CVE-2026-73494: blaze: Multiple HTTP/1.1 request-smuggling primitives in blaze's Java wire parser
blaze is a Scala library for building asynchronous pipelines, with a focus on network IO. Prior to 0.23.18 and from 1.0.0-M1 until 1.0.0-M42, five HTTP/1.1 conformance laxities in the hand-written Java parser under http/src/main/java/org/http4s/blaze/http/parser/ can cause blaze to derive a different request boundary than a stricter fronting intermediary. A default BlazeServerBuilder accepts invalid or valueless header field names that violate tchar syntax, obsolete folded field lines (obs-fold), unsupported Transfer-Encoding values, duplicate Content-Length fields, and requests containing both Transfer-Encoding and Content-Length. If a lenient or legacy proxy forwards the malformed bytes but interprets them differently, the disagreement can permit front-end authorization bypass, response-queue poisoning on pooled backend connections, or cache poisoning. Exploitation requires a pair of disagreeing parsers; no non-default blaze configuration is required. The affected checks are enforced in BodyAndHeaderParser and Http1ServerParser. This issue is fixed in versions 0.23.18 and 1.0.0-M42.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
blazeto a version that resolves this vulnerability.Fixed in 0.23.18 - Upgrade
Upgrade
blazeto a version that resolves this vulnerability.Fixed in 1.0.0-M42
Event History
Frequently Asked Questions
Which deployments are realistically exposed to this issue?
Deployments using affected blaze versions behind a fronting proxy or intermediary are exposed when that component accepts and forwards malformed HTTP/1.1 requests but determines request boundaries differently from blaze. This can affect the default BlazeServerBuilder configuration.
What does an attacker need to exploit the vulnerability?
An attacker needs to send malformed HTTP/1.1 request bytes through a pair of disagreeing parsers: a lenient or legacy front-end intermediary and the blaze backend parser. No authentication or user interaction is required, but exploitation has high attack complexity because the parser discrepancy must be present.
Which malformed request forms are relevant for detection or filtering?
Relevant forms include invalid or valueless header field names, obsolete folded header lines, unsupported Transfer-Encoding values, duplicate Content-Length headers, and requests carrying both Transfer-Encoding and Content-Length. These checks are handled by BodyAndHeaderParser and Http1ServerParser.
What should be done if immediate patching is not possible?
Ensure the fronting intermediary rejects the malformed HTTP/1.1 forms associated with this issue rather than forwarding them to blaze, and avoid routing such traffic through parser combinations that disagree on request boundaries. The permanent fix is to upgrade to 0.23.18 or 1.0.0-M42.