Replay AttackAffected versions of this package are vulnerable to Replay Attack due to the Wss4jSecurityInterceptor class in Wss4jSecurityInterceptor.java not consistently wiring configured Apache WSS4J ReplayCache instances into RequestData for validation-time checks. As a result, replay protections for UsernameToken nonces and creation timestamps, Timestamp elements, and SAML one-time-use semantics are ineffective even when an operator configures a replay cache on the interceptor. An attacker who captures a valid SOAP message can re-submit it and have it accepted again, re-triggering the authenticated operation.
Note:
This is only exploitable if the attacker first captures still-valid cryptographic material and replays it within the message's acceptance window against a deployment that relies on WSS4J replay detection.
How to fix Replay Attack? Upgrade org.springframework.ws:spring-ws-security to version 4.1.4, 5.0.2 or higher.
| |
Incorrect Implementation of Authentication AlgorithmAffected versions of this package are vulnerable to Incorrect Implementation of Authentication Algorithm via the X509AuthenticationProvider class in X509AuthenticationProvider.java. The provider issues a fully authenticated X509AuthenticationToken whenever a presented certificate maps to UserDetails, without applying Spring Security's standard UserDetailsChecker account lifecycle checks. The omission affects both users freshly resolved through X509AuthoritiesPopulator and entries returned from X509UserCache, so accounts that are disabled, locked, expired, or have expired credentials continue to authenticate when mutual TLS or certificate-based SOAP authentication is in use. An attacker who holds a still-valid client certificate mapped to such a deactivated account retains that account's access, gaining limited read and modify capability within the account's privileges over the network.
How to fix Incorrect Implementation of Authentication Algorithm? Upgrade org.springframework.ws:spring-ws-security to version 4.1.4, 5.0.2 or higher.
| |
Insecure DefaultsAffected versions of this package are vulnerable to Insecure Defaults due to the Wss4jSecurityInterceptor class in Wss4jSecurityInterceptor.java initializing its bspCompliant flag to false, so inbound validation always calls RequestData.setDisableBSPEnforcement(true) and disables WSS4J's WS-I Basic Security Profile checks, contradicting the documented secure default of the setBspCompliant setter. A remote, unauthenticated attacker can send SOAP messages that violate BSP rules around signatures and related constructs to a service that uses the interceptor for inbound WS-Security validation, weakening defenses against non-standard transforms and signature-related abuse.
How to fix Insecure Defaults? Upgrade org.springframework.ws:spring-ws-security to version 4.1.4, 5.0.2 or higher.
| |
Information ExposureAffected versions of this package are vulnerable to Information Exposure due to the Spring Security integration paths in SpringSecurityUtils.checkUserValidity(), SpringSecurityPasswordValidationCallbackHandler, and X509AuthenticationProvider, which surface account status exceptions such as LockedException and DisabledException (with SpringSecurityUtils embedding full UserDetails content in exception messages) to remote SOAP clients instead of failing uniformly with a generic BadCredentialsException. A remote attacker submitting SOAP requests through the username-token, digest, or X.509 validation paths can distinguish valid accounts from invalid ones and infer account lifecycle state (locked, disabled, or expired), enabling user enumeration.
How to fix Information Exposure? Upgrade org.springframework.ws:spring-ws-security to version 4.1.4, 5.0.2 or higher.
| |
Use of RSA Algorithm without OAEPAffected versions of this package are vulnerable to Use of RSA Algorithm without OAEP via the Wss4jSecurityInterceptor class, in the Wss4jSecurityInterceptor.java file due to defaulting allowRSA15KeyTransportAlgorithm to true when building the validation RequestData. This overrides Apache WSS4J's safer default, so inbound WS-Security decryption accepts EncryptedKey elements that wrap the symmetric key with the legacy RSA PKCS#1 v1.5 (rsa-1_5) key-transport algorithm instead of requiring RSA-OAEP. An attacker who can capture encrypted SOAP messages and submit modified ciphertexts to the endpoint can use the server's responses as a Bleichenbacher padding oracle to recover the message encryption key, defeating the confidentiality and integrity of WS-Security-protected traffic.
Note:
This is only exploitable if the attacker has a network position from which to intercept WS-Security traffic, and exploitation depends on peers actually negotiating RSA v1.5 key transport.
How to fix Use of RSA Algorithm without OAEP? Upgrade org.springframework.ws:spring-ws-security to version 4.1.4, 5.0.2 or higher.
| |
