CVE-2026-69211

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.

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.

Vulnerability in Http4s (a Scala interface for HTTP services) prior to 0.23.35 and 1.0.0-M47. When Ember receives an HTTP/2 HEADERS or PUSH_PROMISE frame without END_HEADERS, H2Connection buffers the header block and subsequent CONTINUATION fragments without a size bound, allowing a remote peer to exhaust heap memory.

Vulnerability in Http4s prior to 0.23.35 and 1.0.0-M47. Ember's HTTP/1.1 parser accepts differing duplicate Content-Length headers and uses the last value instead of rejecting the message, enabling CL.CL request smuggling.

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, the CookieJar client middleware uses unanchored substring checks instead of RFC 6265 domain and path matching. Consequently, a cookie for example.com can be sent to an attacker-controlled hostname such as evilexample.com.

Vulnerability in Http4s prior to 0.23.35 and 1.0.0-M47. WebSocket FrameTranscoder.bodyLength rejects extended payload lengths above Integer.MAX_VALUE but permits negative 64-bit lengths, allowing a remote client to send a frame that causes an infinite decode loop and resource exhaustion.

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, DigestAuth replay protection records lastNc plus one instead of the highest nonce-count value it has accepted. When a legitimate client sends noncontiguous nc values due to parallel or retried requests, the stored counter remains below the accepted maximum, allowing a passive observer to replay a captured Authorization header multiple times.

Vulnerability in Http4s prior to 0.23.35 and 1.0.0-M47. Ember's HeaderP.parse uses a case-sensitive substring test for the Transfer-Encoding value and decodes header bytes with the platform default charset, leading to disagreement with RFC-compliant intermediaries and enabling TE.CL or TE.0 request smuggling.

In Http4s, an Ember server with HTTP/2 enabled does not enforce SETTINGS_MAX_CONCURRENT_STREAMS for peer-created streams. A single unauthenticated connection can open an unbounded number of streams, each retaining per-stream state until heap exhaustion. The same unchecked allocation is reachable in ember-client via server-initiated PUSH_PROMISE frames because enablePush is not enforced. Fixed in versions 0.23.35 and 1.0.0-M47.

In Http4s, Ember's HTTP/2 flow-control window is replenished based on bytes received from the network rather than bytes consumed by the application, while each stream stores DATA in an unbounded channel. A hostile peer can send a body faster than a slow or non-draining application consumes it, retaining payloads in heap on an ember-server or ember-client configured with withHttp2. The patch bounds the per-stream H2Connection body channel so application consumption applies backpressure. Fixed in versions 0.23.35 and 1.0.0-M47.