Http4s Ember Parser Accepts Conflicting Transfer-Encoding and Content-Length Headers, Enabling CL.TE Request Smuggling

A security advisory (GHSA-8h4c-x2wg-6xp8, tracked as CVE-2026-69204) was published on 2026-09-15 for Ember, the HTTP/1.1 server and client implementation in the Scala http4s toolkit. According to the advisory, Ember's request parser does not reject messages that carry both a Transfer-Encoding and a Content-Length header. RFC 9112 §6.1 requires such messages to be treated as a framing error and the connection closed; Ember does not enforce this, and a proof-of-concept is reportedly available.

Why It Matters

The affected components are org.http4s:http4s-ember-core for Scala 2.12, 2.13, and 3. Per the advisory, the primary risk is CL.TE request smuggling when ember-server sits as an origin behind a keep-alive intermediary that forwards both conflicting headers and frames the body by Content-Length while Ember frames by the chunked encoding. Consequences described include bypass of the front-end's ACL/auth checks, cross-user request hijacking when a smuggled prefix concatenates with a subsequent victim's request on a shared backend socket, and response/cache poisoning in caching proxies. The advisory also notes that ember-client shares the same parser on the response path, so a malicious or compromised upstream could desync a pooled client connection — though this requires that upstream to be untrusted or compromised. The server-side smuggling scenario is described as reachable by an unauthenticated remote attacker, contingent on the intermediary's forwarding and framing behavior.

What Defenders Should Do Now

• Inventory services using http4s-ember-core (any Scala 2.12/2.13/3 build) as an HTTP origin behind a reverse proxy, load balancer, or API gateway with backend keep-alive.
• Check whether your intermediary strictly rejects requests carrying both Transfer-Encoding and Content-Length, or instead silently strips one and forwards — the advisory calls this out as the specific condition that enables desync.
• As interim mitigations per the advisory: configure the intermediary to reject dual-header requests outright, have it buffer and fully re-encode request bodies rather than passing them through, or disable keep-alive between the intermediary and Ember.
• For hunting: watch reverse-proxy and WAF logs for requests containing both headers, and look for anomalous request pairing or unexpected response bodies on shared backend connections, which are classic smuggling tells.
• Prioritize patching once an updated Ember release is available, and re-test any WAF/gateway rules that currently permit ambiguous framing.

This is a same-day advisory and the write-up here reflects only what has been published so far; details on affected version ranges, a fix release, and further exploitation specifics may evolve. For the authoritative and most current information, see the original GHSA advisory: GHSA-8h4c-x2wg-6xp8.