CVE-2026-69218

http4s Ember, the native Scala HTTP server and client, fails to limit how much data can accumulate from HTTP/2 CONTINUATION frames that follow a HEADERS or PUSH_PROMISE frame without the END_HEADERS flag, allowing unbounded heap growth until the connection closes. A remote, unauthenticated attacker can send an endless stream of CONTINUATION frames against any reachable path on an Ember server configured with .withHttp2 (even paths returning 404), exhausting memory and crashing or degrading the service; a malicious origin server can likewise exhaust an Ember client's memory via an oversized response header block. The attack completes before the request is decoded, so no authentication or valid path is required, and consumption is limited only by the attacker's bandwidth and connection lifetime. Only deployments that explicitly enabled HTTP/2 via .withHttp2 are affected, since HTTP/2 is off by default; the fix bounds the accumulated header block at SETTINGS_MAX_HEADER_LIST_SIZE and terminates offending connections with GOAWAY. No public proof of concept or in-the-wild exploitation is known, and the flaw is not in the CISA KEV catalog.

What to do: Upgrade to a patched http4s Ember release that enforces SETTINGS_MAX_HEADER_LIST_SIZE (derived from maxHeaderSize / maxResponseHeaderSize) and terminates oversize header blocks with GOAWAY; if an immediate upgrade is not possible, remove .withHttp2 (reverting to the HTTP/1.1 default) or place Ember behind a reverse proxy that terminates HTTP/2 itself and speaks HTTP/1.1 to Ember. Also verify that receiveHeadersTimeout is configured to bound how long an incomplete header block may remain open, and monitor Ember processes for unexpected heap growth.