high · 7.4Jul 24, 2026

http4s-blaze-server HTTP/1.1 Request Smuggling (Multiple Parser Laxities)

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

Blaze's hand-written Java HTTP/1.1 parser accepts several malformed request forms that stricter front-end proxies interpret differently, letting an attacker smuggle hidden requests through a proxy to…

Packageorg.http4s:http4s-blaze-server_2.13
Ecosystemmaven
Affected<= 0.23.17
Fixed in0.23.18

The problem

Blaze's Java wire parser in http/src/main/java/org/http4s/blaze/http/parser/ contains five independent conformance gaps against RFC 7230. These include: accepting bare LF (\n) as a line terminator instead of requiring CRLF (\r\n), tolerating a space before the colon in a header name, accepting header folding (obsolete obs-fold), not rejecting requests that carry both Content-Length and Transfer-Encoding, and accepting obfuscated Transfer-Encoding values (e.g. chunked with trailing whitespace or mixed case).

Any one of these creates a boundary disagreement when a stricter intermediary sits in front of blaze. The result is a classic CTE/CL smuggling primitive: a single TCP stream that the proxy reads as one request but blaze reads as two.

Proof of concept

A working proof-of-concept for this issue in org.http4s:http4s-blaze-server_2.13, with the exact payload below.

http
POST /api/auth-check HTTP/1.1
Host: internal-app
Content-Length: 44
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: internal-app

This is a CL.TE smuggling payload. A strict front-end proxy (nginx, HAProxy) reads the Content-Length header and forwards exactly 44 bytes, treating the whole thing as one POST. Blaze, however, honours the Transfer-Encoding header preferentially, reads the chunked body as ending at the 0\r\n\r\n terminator, and then interprets the trailing GET /admin ... bytes as the start of a second, independent request on the same keep-alive connection.

The five patch commits each add an explicit rejection in the Java parser for one of these laxities: bare LF terminators, obs-fold continuation lines, header names containing spaces before the colon, duplicate Content-Length values, and non-canonical Transfer-Encoding tokens.

Fixing all five closes the disagreement surface without requiring any change to server configuration. No public PoC exists for this advisory; the payload above is derived from the advisory description and the five patch commit subjects (CWE-444 / CL.TE variant).

The fix

Upgrade org.http4s:http4s-blaze-server_2.13 to **0.23.18** (or the equivalent 0.22.x / 1.0.0-Mx series releases that include the same five parser patches). If an immediate upgrade is not possible, deploy exclusively behind an RFC-strict reverse proxy (nginx, HAProxy, Envoy, or AWS ALB) configured to reject or re-serialise malformed HTTP/1.1 requests at the edge before they reach blaze.

Reporter not attributed.

References: [1][2][3][4][5][6]

Related research