Apache CXF EUVD-2026-53858

Exploitation requires that the target Apache CXF instance is deployed as an OAuth 2.0 authorization server using the DefaultEncryptingCodeDataProvider class specifically. Deployments that use alternative code providers or that do not implement the authorization code grant flow are not affected. An attacker must first obtain a valid, unexpired authorization code issued to a legitimate user - this typically requires network interception, access to server/proxy logs that record authorization code values, or exploitation of HTTP referrer header leakage from redirect URIs. Exploitation is limited to the authorization code grant type; client credentials, implicit, and resource owner password grants are not affected by this flaw. The victim user must have initiated an OAuth authorization flow to generate the code in the first place.

No CVSS score or vector was provided in the source data, so risk must be inferred from the description and CWE. The exploit requires the attacker to first capture a valid authorization code - a non-trivial prerequisite that implies high attack complexity (e.g., network interception, MITM position, log access, or referrer header leakage). User interaction is required because a legitimate user must initiate the OAuth flow to generate the code. Once a code is captured, however, exploitation is straightforward and repeatable, requiring no further privileges. The confidentiality impact is high, as repeated token issuance can grant sustained unauthorized access to protected resources. EPSS data is not available in the provided intelligence. No CISA KEV listing exists. No public POC or exploit code has been identified. The net assessment is moderate-to-high real-world risk for deployments using Apache CXF as an OAuth 2.0 authorization server, particularly in environments where authorization codes traverse less-than-fully-trusted channels (proxies, logging pipelines). The risk is substantially lower for deployments using CXF only as a web service client or non-OAuth server.

An attacker positioned to observe OAuth 2.0 traffic - via a shared network, a misconfigured proxy that logs query parameters, or HTTP referrer header leakage from a redirect URI - captures a victim's authorization code during a legitimate login flow. The attacker then exchanges this code at the CXF token endpoint to obtain a valid access token; because removeCodeGrant() does not properly invalidate the code, the attacker can repeat this exchange to obtain multiple tokens, maintaining unauthorized access even after the original token expires. No public POC has been identified, but the technique is well-understood within standard OAuth 2.0 attack research.