CVE-2026-69204

http4s Ember's HTTP/1.1 implementation fails to reject messages that contain both a Transfer-Encoding and a Content-Length header, allowing request-smuggling (CL.TE/TE.CL) desynchronization between an intermediary and the Ember backend. An unauthenticated attacker can exploit an ember-server deployed behind a keep-alive intermediary that forwards both headers to smuggle a second request, bypass the intermediary's access controls, poison caches, or prepend attacker-controlled data to a victim's request. The shared response parser also lets a malicious or compromised upstream desynchronize an ember-client connection, exposing downstream consumers. Affected deployments are those running http4s versions prior to 0.23.35 or 1.0.0-M47 with the Ember backend; the flaw is fixed in 0.23.35 and 1.0.0-M47. There is no known public PoC, no CISA KEV listing, and no evidence of in-the-wild exploitation at this time, though the 9.2 CVSS score reflects the severity when the deployment pattern (proxy + Ember) is present.

What to do: Upgrade http4s to 0.23.35 (0.23.x line) or 1.0.0-M47 (1.0 milestone line) or later as soon as possible. As a defense-in-depth measure, configure fronting proxies/load balancers (nginx, HAProxy, cloud LBs) to normalize requests by stripping or rejecting any request carrying both Transfer-Encoding and Content-Length rather than forwarding both. Review intermediary and origin logs for anomalous responses, unexpected 4xx responses on legitimate requests, or byte-count mismatches that could indicate prior smuggling attempts.