CVE-2026-88975
HighCVSS 7.5Summary
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.
Risk Assessment
The risk includes memory exhaustion on the server or client, which could lead to denial of service and disruption of application functionality.
Recommendation
Update Http4s to version 0.23.37 or 1.0.0-M48 (or later) and implement HTTP/2 frame size limits.
Other vulnerabilities in Http4s
See all- CVE-2026-69218High
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.
- CVE-2026-69217High
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.
- CVE-2026-69210High
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.
- CVE-2026-69205High
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.
- CVE-2026-69204Critical
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.
- 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.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.