fkie_cve-2026-88975

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.

GHSA-gq9p-f254-h286 — Http4s: Ember HTTP/2 buffers a frame's declared payload before checking SETTINGS_MAX_FRAME_SIZE

Affected: Maven: org.http4s:http4s-ember-core_2.13, Maven: org.http4s:http4s-ember-core_2.12, Maven: org.http4s:http4s-ember-core_3

### Summary An unauthenticated peer can make Ember's HTTP/2 read loop hold 16 MiB of a single frame in memory on a connection where Ember advertised a 16 KiB limit. The declared length is readable from the frame's first 9 bytes, but it is not compared against SETTINGS_MAX_FRAME_SIZE until the whole payload has been read into a contiguous buffer. That is 1024x amplification per connection, bounded by the protocol's 24-bit length field rather than by any setting, and at the default maxConnections of 1024 it puts about 16 GiB of heap in reach.

### Details H2Frame.RawFrame.fromByteVector (ember-core/.../h2/H2Frame.scala:66-69) reads the length, then refuses to produce a frame until 9 + length bytes are present:

``` val length = (bv(2) & 0xff) | ((bv(1) & 0xff) << 8) | ((bv(0) & 0xff) << 16) if (bv.length >= 9 + length) { ```

readNextFrame in H2Connection.readLoop (H2Connection.scala:246-266) reads that None as "need more" and concatenates further socket reads into one accumulator until it is satisfied.

The only check of an inbound frame against the connection's own SETTINGS_MAX_FRAME_SIZE is in processFrame at H2Connection.scala:534, which cannot run until the frame is assembled. So the value that condemns the frame sits in the accumulator from byte 9 onward and is never consulted. A peer that declares 16777215 and dribbles the payload without finishing gets the same buffering with no reaction at all, since an incomplete frame never reaches processFrame.

RFC 9113 4.2 requir…

Most recent entries from all

fkie_cve-2026-88975

GHSA-gq9p-f254-h286 — Http4s: Ember HTTP/2 buffers a frame's declared payload before checking SETTINGS_MAX_FRAME_SIZE