CVE-2026-97791
Apache Cxf: race condition
- Risk score
- 54/100
- CVSS
- 7.5 v3.1
- Exploit chance (30 days)
- 0.3%
- Published
- 9 Oct 2026
Open in the live forecast Today's forecast
What to know
- What it is
- In Apache CXF, STSTokenValidator checks whether a SAML assertion is signed by a trusted certificate before deciding to send it to the STS. That result was stored in one object shared by all requests, so one request could read another's result. A remote, unauthenticated attacker could send a forged assertion signed wit…
- Affected
- Apache Cxf before 4.2.4, 4.1.9, 3.6.13
- Fix
- Upgrade Apache Cxf to 4.2.4, 4.1.9 or 3.6.13 (whichever matches your release line), or later.
- Exploitation
- No known exploitation
Story map
At a glance
Apache Cxf: Amber, patch this week. The max_age authentication-freshness check in OidcClientCodeRequestFilter was inoperative due to a milliseconds/seconds unit mismatch and an inverted comparison polarity. Any relying party using setMaxAgeOffset to enforce re-authentication would silently accept sessions of any age, bypassing step-up authentication pol…
The flaws
- CVE-2026-97791: Race condition (CVSS 7.5 · EPSS 0%)
- CVE-2026-71575: The max_age authentication-freshness check in OidcClientCodeRequestFilter was inoperative due to a… (CVSS 9.1 · EPSS 0%)
- CVE-2026-97468: Apache CXF's STSTokenValidator and Security Token Service (STS) cached validated security tokens… (CVSS 9.1 · EPSS 0%)
- CVE-2026-107938: In Apache CXF, the Netty-based HTTP client transport (cxf-rt-transports-http-netty-client) did not… (CVSS 9.1 · EPSS 0%)
The fix
Upgrade Apache Cxf: 4.2.4 · 4.1.9 · 3.6.13 or later on your release line
Who is exposed: Apache Cxf before 4.2.4, 4.1.9, 3.6.13
Where it stands
- No known exploitation
Connects to
- Same weakness: Race condition (CWE-362). 94 other warnings in 30 days
- Same product: Earlier Apache Cxf warnings. 7 in the last 90 days
Why it is Yellow
- CVSS 7.5 high
- Remotely exploitable without logging in
References
Original description
In Apache CXF, STSTokenValidator checks whether a SAML assertion is signed by a trusted certificate before deciding to send it to the STS. That result was stored in one object shared by all requests, so one request could read another's result. A remote, unauthenticated attacker could send a forged assertion signed with an untrusted certificate while legitimate requests were being processed, and it could be accepted as trusted without ever reaching the STS. Only services that use STSTokenValidator to validate SAML tokens without alwaysValidateToSts set are affected. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.
Last activity 9 Oct 2026. Patch Forecast updates every hour.