CVE-2026-69215

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.

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.

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember's chunk decoder trims the chunk-size token and accepts leading plus or minus signs instead of requiring one or more hexadecimal digits followed by the required CRLF. When an intermediary forwards chunked data without re-encoding and interprets malformed chunk boundaries differently, an unauthenticated attacker can create TE.TE request smuggling that bypasses intermediary controls, poisons caches, or hijacks the request queue.

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, the CookieJar client middleware stores a response cookie's Domain attribute without checking that it domain-matches the host that supplied the cookie or rejecting public suffixes. A malicious or compromised server contacted through the same CookieJar can plant a cookie for another domain, and the jar later sends that cookie to the victim domain, enabling session fixation or overwriting security-sensitive cookies.