Summary
Http4s: Ember HTTP/2 buffers a frame's declared payload before checking SETTINGSMAXFRAME_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.
Details
H2Frame.RawFrame.fromByteVector (ember-core/.../h2/H2Frame.scala:66-69) reads the length, then refuses to produce a frame until 9 + length bytes are present:
val length = (bv(2) & 0xff) | ((bv(1) & 0xff) << 8) | ((bv(0) & 0xff) << 16)
if (bv.length >= 9 + length) {
readNextFrame in H2Connection.readLoop (H2Connection.scala:246-266) reads that None as "need more" and concatenates further socket reads into one accumulator until it is satisfied.
The only check of an inbound frame against the connection's own SETTINGS_MAX_FRAME_SIZE is in processFrame at H2Connection.scala:534, which cannot run until the frame is assembled. So the value that condemns the frame sits in the accumulator from byte 9 onward and is never consulted. A peer that declares 16777215 and dribbles the payload without finishing gets the same buffering with no reaction at all, since an incomplete frame never reaches processFrame.
RFC 9113 4.2 requires treating an oversized frame as a connection error and explicitly permits responding without reading the rest of the payload.
Impact
Uncontrolled resource consumption leading to unauthenticated remote denial of service by memory exhaustion.
- ember-server built .withHttp2: any peer able to open an HTTP/2 connection can trigger it. No authentication and no valid request, since the frame is rejected before it is associated with a stream, and the incomplete variant is never rejected.
- ember-client built .withHttp2 against a hostile origin: readLoop is shared, so the client side is symmetric. Reasoned from the shared code path, not reproduced.
- Not affected: HTTP/2 off, which is the default on both builders.
The overshoot is not configurable. It comes from the protocol's length field, not from Ember's limit, so tuning SETTINGS_MAX_FRAME_SIZE down does not reduce exposure, and withIdleTimeout does not apply because the read loop is making steady progress. Workarounds: leave HTTP/2 off, or terminate it at a proxy that enforces frame size and speak HTTP/1.1 to Ember.
Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.
CVE-2026-88975 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.23.37, 1.0.0-M48); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
org.http4s:http4s-ember-core_2.13 to 0.23.37 or later; org.http4s:http4s-ember-core_2.12 to 0.23.37 or later; org.http4s:http4s-ember-core_3 to 0.23.37 or later; org.http4s:http4s-ember-core_2.13 to 1.0.0-M48 or later; org.http4s:http4s-ember-core_3 to 1.0.0-M48 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-88975? CVE-2026-88975 is a high-severity uncontrolled resource consumption vulnerability in org.http4s:http4s-ember-core_2.13 (maven), affecting versions <= 0.23.36. It is fixed in 0.23.37, 1.0.0-M48. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
- How severe is CVE-2026-88975? CVE-2026-88975 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which packages are affected by CVE-2026-88975?
org.http4s:http4s-ember-core_2.13(maven) (versions <= 0.23.36)org.http4s:http4s-ember-core_2.12(maven) (versions <= 0.23.36)org.http4s:http4s-ember-core_3(maven) (versions <= 0.23.36)
- Is there a fix for CVE-2026-88975? Yes. CVE-2026-88975 is fixed in 0.23.37, 1.0.0-M48. Upgrade to this version or later.
- Is CVE-2026-88975 exploitable, and should I be worried? Whether CVE-2026-88975 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-88975 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-88975?
- Upgrade
org.http4s:http4s-ember-core_2.13to 0.23.37 or later - Upgrade
org.http4s:http4s-ember-core_2.12to 0.23.37 or later - Upgrade
org.http4s:http4s-ember-core_3to 0.23.37 or later - Upgrade
org.http4s:http4s-ember-core_2.13to 1.0.0-M48 or later - Upgrade
org.http4s:http4s-ember-core_3to 1.0.0-M48 or later
- Upgrade