CVE-2026-69204
CriticalCVSS 9.2Summary
Http4s (Ember HTTP/1.1 module) prior to 0.23.35 and 1.0.0-M47 did not reject messages containing both Transfer-Encoding and Content-Length headers. This allows an intermediary and Ember to select different body framing rules, enabling HTTP request smuggling.
Risk Assessment
An unauthenticated attacker can smuggle a second request, bypass intermediary access controls, poison caches, or join a victim request to an attacker-controlled prefix. The shared response parser can also desynchronize an ember-client connection when a malicious upstream sends both headers.
Recommendation
Upgrade Http4s to version 0.23.35 or 1.0.0-M47 (or later). Verify that intermediaries (proxies, load balancers) properly reject messages with both Transfer-Encoding and Content-Length headers.
Other vulnerabilities in Http4s
See all- CVE-2026-88975High
Http4s is a Scala interface for HTTP services. Prior to 0.23.37 and 1.0.0-M48, Ember’s HTTP/2 read loop parses a frame’s 24-bit declared length but waits to buffer the entire payload before comparing it with SETTINGS_MAX_FRAME_SIZE. An unauthenticated peer can declare a payload near 16 MiB on a connection where Ember advertised 16 KiB and either complete or slowly stream it, causing up to 1024-fold memory amplification per connection before processFrame can reject the frame. The shared H2Connection.readLoop affects withHttp2 servers and clients, while HTTP/2-disabled configurations are unaffected, and the patch rejects oversized frames before buffering their payloads. This issue is fixed in versions 0.23.37 and 1.0.0-M48.
- CVE-2026-54556High
Http4s before versions 0.23.35 and 1.0.0-M47 has a DoS vulnerability via HTTP/2 in the Ember backend. The Hpack wrapper does not include indexed headers or per-header overhead in the header size limit, allowing a small block to expand into a large in-memory representation. Multiple malicious connections can exhaust process memory.
Original NVD description (English source)
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.