CVE-2026-41694: Spring Security SAML Decryption Oracle Vulnerability

Technical summary

CVE-2026-41694 is a signature validation bypass in Spring Security's SAML support that allows an unauthenticated attacker to use a SAML Service Provider as a decryption oracle. The vulnerability exists because Spring Security decrypts SAML Response elements and LogoutRequest/LogoutResponse elements without mandating a valid XML signature on those payloads first. An attacker can submit crafted SAML assertions or logout messages to exploit this, potentially leveraging timing analysis or error-based side channels to infer information about decryption operations. The attack surface is network-accessible and requires no special privileges, but the practical impact is constrained by the strength of typical SAML encryption and the limited information leakage channels available in most deployment scenarios.

Business impact

Organizations using Spring Security's SAML authentication should treat this as a moderate priority maintenance item rather than an emergency. The vulnerability does not enable direct authentication bypass or account takeover. However, in environments where SAML encryption keys are particularly sensitive or where an attacker has already compromised network visibility, the decryption oracle could be weaponized to recover key material or other encrypted data. The risk is highest for applications handling high-value SAML assertions or those deployed in zero-trust network architectures where lateral movement is already expected.

Affected systems

VMware Spring Security versions 5.7.0–5.7.23, 5.8.0–5.8.25, 6.3.0–6.3.16, 6.4.0–6.4.16, 6.5.0–6.5.10, and 7.0.0–7.0.5 are affected. Any application using Spring Security's SAML Service Provider functionality for authentication is in scope. Applications that do not use Spring Security's SAML module, or those using only the Identity Provider role, are not affected. Applications already enforcing signature validation through custom policy overrides are also not exposed.

Exploitability

Exploitation requires network access and the ability to submit SAML payloads to the target application's SAML endpoint. No authentication is required, and no user interaction is needed. However, the attack complexity is high because the attacker must either observe timing differences, analyze error messages, or conduct repeated interactions to extract meaningful information. Public exploit code is not known to exist, and the vulnerability is not listed on CISA's Known Exploited Vulnerabilities catalog, suggesting real-world exploitation remains theoretical at present.

Remediation

Upgrade Spring Security to a patched version. Verify against official VMware Spring Security advisories for the exact patch versions that address CWE-347 in each branch (5.7.x, 5.8.x, 6.3.x, 6.4.x, 6.5.x, and 7.0.x). As an interim control, enforce SAML signature validation policies at the application level or via SAML assertion validators if your current Spring Security version cannot be updated immediately. Monitor for abnormal patterns of SAML decryption requests or unusually high error rates on your SAML endpoints.

Patch guidance

Check the official VMware Spring Security release notes and security advisories for the targeted patch version in your active branch. Each major version series (5.7.x, 5.8.x, 6.3.x, 6.4.x, 6.5.x, 7.0.x) has its own remediation path. Prioritize upgrading 7.0.x deployments first if you are on the latest major version, as those tend to receive support longest. After patching, validate that SAML assertion signature verification is enabled in your configuration by reviewing the org.springframework.security.saml2.provider.service.servlet.filter.Saml2WebSsoAuthenticationFilter settings and confirming SignatureValidator is active.

Detection guidance

Monitor application logs for repeated SAML decryption errors or malformed SAML assertions arriving at your Service Provider endpoint. Implement alerting on SAML endpoint 400/401 responses that cluster around suspicious timestamps or originate from unexpected sources. Network-level detection is difficult because malicious SAML payloads appear as normal HTTP POST traffic. Consider adding a SAML assertion validator that logs signature validation failures before decryption occurs, allowing you to see if an attacker is consistently submitting unsigned or re-signed payloads.

Why prioritize this

Although the CVSS score is low (3.7), this vulnerability warrants timely patching because it enables an attacker to systematically probe encryption strength and potentially recover key material in targeted attacks. The lack of signature validation before decryption violates the principle of crypto-agility and defense-in-depth. Given that Spring Security is widely used in enterprise Java environments, batch patching cycles should include this fix in the next scheduled maintenance window, even if no active exploitation is observed. The fact that it is not yet on the KEV catalog should not delay remediation; it reflects the recent publication date and limited public visibility rather than low actual risk.

Risk score, explained

The CVSS 3.1 score of 3.7 (LOW) reflects that exploitation requires high complexity, yields only confidential information disclosure, and does not require authentication. However, the true risk in a given environment depends on how SAML encryption keys are managed, whether the attacker has network vantage to conduct repeated oracle queries, and the sensitivity of assertions being protected. Organizations with particularly strict key-rotation policies or those using SAML only for low-risk service-to-service calls may view this as minimal risk. Conversely, those using SAML for sensitive user authentication in compliance-heavy industries should prioritize patching above the CVSS score.

Frequently asked questions