CVE-2026-88975: Http4s: Ember HTTP/2 buffers a frame's declared payload before checking SETTINGS_MAX_FRAME_SIZE
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.
References
- github.com/advisories/GHSA-gq9p-f254-h286
- github.com/http4s/http4s/commit/87cf334fa3f608ef7d3eb359e71e037ba3336d29
- github.com/http4s/http4s/releases/tag/v0.23.37
- github.com/http4s/http4s/releases/tag/v1.0.0-M48
- github.com/http4s/http4s/security/advisories/GHSA-gq9p-f254-h286
- nvd.nist.gov/vuln/detail/CVE-2026-88975
Code Behaviors & Features
Detect and mitigate CVE-2026-88975 with GitLab Dependency Scanning
Secure your software supply chain by verifying that all open source dependencies used in your projects contain no disclosed vulnerabilities. Learn more about Dependency Scanning →