CVE-2026-68079

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-68079) has been identified in the DefaultEncryptingCodeDataProvider class of the Apache CXF OAuth 2.0 module, which allows attackers who capture an authorization code to redeem it any number of times and obtain fresh access tokens for the user who granted it. This breaks the OAuth 2.0 requirement (RFC 6749) that an authorization code must not be used more than once.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects versions before 3.6.12, versions 4.0.0 through 4.1.7, and versions 4.2.0 through 4.2.2 of Apache CXF.

Details

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-rt-rs-security-oauth2
• Affected versions: <3.6.12, >=4.0.0 <4.1.8, >=4.2.0 <4.2.3
• GitHub repository: https://github.com/apache/cxf
• Published packages: https://central.sonatype.com/artifact/org.apache.cxf/cxf-rt-rs-security-oauth2
• Package manager: Maven
• Fixed in:
  
  • OSS Apache CXF 3.6.12, 4.1.8, 4.2.3
  • NES for Apache CXF v3.5.13, v3.4.12

Vulnerability Info

This Critical-severity vulnerability is found in the org.apache.cxf:cxf-rt-rs-security-oauth2 package in versions before 3.6.12, versions 4.0.0 through 4.1.7, and versions 4.2.0 through 4.2.2 of Apache CXF.

DefaultEncryptingCodeDataProvider is a stateless-style authorization code store: when a code grant is created, the whole grant is encrypted with the provider's secret key, and the encrypted string itself is handed to the client as the authorization code. The provider keeps a set of the encrypted codes it has issued, and that set is the only thing meant to make each code single-use.

When a client exchanges a code at the token endpoint, AuthorizationCodeGrantHandler calls removeCodeGrant(code) and issues an access token for whatever grant comes back, provided it is non-null, unexpired, bound to the same client, and passes the redirect URI and PKCE code verifier checks. None of these checks establishes that the code has not already been redeemed. In the vulnerable implementation, removeCodeGrant discards the boolean result of grants.remove(code) and always decrypts and returns the grant:

@Override
public ServerAuthorizationCodeGrant removeCodeGrant(String code) throws OAuthServiceException {
    grants.remove(code);
    return ModelEncryptionSupport.decryptCodeGrant(this, code, key);
}

public ServerAuthorizationCodeGrant getCodeGrant(String code) throws OAuthServiceException {
    ServerAuthorizationCodeGrant grant = ModelEncryptionSupport.decryptCodeGrant(this, code, key);
    if (grant != null) {
        grants.remove(code);
    }
    return grant;
}

Because the code is self-contained ciphertext, decryption succeeds whether or not the code is still in the issued set. The first redemption removes the code from the set, but every later redemption of the same code still decrypts to a valid grant and the token endpoint issues another access token. An attacker who obtains an authorization code and can pass the token endpoint's client checks can therefore keep exchanging it for tokens after the legitimate client has already used it. The code might leak through a redirect URL, browser history, proxy or server logs, or a Referer header. getCodeGrant has a related flaw: it decrypts without checking membership in the issued set, and it removes the code from that set as a side effect of a read.

Mitigation

Only recent versions of Apache CXF receive community support. 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

• Guanping Zhang (finder)