CVE-2026-88975

http4s Ember's HTTP/2 implementation buffers a frame's entire declared payload — up to 16 MiB, bounded only by the protocol's 24-bit length field — into contiguous memory before checking it against the advertised SETTINGS_MAX_FRAME_SIZE (16 KiB), because the validation in processFrame cannot run until the frame is fully assembled. An unauthenticated attacker triggers it simply by opening an HTTP/2 connection and declaring an oversized frame; no request, stream association, or credentials are required, and dribbling the payload without finishing evades rejection entirely since incomplete frames never reach validation. The result is uncontrolled resource consumption and remote denial of service by memory exhaustion — roughly 16 GiB of heap within reach at the default 1024 maxConnections — and the client side is symmetric because ember-client's readLoop shares the same code path. Only deployments explicitly built with .withHttp2 on ember-server or ember-client are affected; HTTP/2 is off by default on both builders. No public PoC exists, the CVE is not in CISA's KEV, and no exploitation in the wild is known.

What to do: Upgrade to a patched http4s release as soon as one is published (track http4s security advisories for CVE-2026-88975), since the flaw sits in ember-core's H2Frame/H2Connection read loop and cannot be fixed in application code. Until then, disable HTTP/2 on Ember (it is off by default) or terminate HTTP/2 at a reverse proxy that enforces frame-size limits and speak HTTP/1.1 to the backend. Note that lowering SETTINGS_MAX_FRAME_SIZE or setting withIdleTimeout provides no mitigation — the check runs only after buffering and dribbled frames make steady read progress — so also monitor heap usage on any HTTP/2 listeners you cannot yet disable.