CVE-2026-54556: Http4s Ember Backend HTTP/2 DoS Vulnerability

CVE-2026-54556 Overview

CVE-2026-54556 is a denial of service vulnerability in http4s, a Scala interface for HTTP services. The flaw affects the Ember backend when HTTP/2 is enabled and allows an unauthenticated peer to exhaust process heap memory. The Hpack wrapper in ember-core/shared/src/main/scala/org/http4s/ember/core/h2/Hpack.scala concatenates HEADERS and CONTINUATION frame fragments, then decodes them into a single List. The maxHeaderSize accounting fails to include indexed headers or HPACK per-header overhead. A small compressed header block can expand into a much larger decoded representation held in memory. The issue is fixed in versions 0.23.35 and 1.0.0-M47.

Critical Impact
Unauthenticated remote attackers can exhaust the process heap of http4s Ember servers and clients through crafted HTTP/2 header blocks, causing service outages.

Affected Products

http4s Ember backend prior to 0.23.35 (with HTTP/2 enabled)
http4s Ember backend prior to 1.0.0-M47 (with HTTP/2 enabled)
Ember clients connecting to untrusted HTTP/2 servers

Discovery Timeline

2026-08-26 - CVE-2026-54556 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-54556

Vulnerability Analysis

The vulnerability is a resource exhaustion issue classified under [CWE-409] (Improper Handling of Highly Compressed Data). HTTP/2 uses HPACK, a header compression format that permits static and dynamic table indexing. Small on-the-wire header blocks can decode into significantly larger in-memory representations. The http4s Ember backend enforces a maxHeaderSize limit on incoming header data, but the accounting logic evaluates only the encoded byte size. It does not track expansion from indexed headers or per-header structural overhead once decoded.

An attacker exploits this asymmetry by sending compressed HEADERS and CONTINUATION frames that reference indexed table entries. The decoded List representation held for request processing balloons far beyond the intended memory bound. Concurrent malicious connections multiply the effect, exhausting the JVM heap and forcing the service to fail requests or crash.

Root Cause

The root cause resides in Hpack.scala within ember-core. The wrapper aggregates HEADERS and CONTINUATION fragments before HPACK decompression, then decodes the full block in one pass. Size enforcement measures the compressed input rather than the decoded output. Indexed header references and HPACK bookkeeping overhead are excluded from the cap, allowing a bounded compressed payload to produce an unbounded decoded structure.

Attack Vector

The attack is network-based, requires no authentication, and needs no user interaction. Any HTTP/2 peer reachable by an Ember server, or any hostile HTTP/2 server contacted by an Ember client, can send crafted header frames. Repeated or concurrent connections amplify heap pressure until the process becomes unresponsive.

text

// Patch excerpt: EmberClientBuilder now advertises SETTINGS_MAX_HEADER_LIST_SIZE
// and threads maxResponseHeaderSize into H2Client.impl
val settings = default.copy(
  enablePush = enablePushPromise,
  maxHeaderListSize =
    Some(H2Frame.Settings.SettingsMaxHeaderListSize(maxResponseHeaderSize)),
)

H2Client.impl[F](
  pushPromiseSupport.getOrElse { case (_, _) => Applicative[F].pure(Outcome.canceled) },
  context,
  logger,
  idleConnectionTime,
  settings,
  checkEndpointIdentification,
  serverNameIndication,
)
// Source: https://github.com/http4s/http4s/commit/6e8eccd64a6a74ab4811897881e95e0e1b3a818e

Detection Methods for CVE-2026-54556

Indicators of Compromise

Sudden JVM heap growth or OutOfMemoryError events in Ember server logs correlated with HTTP/2 traffic.
Concurrent HTTP/2 connections from a single peer transmitting oversized header blocks or long CONTINUATION frame chains.
Increased garbage collection pauses and request latency without proportional throughput increases.

Detection Strategies

Inspect HTTP/2 traffic for anomalous ratios of CONTINUATION frames per stream and abnormally large decoded header lists.
Monitor http4s Ember process metrics for heap saturation immediately following new HTTP/2 stream initialization.
Enumerate deployed http4s versions across the fleet and flag any Ember backend prior to 0.23.35 or 1.0.0-M47 with HTTP/2 enabled.

Monitoring Recommendations

Emit application metrics for peak header list size, CONTINUATION frame count, and per-connection header memory usage.
Alert on repeated connection resets or stream errors returned with HTTP/2 ENHANCE_YOUR_CALM or COMPRESSION_ERROR codes.
Track upstream reverse proxy logs for clients that trigger 431 Request Header Fields Too Large or comparable rejections.

How to Mitigate CVE-2026-54556

Immediate Actions Required

Upgrade http4s Ember to 0.23.35 or 1.0.0-M47 in all services and clients that use HTTP/2.
Audit Ember client code paths that connect to third-party HTTP/2 endpoints, since malicious servers can trigger the same condition.
Constrain exposure by placing untrusted HTTP/2 traffic behind a hardened reverse proxy that enforces header list limits.

Patch Information

The fix is available in http4s 0.23.35 and 1.0.0-M47. The patch adds SETTINGS_MAX_HEADER_LIST_SIZE advertisement, threads maxResponseHeaderSize and idle connection timeouts through the HTTP/2 client, and revises Hpack and H2Stream state handling to enforce size limits during decode. See the GitHub Security Advisory GHSA-vmm3-xgcx-67hm, release v0.23.35, and release v1.0.0-M47 for release notes.

Workarounds

Disable HTTP/2 on Ember servers and clients until upgrades are deployed.
Terminate HTTP/2 at a front-end proxy such as nginx or Envoy that enforces strict header size limits before forwarding as HTTP/1.1 to Ember.
Apply per-source connection and rate limits at the network edge to reduce concurrent attacker capacity.

bash

# Example: enforce HTTP/2 header limits at an Envoy front-end
# envoy.yaml (excerpt)
http2_protocol_options:
  max_concurrent_streams: 100
  max_request_headers_kb: 32
  initial_stream_window_size: 65536
  initial_connection_window_size: 1048576