CVE-2026-97791

Overview

Apache CXF is an open-source services framework, maintained by the Apache Software Foundation, for building and consuming web services in Java. It implements the JAX-WS and JAX-RS APIs and supports SOAP, the WS-* standards, RESTful HTTP, and OAuth 2.0 over transports such as HTTP and JMS. Its modules are published as Maven artifacts under org.apache.cxf.

An authorization bypass vulnerability (CVE-2026-97791) has been identified in the STSTokenValidator of Apache CXF's WS-Security module, which allows remote, unauthenticated attackers to have a SAML assertion signed with an untrusted certificate accepted as trusted without it ever being sent to the Security Token Service (STS) for validation. Only services that use STSTokenValidator to validate SAML tokens without alwaysValidateToSts set are affected.

Per OWASP: Confirmation of the user's identity, authentication, and session management is critical to protect against authentication-related attacks.

This issue affects multiple versions of Apache CXF.

Details

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-rt-ws-security
• Affected versions: <3.6.13, >=4.0.0 <4.1.9, >=4.2.0 <4.2.4
• GitHub repository: https://github.com/apache/cxf
• Published packages: https://central.sonatype.com/artifact/org.apache.cxf/cxf-rt-ws-security
• Package manager: Maven
• Fixed in:
  
  • OSS Apache CXF 3.6.13, 4.1.9, 4.2.4
  • NES for Apache CXF v3.4.13, v3.5.14

Vulnerability Info

This High-severity vulnerability is found in the org.apache.cxf:cxf-rt-ws-security package in multiple versions of Apache CXF. STSTokenValidator.validate first calls isValidatedLocally. When that method returns true, the credential is accepted as is; otherwise it is sent to the STS through validateWithSTS. For SAML assertions, unless alwaysValidateToSts is set, the local check delegates to a single STSSamlAssertionValidator that is held in an instance field and therefore shared by every request the validator handles:

public class STSTokenValidator implements Validator {
    private STSSamlAssertionValidator samlValidator = new STSSamlAssertionValidator();
    // ...
    protected boolean isValidatedLocally(Credential credential, RequestData data)
        throws WSSecurityException {

        if (!alwaysValidateToSts && credential.getSamlAssertion() != null) {
            try {
                samlValidator.validate(credential, data);
                return samlValidator.isTrustVerificationSucceeded();
            } ...
        }
        return false;
    }
  // ...
}

STSSamlAssertionValidator records the outcome of the signature trust check in a field of its own. verifySignedAssertion sets trustVerificationSucceeded to true when the signing certificate is trusted and to false when trust verification fails, and isTrustVerificationSucceeded() simply returns that field:

public class STSSamlAssertionValidator extends SamlAssertionValidator {
    private boolean trustVerificationSucceeded;

    @Override
    protected Credential verifySignedAssertion(SamlAssertionWrapper assertion, RequestData data)
        throws WSSecurityException {
        try {
            Credential credential = super.verifySignedAssertion(assertion, data);
            trustVerificationSucceeded = true;
            return credential;
        } catch (WSSecurityException ex) {
            ...
            trustVerificationSucceeded = false;
            return null;
        }
    }

Because the write in validate and the read in isTrustVerificationSucceeded() are two separate steps on shared state, concurrent requests race on the same flag. An attacker sends an assertion signed with a certificate the service does not trust while legitimate requests with trusted assertions are being processed. If a legitimate request sets the flag to true between the attacker's validation and the read, isValidatedLocally returns true for the attacker's assertion. validate then returns the attacker's credential as trusted, and the assertion is never forwarded to the STS, which is the component that would have rejected it.

Mitigation

Only recent versions of Apache CXF are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue.

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

• Upgrade to a currently supported Apache CXF release line (3.6.x or later) that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• MopMonk-AI (finder)