CVE-2026-69204: Http4s: Ember accepts Transfer-Encoding combined with Content-Length (CL.TE request smuggling)
Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember HTTP/1.1 does not reject messages containing both Transfer-Encoding and Content-Length, so an intermediary and Ember can select different body framing rules. When ember-server is behind a keep-alive intermediary that forwards both headers and frames by Content-Length, an unauthenticated attacker can smuggle a second request, bypass intermediary access controls, poison caches, or cause a victim request to be joined to an attacker-controlled prefix. The shared response parser can also desynchronize an ember-client connection when a malicious or compromised upstream sends both headers. This issue is fixed in versions 0.23.35 and 1.0.0-M47.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
http4s/emberto a version that resolves this vulnerability.Fixed in 0.23.35 - Upgrade
Upgrade
http4s/emberto a version that resolves this vulnerability.Fixed in 1.0.0-M47
Event History
Frequently Asked Questions
Which deployments are exposed to request smuggling?
Ember HTTP/1.1 servers are exposed when they sit behind a keep-alive intermediary that forwards both Transfer-Encoding and Content-Length headers and uses Content-Length to frame requests. In that configuration, an unauthenticated attacker may smuggle a second request and potentially bypass intermediary controls or poison caches.
Are outbound Ember client connections affected too?
Yes. The shared response parser can desynchronize an ember-client connection if a malicious or compromised upstream server sends a response containing both Transfer-Encoding and Content-Length.
What versions contain the fix?
The issue is fixed in Http4s versions 0.23.35 and 1.0.0-M47. Versions before those releases are affected according to the advisory.