The vulnerability exists in the Blaze Scala library’s hand‑written Java HTTP/1.1 parser. Five conformance laxities expose Blaze to parse request boundaries differently from upstream proxies or other intermediaries. When a request contains header fields with invalid tchar syntax, obsolete folded lines, unsupported Transfer‑Encoding values, duplicate Content‑Length fields, or both Transfer‑Encoding and Content‑Length, Blaze accepts them while a stricter front‑end may reject or interpret them differently. This mismatch permits request smuggling, which can lead to front‑end authorization bypass, response‑queue poisoning on pooled backend connections, or cache poisoning. The issue is classified as CWE‑444, reflecting improper input validation in an otherwise performance‑directed parser.

The flaw affects every release of the Blaze HTTP server library earlier than version 0.23.18 and all milestone releases from 1.0.0-M1 through 1.0.0-M42. The affected packages are blaze-http_2.13, org.http4s:blaze-http_3, org.http4s:http4s-blaze-server_2.13, and http4s:blaze. It is triggered only when the default BlazeServerBuilder is used with permissive header handling; no proprietary configuration changes are required.

The vulnerability has a CVSS base score of 7.4, indicating high severity. The EPSS score of <1% indicates a very low exploitation probability, and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires a pair of parsers that disagree on request boundary interpretation—typically an upstream proxy or load balancer versus the Blaze backend. Attackers with network access to the front‑end can craft malformed headers to trigger the backend into misinterpreting the request, thereby enabling HTTP request smuggling that can lead to front‑end authorization bypass, response‑queue poisoning on pooled backend connections, or cache poisoning.