CVE-2026-57818
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
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-57818) has been identified in the OAuth2 JCacheCodeDataProvider of Apache CXF, which allows attackers to redeem a single OAuth2 authorization code multiple times through concurrent token requests and obtain several distinct, valid access tokens from one code that should only be usable 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 High-severity vulnerability is found in the 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.
OAuth 2.0 authorization codes are single-use: when a client exchanges a code at the token endpoint, the authorization server must consume the code so that it cannot be redeemed again. In Apache CXF, the token endpoint's authorization code grant handler consumes a code by calling removeCodeGrant on the configured code data provider. The JCache-backed provider, JCacheCodeDataProvider, implements this as two separate, non-atomic cache operations. It first reads the grant, then removes it in a later call:
@Override
public ServerAuthorizationCodeGrant removeCodeGrant(String code) throws OAuthServiceException {
ServerAuthorizationCodeGrant grant = getCodeGrant(code);
if (grant != null) {
grantCache.remove(code);
}
return grant;
}
protected ServerAuthorizationCodeGrant getCodeGrant(String code) throws OAuthServiceException {
ServerAuthorizationCodeGrant grant = grantCache.get(code);
if (grant != null && isExpired(grant)) {
grantCache.remove(code);
grant = null;
}
return grant;
}
Nothing ties the grantCache.get(code) check to the later grantCache.remove(code). When several token requests carrying the same authorization code arrive concurrently, each request thread can read the grant from the cache before any of them removes it. Every one of those threads then gets a non-null grant back from removeCodeGrant, and the token service issues a separate access token (and refresh token, where configured) for each request. This is a time-of-check to time-of-use (TOCTOU) race condition (CWE-367). An attacker who obtains or intercepts an authorization code, or a malicious client, can race multiple redemptions of it and receive several independent, valid tokens. This breaks the single-use guarantee of the authorization code.
This vulnerability was introduced in 2016 with Apache CXF 3.1.7.
Mitigation
Only recent versions of Apache CXF are community-supported. The 3.5.x line was already End-of-Life when this CVE was published 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)