CVE-2026-107937
Apache Cxf: denial of service
- Risk score
- 59/100
- CVSS
- 7.5 v3.1
- Exploit chance (30 days)
- 0.6%
- Published
- 9 Oct 2026
Open in the live forecast Today's forecast
What to know
- What it is
- In Apache CXF, the parser for multipart/MTOM attachment part headers did not fully enforce the configured attachment-max-header-size (default 300 characters) and attachment-headers-max-count (default 500) limits. The size limit was applied only to each physical line, not to a header value built from continuation lines…
- 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-107937: Denial of service (CVSS 7.5 · EPSS 1%)
- 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: Denial of service (CWE-770). 202 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, the parser for multipart/MTOM attachment part headers did not fully enforce the configured attachment-max-header-size (default 300 characters) and attachment-headers-max-count (default 500) limits. The size limit was applied only to each physical line, not to a header value built from continuation lines or to the combined values of a repeated header. The count limit was checked against the number of distinct header names, not the total number of header lines. A remote, unauthenticated attacker could send a multipart request with very large folded or repeated part headers. The server would then allocate memory without bound, causing a denial of service. 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.