CVE-2026-40999

Overview

Spring Web Services (Spring WS) is a product for building document-driven, contract-first SOAP web services, providing WS-Addressing, WS-Security, and message-mapping support on top of the Spring Framework. A high-severity vulnerability (CVE-2026-40999) has been identified in its WS-Addressing out-of-band reply handling.

When WS-Addressing is used with non-anonymous ReplyTo or FaultTo addresses, Spring WS may initiate outbound connections through configured WebServiceMessageSender instances to destinations taken directly from request headers, without verifying that those destinations are safe to connect to. A remote attacker can supply crafted addressing headers that cause the server to connect to internal-only hosts, cloud metadata endpoints, or other sensitive destinations, resulting in Server-Side Request Forgery (SSRF).

Per OWASP, Server-Side Request Forgery flaws occur whenever a web application fetches a remote resource without validating the user-supplied destination, allowing an attacker to coerce the application into sending requests to unintended internal services and bypassing network controls such as firewalls.

This issue only affects deployments where an AbstractAddressingEndpointMapping subclass is registered with one or more WebServiceMessageSender instances configured for out-of-band replies, the service accepts WS-Addressing headers from untrusted callers, and no restrictive destination validator or network-level egress control is in place.

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. Versions that are no longer supported are also affected.

‍

Details

Module Info

• Product: Spring Web Services
• Affected packages: spring-ws-core
• 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-core
• 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

Spring WS supports WS-Addressing, which lets a SOAP request specify where replies and faults should be delivered through the wsa:ReplyTo and wsa:FaultTo header elements. When a request carries a non-anonymous reply address, the server delivers the response or fault out of band by opening a new outbound connection to that address using one of the configured WebServiceMessageSender instances.

The vulnerability is in the out-of-band send path of AddressingEndpointInterceptor. The interceptor took the reply endpoint address straight from the attacker-influenced addressing header and asked each configured sender only whether it could handle the URI, then opened a connection to it:

boolean supported = false;
for (WebServiceMessageSender messageSender : this.messageSenders) {
    if (messageSender.supports(replyEpr.getAddress())) {
        supported = true;
        try (WebServiceConnection connection = messageSender.createConnection(replyEpr.getAddress())) {
            connection.send(messageContext.getResponse());
            break;
        }
    }
}

‍The supports(URI) check only confirmed that a sender understood the transport (for example, that a URI used the http scheme), not that the destination was safe to reach. A remote, peer-supplied destination was treated identically to an application-chosen one, so the server would open a connection to whatever host the attacker named, including loopback addresses, private network ranges, and cloud metadata endpoints. Because authentication-related ordering was not enforced, a request that failed WS-Security validation could still trigger fault delivery to an attacker-supplied wsa:FaultTo address.

The remediation distinguishes the origin of a destination URI: application-controlled destinations retain their existing behavior, while peer-supplied wsa:ReplyTo and wsa:FaultTo URIs are classified as remote and subjected to stricter validation before any connection is opened. Per-transport default checks were added (HTTP host and literal-IP screening that rejects private IPv4 literals and disables DNS resolution by default to mitigate DNS rebinding, JMS destination-name screening, mail host rules, and XMPP domain alignment), composable with an optional destination policy. WS-Security interceptors are also ordered to run before WS-Addressing processing so that requests failing authentication cannot trigger out-of-band delivery.

If upgrading is not possible, deployments can restrict the destinations each configured sender accepts by overriding its supports method to allowlist known-safe destinations, applying the same pattern to every configured sender type such as HttpUrlConnectionMessageSender, JmsMessageSender, and MailMessageSender.

‍

Mitigation

Spring Web Services lines 4.0.x and 3.1.x, along with all earlier versions, are End-of-Life and have no publicly available fix for this vulnerability. Information about Spring Web Services support timelines is available at https://spring.io/projects/spring-ws.

To remediate this vulnerability, we recommend one of the following:

1. Upgrade to a supported, fixed version of Spring Web Services (5.0.2 or 4.1.4, or later).
2. If you are running an End-of-Life version that cannot be upgraded, adopt HeroDevs Never-Ending Support (NES) for Spring, which provides drop-in secure replacements for End-of-Life Spring Web Services releases.