Spring Web Services vulnerabilities

In Spring Web Services (versions 5.0.0-5.0.1, 4.1.0-4.1.3, 4.0.0-4.0.18, 3.1.0-3.1.8) the Wss4jSecurityInterceptor did not properly wire ReplayCache instances into RequestData, making replay protections ineffective for UsernameToken nonces, timestamps, and SAML.

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 their safety.

Vulnerability in Spring Web Services (Jaxp13XPathTemplate) causes XPath expressions to be processed with the JDK's default configuration instead of Spring's hardened parser. This can lead to XXE (XML External Entity) attacks when processing untrusted XML data.

Spring Web Services integrated with Spring Security may expose detailed account state (e.g., locked or disabled user) to remote SOAP clients via exception messages or callback outcomes, instead of generic authentication errors. Affects versions 5.0.0-5.0.1, 4.1.0-4.1.3, 4.0.0-4.0.18, 3.1.0-3.1.8.

In Spring Web Services, Wss4jSecurityInterceptor defaults allowRSA15KeyTransportAlgorithm to true, overriding Apache WSS4J's safer default. This allows acceptance of RSA PKCS#1 v1.5 (rsa-1_5) encrypted keys during WS-Security decryption unless explicitly reconfigured.

In Spring Web Services, X509AuthenticationProvider can issue a fully authenticated token when a certificate maps to UserDetails without applying standard account lifecycle checks (disabled, locked, expired, or credentials-expired accounts).

Wss4jSecurityInterceptor initialized its BSP compliance flag so that inbound validation disabled WSS4J BSP enforcement on RequestData. Services that validate WS-Security on the network could therefore accept messages that violate BSP rules, weakening protocol-level checks.