Server-side Request Forgery (SSRF) Affecting org.springframework.ws:spring-ws-core package, versions [,4.1.4)[5.0.0-M1,5.0.2)


Severity

Recommended
0.0
high
0
10

CVSS assessment by Snyk's Security Team. Learn more

Threat Intelligence

EPSS
0.43% (34th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Server-side Request Forgery (SSRF) vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-JAVA-ORGSPRINGFRAMEWORKWS-17320740
  • published12 Jun 2026
  • disclosed10 Jun 2026
  • creditUnknown

Introduced: 10 Jun 2026

NewCVE-2026-40999  (opens in a new tab)
CWE-918  (opens in a new tab)

How to fix?

Upgrade org.springframework.ws:spring-ws-core to version 4.1.4, 5.0.2 or higher.

Overview

org.springframework.ws:spring-ws-core is a product of the Spring community focused on creating document-driven Web services. Spring Web Services aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads.

Affected versions of this package are vulnerable to Server-side Request Forgery (SSRF). When WS-Addressing is used with non-anonymous ReplyTo or FaultTo addresses, the addressing server interceptor initiates outbound connections through configured WebServiceMessageSender instances to destinations taken directly from the request's wsa:ReplyTo / wsa:FaultTo headers, without verifying that those destinations are safe to connect to. An attacker can supply 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.

Note:

This issue only affects deployments where all of the following are true:

  • an AbstractAddressingEndpointMapping subclass is registered with one or more WebServiceMessageSender instances configured for out-of-band replies;

  • the service accepts WS-Addressing wsa:ReplyTo / wsa:FaultTo headers from untrusted callers;

  • no restrictive destination validator or network-level egress control is in place.

Workaround

This can be mitigated by restricting the destinations each configured sender accepts by overriding its supports method, for example to allowlist specific JMS destination names:

class SafeJmsMessageSender extends JmsMessageSender {
    @Override
    public boolean supports(URI uri) {
        return super.supports(uri) &&
                isAllowedDestination(JmsTransportUtils.getDestinationName(uri));
    }

private boolean isAllowedDestination(String destinationName) {
    // Return true only for known-safe destination names
}

}

CVSS Base Scores

version 4.0
version 3.1