CVE-2026-41000

Overview

Spring Web Services (Spring WS) is a product of the Spring community focused on creating document-driven, contract-first SOAP web services, with built-in support for WS-Security through its integration with Apache WSS4J.

A low-severity vulnerability (CVE-2026-41000) has been identified in Spring Web Services. The Wss4jSecurityInterceptor did not wire Apache WSS4J ReplayCache instances into the validation pipeline. As a result, protections against replay of UsernameToken nonces and creation timestamps, Timestamp elements, and SAML one-time-use assertions could be ineffective even when operators configured a replay cache on the interceptor, allowing attackers to re-submit still-valid cryptographic material within the acceptance window.

Per OWASP, permitting replay attacks is a form of identification and authentication failure: an application that fails to detect the re-submission of previously used credentials or messages allows an attacker to re-use valid authentication material they have captured.

This issue affects >=2.4.0 <=2.4.7, >=3.1.0 <=3.1.8, >=4.0.0 <=4.0.18, >=4.1.0 <=4.1.3, and >=5.0.0 <=5.0.1 of Spring Web Services.

‍

Details

Module Info

• Product: Spring Web Services
• Affected packages: spring-ws-security
• Affected versions: >=2.4.0 <=2.4.7, >=3.1.0 <=3.1.8, >=4.0.0 <=4.0.18, >=4.1.0 <=4.1.3, >=5.0.0 <=5.0.1
• GitHub repository: https://github.com/spring-projects/spring-ws
• Published packages: https://central.sonatype.com/artifact/org.springframework.ws/spring-ws-security
• Package manager: Maven
• Fixed in:
• NES for Spring Web Services 2.4.x, 3.1.x, 4.0.x
• Spring Web Services 5.0.2, 4.1.4 (OSS)

Vulnerability Info

WS-Security relies on replay detection to stop an attacker from capturing a valid SOAP message and submitting it again. Apache WSS4J implements this with ReplayCache instances that record previously seen UsernameToken nonces, message timestamps, and SAML OneTimeUse assertions, rejecting any message whose token has already been processed.

In affected versions of Spring Web Services, the Wss4jSecurityInterceptor builds the WSS4J RequestData object for inbound message validation in its initializeValidationRequestData method without attaching any replay cache:

protected RequestData initializeValidationRequestData(MessageContext messageContext) {
    RequestData requestData = new RequestData();
    requestData.setMsgContext(messageContext);

    requestData.setWssConfig(wssConfig);
    requestData.setDecCrypto(validationDecryptionCrypto);
    requestData.setSigVerCrypto(validationSignatureCrypto);
    requestData.setCallbackHandler(validationCallbackHandler);

    messageContext.setProperty(WSHandlerConstants.TTL_TIMESTAMP, Integer.toString(validationTimeToLive));

    requestData.setTimeStampStrict(timestampStrict);
    requestData.setTimeStampTTL(validationTimeToLive);
    requestData.setTimeStampFutureTTL(futureTimeToLive);

    // ... no replay cache is ever set on requestData
    return requestData;
}

Because RequestData carries no ReplayCache, the WSS4J validators have no cross-request store of previously seen nonces, timestamps, or one-time-use assertions. Any captured message whose timestamp or nonce is still inside the configured time-to-live acceptance window (300 seconds by default) validates successfully again on every re-submission. An attacker positioned to observe a valid message can therefore replay authenticated or signed requests against the service for the remainder of the acceptance window.

The conditions for exploitation are: the service validates WS-Security constructs that rely on replay detection (username tokens with nonces, timestamps, or SAML one-time-use assertions), the service accepts repeated SOAP messages over the network, and the deployment expects WSS4J replay caches to be enforced.

The remediation wires configurable ReplayCache instances into RequestData during validation, so nonce, timestamp, and SAML one-time-use replay checks run across requests, and introduces Spring-friendly cache implementations for single-node and distributed deployments.

‍

Mitigation

The Spring Web Services 2.4.x, 3.1.x, and 4.0.x release lines are End-of-Life and have no publicly available fix. Affected users should not attempt to author their own patches.

Recommended actions:

1. Upgrade to a supported, fixed Spring Web Services release (5.0.2 or 4.1.4).
2. If upgrading is not feasible because you depend on an End-of-Life release line, obtain a supported, patched build through a commercial support partner like HeroDevs Never-Ending Support (NES).