Apache CXF CVE-2026-73179

Exploitation requires that the target run the Apache CXF OAuth2 authorization server using the JPA-backed authorization code grant provider persisting codes to a shared relational database operating under READ_COMMITTED isolation - this specific provider/config is the prerequisite, not default for every CXF deployment. The attacker must also possess a single valid, not-yet-redeemed authorization code and be able to issue multiple token-exchange requests concurrently to win the race. Limiting factors: success is probabilistic due to the timing race (AC:H); stronger database isolation (e.g., SERIALIZABLE) or the patched atomic delete removes the window; and affected versions are bounded to CXF <3.6.13, 4.2.0-<4.2.4, and 4.0.0-<4.1.9.

Signals are consistent in pointing to a real-but-conditional risk rather than a mass-exploitation emergency. The CVSS 3.1 base score of 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects a network-reachable flaw with no required privileges or user interaction, but critically carries AC:H - exploitation depends on winning a timing race against a non-atomic find-then-delete under READ_COMMITTED database isolation, which is not deterministic. EPSS corroborates this: 0.22% (11th percentile) indicates very low predicted exploitation probability, aligning with the high attack complexity and the narrow precondition that the attacker must already possess a valid authorization code. The flaw is NOT in CISA KEV and there is no public exploit identified at time of analysis, so there is no evidence of active exploitation. Note a nuance the CVSS vector understates: although PR:N is scored (the token endpoint requires no pre-existing account), the attacker must hold or intercept a legitimate OAuth2 authorization code, so this is realistically an abuse of the OAuth flow rather than a fully anonymous attack - verify operational context before treating it as trivially remote. Overall: a legitimately serious correctness/authorization defect worth patching promptly for anyone running the CXF JPA OAuth2 authorization-code provider, but not an emergency 'drop-everything' item given AC:H, low EPSS, no KEV, and no known POC.

An OAuth2 client (or an attacker who has intercepted a single authorization code) submits several token-exchange requests to the Apache CXF authorization server simultaneously. Because the JPA provider performs a non-atomic find-then-delete on the code under READ_COMMITTED isolation, multiple concurrent requests each find the code still present and are each issued a valid access token, defeating single-use semantics. No public exploit code is identified, and the timing-dependent race (AC:H) makes reliable exploitation non-trivial.