CVE-2026-69218

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 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.

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 (versions prior to 0.23.35 and 1.0.0-M47) has a memory exhaustion vulnerability in the Ember HTTP/2 server. An unauthenticated HTTP/2 client can send PING, SETTINGS, or DATA frames that cause the server to enqueue acknowledgments or WINDOW_UPDATE frames faster than they are written, leading to heap memory exhaustion.

Http4s (versions prior to 0.23.35 and 1.0.0-M47) has a memory exhaustion vulnerability in the shared WebSocket decoder. The decoder allows unbounded message buffering because defragmentation accumulates fragments without a limit and FrameTranscoder accepts declared lengths up to Int.MaxValue. A remote client that completes a WebSocket handshake can exhaust server memory.

Http4s (versions prior to 0.23.35 and 1.0.0-M47) has a memory exhaustion vulnerability in the DigestAuth server middleware. Due to an inverted stale-nonce comparison, the middleware does not remove fresh nonces and stops eviction at the first stale nonce. An unauthenticated attacker can repeatedly trigger authentication challenges, causing the persistent nonce map to grow until the JVM exhausts heap memory.

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.