Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-09-14T18:19:58.857Z",
  "pubdate": "2026-09-14T18:19:58.857Z",
  "executiveSummary": "Blaze, a Scala-based asynchronous network IO library, is susceptible to HTTP request smuggling vulnerabilities due to non-conformant parsing logic in its HTTP/1.1 implementation.\nThe vulnerability stems from lax request boundary validation, where the parser disagrees with fronting intermediaries regarding message framing and headers.\nThis mismatch allows attackers to inject malformed HTTP requests that are interpreted differently by the frontend proxy and the backend Blaze server.\nThe primary risk implications include cross-protocol request smuggling, authorization bypass, cache poisoning, and response-queue poisoning on pooled connections.\nAffected products include versions prior to 0.23.18 and versions 1.0.0-M1 through 1.0.0-M42. Exploitation is possible without specialized configurations, provided there is a disparity between the security parsing logic of the proxy and the Blaze server.\nAttackers can leverage this to manipulate backend state or bypass security controls enforced at the edge.",
  "technicalDetails": "The vulnerability exists within the hand-written Java parser located in http/src/main/java/org/http4s/blaze/http/parser/, specifically affecting the BodyAndHeaderParser and Http1ServerParser classes.\nThe root cause is a failure to enforce strict HTTP/1.1 conformance regarding header field syntax and request framing, specifically: acceptance of non-tchar characters in header field names, support for obsolete folded field lines (obs-fold), handling of unsupported Transfer-Encoding values, improper processing of duplicate Content-Length headers, and ambiguous handling of requests containing both Transfer-Encoding and Content-Length headers.\nExploitation follows the standard HTTP Request Smuggling (HRS) pattern, characterized by a desynchronization between a fronting intermediary and the backend Blaze instance. By sending a crafted request that leverages these protocol laxities, an attacker can influence how the Blaze server identifies the termination point of an HTTP message.\nWhen a frontend proxy and the Blaze backend disagree on the request length, the remaining bytes of a malicious request may be treated as the start of a subsequent request by the backend. This allows for 'request smuggling,' where the injected part of the request is prepended to the next legitimate request arriving on the same connection.\nThe attack flow typically involves: 1. Identification of the parsing discrepancy between the proxy and the Blaze parser. 2. Crafting a request that uses ambiguous headers (e.g., conflicting Transfer-Encoding and Content-Length) that the proxy ignores but Blaze consumes. 3. The frontend proxy forwards the request as a single unit, while Blaze interprets it as two separate messages or a message with an altered boundary. 4. The smuggled segment executes within the context of the next authorized user or system operation.\nThis vulnerability is particularly dangerous in load-balanced or proxied environments where HTTP/1.1 keep-alive connections are maintained. Because the parser accepts invalid header syntax, it fails to reject packets that should be considered malformed, thereby violating the fundamental security assumptions of the HTTP protocol regarding request isolation. The lack of strict validation on Transfer-Encoding allows for smuggling techniques that bypass simple content-length filters."
}