CVE-2026-41000: Spring Web Services Replay Cache Configuration Bypass

Technical summary

CVE-2026-41000 stems from incomplete wiring of Apache WSS4J ReplayCache instances into the RequestData object during validation processing in Wss4jSecurityInterceptor. The interceptor accepts ReplayCache configuration, but validation-time checks do not reliably receive the configured cache instance, causing replay protections for UsernameToken nonces and creation timestamps, Timestamp elements, and certain SAML OneTimeUse assertions to fail silently. The vulnerability affects Spring Web Services versions 5.0.0–5.0.1, 4.1.0–4.1.3, 4.0.0–4.0.18, and 3.1.0–3.1.8. An unauthenticated network attacker with access to observed SOAP message traffic can replay valid security tokens without detection.

Business impact

For organizations using Spring Web Services as a SOAP intermediary or service layer, this vulnerability undermines the effectiveness of replay-attack defenses that were intended to prevent unauthorized message reuse. An attacker with network access can replay stolen or intercepted credentials and timestamps to impersonate legitimate users or services. The actual risk depends on whether a replay cache was configured: if none was set, this CVE has no practical effect. However, for deployments that did configure replay protection expecting it to work, the gap creates an authentication bypass opportunity. Exposure is limited to SOAP endpoints using Spring Web Services and is most acute in environments handling sensitive transactional or identity data over SOAP protocols.

Affected systems

Spring Web Services versions 3.1.0 through 3.1.8, 4.0.0 through 4.0.18, 4.1.0 through 4.1.3, and 5.0.0 through 5.0.1 are affected. This includes both currently maintained versions (4.1.x, 5.0.x) and legacy branches. Any deployment using Wss4jSecurityInterceptor with a configured ReplayCache is potentially vulnerable. Spring Web Services is typically embedded in custom SOAP services or used in enterprise middleware; it is not a widely deployed end-user application.

Exploitability

Exploitation requires network-level access to SOAP traffic and knowledge of a previously valid security token or timestamp. An attacker must observe and capture a legitimate SOAP message (containing a UsernameToken with a nonce, a Timestamp element, or a SAML assertion with OneTimeUse constraints), then replay it within a window where the token remains valid. No user interaction is required, and the attack can be scripted. However, the CVSS score of 3.7 (LOW) reflects the high bar for access: the attacker must be able to intercept SOAP messages on the network and replay them—typically possible only for internal attackers, insecure network segments, or deployments exposed without TLS. The integrity impact is limited; confidentiality and availability are not directly affected.

Remediation

Apply the latest patch version from Spring Web Services. For version 3.1.x, upgrade to 3.1.9 or later (verify against vendor advisory). For 4.0.x, upgrade to 4.0.19 or later. For 4.1.x, upgrade to 4.1.4 or later. For 5.0.x, upgrade to 5.0.2 or later. If immediate patching is not possible, ensure Wss4jSecurityInterceptor is not configured with a ReplayCache and audit SOAP endpoints to confirm replay protection is not advertised or expected. Additionally, enforce strict TLS/mutual authentication for SOAP endpoints to reduce the likelihood of token interception.

Patch guidance

Contact Spring Web Services maintainers or consult the official VMware/Pivotal release notes for the specific patched version in your branch. The patch corrects the wiring of ReplayCache into RequestData during validation. After patching, verify replay protection is functional by testing with replayed tokens in a non-production environment. Patch releases are expected across all affected branches; prioritize patching production environments running 4.1.x or 5.0.x, as these are the most actively supported lines.

Detection guidance

Monitor SOAP request logs for repeated or near-identical security tokens (nonces, timestamps) arriving in short time windows. Use WSS4J diagnostic logging (enable DEBUG level on org.apache.wss4j packages) to capture validation events and confirm whether ReplayCache is actually being invoked during token validation. A replayed token that bypasses validation without error indicates this vulnerability is present. Correlation of repeated UsernameToken nonces or Timestamp values across multiple requests is a strong indicator of replay-attack attempts. Network-level packet capture of SOAP traffic can reveal token reuse patterns.

Why prioritize this

Although this CVE has a low CVSS score, it should be prioritized if your organization: (1) uses Spring Web Services for SOAP endpoints handling authentication or sensitive transactions; (2) has configured replay-cache protection expecting it to work; or (3) operates in a network environment where SOAP traffic might be intercepted by unauthorized parties. For most modern cloud and web-service architectures, Spring Web Services is not a critical dependency, making this a medium-priority patch. However, for legacy SOA or federated identity systems relying on Spring Web Services, the authentication-bypass potential justifies earlier patching.

Risk score, explained

CVSS 3.7 (LOW) reflects: (1) network-level attack vector and no privilege or user interaction required, balanced against (2) high access complexity (attacker must observe and time token replay), (3) limited scope (only affects SOAP endpoints using Spring Web Services), and (4) integrity impact only (no confidentiality or availability loss). The score does not account for whether replay cache was actually configured; if not configured, the vulnerability has no practical effect. The low score should not be interpreted as 'non-urgent'—it reflects the attack's technical constraints, not its absence of business risk.

Frequently asked questions