CVE-2026-40994: Spring Web Services WS-Security BSP Bypass

Technical summary

The Wss4jSecurityInterceptor in affected Spring Web Services versions fails to properly initialize the BSP compliance flag when processing inbound requests. This causes the RequestData object to have BSP enforcement disabled during message validation. WS-I Basic Security Profile defines strict rules for WS-Security header construction, canonicalization, and timestamp handling. When BSP enforcement is disabled, messages violating these rules are accepted without error, allowing potential signature spoofing, timestamp tampering, or malformed credential structures to pass validation. The vulnerability affects multiple active maintenance branches across several years of releases.

Business impact

Organizations running Spring Web Services as a SOAP endpoint face the risk of accepting fraudulent or tampered WS-Security messages that should have been rejected. This undermines message authenticity and non-repudiation guarantees, particularly critical in B2B integrations, financial services, and regulated environments where WS-Security is deployed specifically to enforce protocol-level trust. An attacker could modify messages in transit, impersonate legitimate services, or bypass credential validation, leading to unauthorized data access or transaction manipulation.

Affected systems

Spring Web Services versions 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 are affected. Organizations should identify instances where Wss4jSecurityInterceptor is used to validate inbound WS-Security messages. This vulnerability does not affect Spring Web Services versions prior to 3.1.0, but verify your exact version before assuming safety.

Exploitability

The vulnerability requires network access to the SOAP endpoint but no authentication or user interaction. The attacker simply constructs a WS-Security message that violates BSP rules (such as missing required headers, improper signatures, or expired timestamps) and sends it to the vulnerable service. Because BSP enforcement is disabled, the message is processed as if it were valid. This is a straightforward network-based attack with low complexity; no special credentials or interaction with legitimate users is needed. Active exploitation is feasible.

Remediation

Update Spring Web Services to a patched version that properly initializes BSP compliance. Verify the specific patch version with the Spring projects advisory, as each branch (3.1.x, 4.0.x, 4.1.x, 5.0.x) has its own patch release. Until patching is possible, apply strict network segmentation to limit access to SOAP endpoints and consider implementing additional WS-Security validation logic at the application or gateway layer. Review logs for anomalous WS-Security message patterns or rejections prior to the fix.

Patch guidance

Contact Spring projects via their security advisory channels to identify the specific patched version for your branch. Each maintenance line (3.1, 4.0, 4.1, 5.0) will have a minimum patched version that re-enables BSP enforcement in Wss4jSecurityInterceptor. Test patches in a non-production environment to confirm BSP validation is restored and that legitimate clients continue to function. Coordinate with teams managing downstream SOAP consumers to ensure they send properly formed WS-Security messages.

Detection guidance

Enable debug-level logging for Spring Web Services security processing to observe the RequestData BSP flag state. Monitor for WS-Security validation exceptions or unusual message rejection patterns before and after patching. Search for Wss4jSecurityInterceptor bean configurations in your Spring context to confirm which endpoints are affected. Review WS-Security headers in transit (via proxy logs or packet captures) for structural violations (missing timestamps, incorrect signature algorithms, expired credentials) that should have been rejected. Baseline these metrics to detect when BSP enforcement is restored.

Why prioritize this

This vulnerability has a CVSS 3.1 score of 8.2 (HIGH) due to low attack complexity, no authentication requirement, and network accessibility combined with meaningful integrity impact. While not actively exploited in the wild per KEV data, the ease of exploitation and direct weakening of cryptographic controls in WS-Security make it a priority for any organization relying on SOAP endpoints for sensitive integrations. Patch promptly, particularly for production B2B or financial services systems.

Risk score, explained

The score reflects three key factors: (1) ease of attack—any network user can send a malformed WS-Security message without credentials; (2) protocol-level impact—BSP bypass weakens message integrity and authenticity assurances that are the core reason WS-Security is deployed; (3) scope—the vulnerability affects multiple stable versions across three years of releases, increasing the population of affected deployments. The availability impact is rated as none because validation bypass does not cause service unavailability, only integrity compromise.

Frequently asked questions