Vulnerability Directory | CVE-2026-41694

Overview

Spring Security is a powerful and highly customizable authentication and access-control framework for Java applications built on the Spring Framework, and its spring-security-saml2-service-provider module lets an application act as a SAML 2.0 Service Provider that consumes SAML Responses and single-logout messages from an identity provider. A low-severity vulnerability (CVE-2026-41694) has been identified in that module: when processing SAML Responses, as well as encrypted elements of SAML LogoutRequests and LogoutResponses, the Service Provider decrypts the attacker-supplied ciphertext before it has confirmed that the message carries a valid signature. Because decryption runs ahead of the signature gate, an attacker who can submit crafted SAML payloads can use the Service Provider as a decryption oracle, observing its differential behavior to recover information about the encrypted contents.

Per OWASP, this falls under cryptographic failures, where missing or improperly ordered verification of cryptographic operations exposes data that should remain protected. Here, performing decryption on unverified input lets an attacker probe the decryption routine with chosen ciphertext and infer plaintext, rather than having every untrusted message rejected at the signature check before any cryptographic processing occurs.

This issue affects versions >=5.5.0 <=5.5.8, >=5.7.0 <=5.7.23, >=5.8.0 <=5.8.25, >=6.2.0 <=6.2.8, >=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 of Spring Security.

‍

Details

Module Info

Product: Spring Security
Affected packages: spring-security-saml2-service-provider
Affected versions: >=5.5.0 <=5.5.8, >=5.7.0 <=5.7.23, >=5.8.0 <=5.8.25, >=6.2.0 <=6.2.8, >=6.3.0 <=6.3.16, >=6.4.0 <=6.4.16, >=6.5.0 <=6.5.10, >=7.0.0 <=7.0.5
GitHub repository: https://github.com/spring-projects/spring-security
Published packages: https://central.sonatype.com/artifact/org.springframework.security/spring-security-saml2-service-provider
Package manager: Maven
Fixed in:
NES for Spring Security 5.5.x, 5.7.x, 5.8.x, 6.2.x, 6.3.x, 6.4.x
Spring Security 6.5.11, 7.0.6 (OSS)

Vulnerability Info

The weakness lives in the SAML message-processing pipelines of the spring-security-saml2-service-provider module. Both the authentication (login) path and the single-logout path decrypt encrypted elements of an inbound SAML message before they treat a signature failure as a stopping condition.

On the login path, the provider that processes a SAML Response validates the response signature into an accumulating result, but then invokes the decrypter while that result may already hold signature errors, instead of stopping as soon as the signature is found to be invalid or missing:

ResponseToken responseToken = new ResponseToken(response, token);
Saml2ResponseValidatorResult result = this.responseSignatureValidator.convert(responseToken);
if (responseSigned) { // gated on signature presence, not validity
    this.responseElementsDecrypter.accept(responseToken);
}
// ...
for (Assertion assertion : response.getAssertions()) {
    AssertionToken assertionToken = new AssertionToken(assertion, token);
    result = result.concat(this.assertionSignatureValidator.convert(assertionToken));
    if (responseSigned || assertion.isSigned()) {
        this.assertionElementsDecrypter.accept(assertionToken);
    }
}

The signature errors held in result are only thrown at the very end of the method, after the decrypter has already run against the attacker-controlled EncryptedAssertion and EncryptedData elements. On the single-logout path, the logout validator builds one combined result that concatenates signature verification with the rest of request validation, so the NameID and other encrypted elements of a LogoutRequest or LogoutResponse are decrypted regardless of whether the signature check produced errors:

return Saml2LogoutValidatorResult.withErrors()
    .errors(verifySignature(request, logoutRequest, registration))
    .errors(validateRequest(logoutRequest, registration, authentication))
    .build();

Because decryption is reachable without a valid signature, an attacker who can deliver crafted SAML payloads to the Service Provider can submit chosen ciphertext and use the application as a decryption oracle. The fix reorders both pipelines so that signature validation is a hard gate: the login path returns immediately when the response signature is invalid and skips decryption and downstream validation for any individual assertion whose signature fails, and the logout path returns early on any signature error before performing request validation or decrypting the NameID. Decryption is therefore only ever performed on input whose signature has already been verified.

‍

Mitigation

Only recent versions of Spring Security receive community support and updates. Older versions have no publicly available fixes for this vulnerability.

Users of the affected components should apply one of the following mitigations:

Upgrade to a currently supported version of Spring Security. The OSS fix ships in Spring Security 6.5.11 (6.5.x line) and 7.0.6 (7.0.x line).
Leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support (NES) for Spring Security. Learn more and request coverage at https://www.herodevs.com/support/spring-nes

‍