Http4s’s Ember HTTP/2 implementation parses a frame’s declared 24-bit length but delays buffering the payload until after it compares that length with SETTINGS_MAX_FRAME_SIZE. An unauthenticated peer can declare a payload almost 16 MiB on a connection that has advertised a maximum of 16 KiB. Because the payload is buffered before the size check, the process can consume up to 1024-fold more memory than intended, leading to a denial-of-service condition. This flaw is an instance of uncontrolled resource consumption (CWE-400).

The vulnerability affects any project that incorporates the http4s library and uses Ember’s shared HTTP/2 read loop, whether as a server or client. Versions prior to 0.23.37 and 1.0.0-M48 are vulnerable, while HTTP/2-disabled configurations are unaffected.

The CVSS score of 7.5 indicates a high severity issue. The EPSS score of <1% indicates a very low but nonzero exploitation probability. The CVE description explicitly states that an unauthenticated peer can declare a payload near 16 MiB on a connection where Ember advertised 16 KiB, causing memory amplification before the frame is rejected. This implies that an attacker who can initiate an HTTP/2 connection could exploit this flaw; this inference is based on the description. The vulnerability is not listed in the CISA KEV catalog. The patch introduced in versions 0.23.37 and 1.0.0-M48 rejects oversized frames before buffering their payloads, eliminating the amplification vector.