GHSA-GQ9P-F254-H286
Vulnerability from github – Published: 2026-09-15 20:01 – Updated: 2026-09-15 20:01Summary
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_2.13"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_2.12"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.0-M47"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_2.13"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0-M1"
},
{
"fixed": "1.0.0-M48"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.0-M47"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_3"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0-M1"
},
{
"fixed": "1.0.0-M48"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-88975"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-15T20:01:22Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nAn unauthenticated peer can make Ember\u0027s 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\u0027s 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\u0027s 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.\n\n### Details\nH2Frame.RawFrame.fromByteVector (ember-core/.../h2/H2Frame.scala:66-69) reads the length, then refuses to produce a frame until 9 + length bytes are present:\n\n```\nval length = (bv(2) \u0026 0xff) | ((bv(1) \u0026 0xff) \u003c\u003c 8) | ((bv(0) \u0026 0xff) \u003c\u003c 16)\nif (bv.length \u003e= 9 + length) {\n```\n\nreadNextFrame 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.\n\nThe only check of an inbound frame against the connection\u0027s 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.\n\nRFC 9113 4.2 requires treating an oversized frame as a connection error and explicitly permits responding without reading the rest of the payload.\n\n### Impact\nUncontrolled resource consumption leading to unauthenticated remote denial of service by memory exhaustion.\n\n- 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.\n- 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.\n- Not affected: HTTP/2 off, which is the default on both builders.\n\nThe overshoot is not configurable. It comes from the protocol\u0027s length field, not from Ember\u0027s 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.",
"id": "GHSA-gq9p-f254-h286",
"modified": "2026-09-15T20:01:22Z",
"published": "2026-09-15T20:01:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/security/advisories/GHSA-gq9p-f254-h286"
},
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/commit/87cf334fa3f608ef7d3eb359e71e037ba3336d29"
},
{
"type": "PACKAGE",
"url": "https://github.com/http4s/http4s"
},
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/releases/tag/v0.23.37"
},
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/releases/tag/v1.0.0-M48"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Http4s: Ember HTTP/2 buffers a frame\u0027s declared payload before checking SETTINGS_MAX_FRAME_SIZE"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.