When Ember receives an HTTP/2 HEADERS or PUSH_PROMISE frame without the END_HEADERS flag, it buffers the header block fragment and waits for subsequent CONTINUATION frames. These accumulate unbounded until the connection closes.
A remote, unauthenticated peer can exhaust the heap on any Ember endpoint that has HTTP/2 enabled:
.withHttp2: any HTTP/2 client can trigger this against any reachable path (including paths that return 404). No authentication is required because the attack completes before the request is decoded..withHttp2: a malicious or compromised origin server can trigger this via the response header block. A single in-flight request is sufficient.Memory consumption is bounded only by the attacker's upload bandwidth and the connection lifetime.
EmberServerBuilder configured with .withHttp2.
The fix bounds the accumulated header-block size at SETTINGS_MAX_HEADER_LIST_SIZE (derived from EmberServerBuilder.maxHeaderSize / EmberClientBuilder.maxResponseHeaderSize). When a CONTINUATION frame would push the accumulated block over that limit, the connection is terminated with GOAWAY. The receiveHeadersTimeout additionally bounds how long an incomplete header block may remain open.
.withHttp2) until upgraded (default). It is off by default.{
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-15T20:01:08Z",
"nvd_published_at": null,
"severity": "HIGH"
}