CVE-2026-69218: Http4s HTTP/2 Memory Exhaustion DOS Vulnerability

CVE-2026-69218 Overview

CVE-2026-69218 is an unbounded resource allocation vulnerability [CWE-770] in Http4s, a Scala interface for HTTP services. The flaw affects the Ember server and client components when configured with HTTP/2 support via withHttp2. When Ember receives an HTTP/2 HEADERS or PUSH_PROMISE frame without the END_HEADERS flag, the H2Connection buffers the header block and subsequent CONTINUATION fragments without any size bound. A remote peer can hold an incomplete header block open and exhaust heap memory before request decoding completes. The issue affects Http4s versions prior to 0.23.35 and 1.0.0-M47.

Critical Impact
A remote unauthenticated attacker can trigger heap memory exhaustion in ember-server or ember-client instances configured with HTTP/2, resulting in denial of service.

Affected Products

Http4s ember-server with withHttp2 enabled, prior to 0.23.35
Http4s ember-client with withHttp2 enabled, prior to 0.23.35
Http4s 1.0.0 milestone releases prior to 1.0.0-M47

Discovery Timeline

2026-09-15 - CVE-2026-69218 published to NVD
2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-69218

Vulnerability Analysis

The vulnerability resides in the HTTP/2 frame processing logic within H2Connection. HTTP/2 permits header blocks to span multiple frames using CONTINUATION frames when the initial HEADERS or PUSH_PROMISE frame lacks the END_HEADERS flag. Ember's implementation accepted these fragments into an internal buffer without enforcing a cumulative size cap. An attacker can open a stream, send a HEADERS frame without END_HEADERS, then transmit an indefinite sequence of CONTINUATION frames containing arbitrary payload bytes. Because the buffer grows unbounded and the connection remains open pending completion, memory usage climbs until the Java Virtual Machine (JVM) heap is exhausted.

Root Cause

The underlying defect is a missing enforcement of SETTINGS_MAX_HEADER_LIST_SIZE during the accumulation of CONTINUATION frame payloads. Neither the peer-declared header size limit nor a receive timeout was applied to partial header blocks, allowing indefinite growth. This classifies as Allocation of Resources Without Limits or Throttling [CWE-770].

Attack Vector

Exploitation requires network reachability to an Ember endpoint negotiating HTTP/2. No authentication or user interaction is needed. The attacker establishes an HTTP/2 connection, sends a HEADERS frame with END_HEADERS unset, then streams CONTINUATION frames of maximum permitted payload size. A single connection or a small number of parallel connections can consume server heap and terminate the process.

text

// Security patch from ember-client EmberClientBuilder.scala
// Source: https://github.com/http4s/http4s/commit/6e8eccd64a6a74ab4811897881e95e0e1b3a818e
+        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,
         )

The patch derives SETTINGS_MAX_HEADER_LIST_SIZE from EmberClientBuilder.maxResponseHeaderSize (and EmberServerBuilder.maxHeaderSize for the server), tracks accumulated header block size, sends a GOAWAY frame when the limit is exceeded, and applies receiveHeadersTimeout to incomplete blocks. A second commit propagates the idle timeout into the H2 connection constructor:

text

// Source: https://github.com/http4s/http4s/commit/f9dcca4f5a17992ac0972fafd7920f9bc12cdc51
       } yield new H2Connection(
         socketAdd,
         H2Connection.ConnectionType.Client,
-        Duration.Inf,
+        idleTimeout,
         idleTimeout,
         localSettings,
         ref,

Detection Methods for CVE-2026-69218

Indicators of Compromise

Sustained memory growth in JVM processes hosting Ember HTTP/2 endpoints without corresponding request throughput.
HTTP/2 connections that transmit repeated CONTINUATION frames without ever setting END_HEADERS.
OutOfMemoryError exceptions in application logs originating from org.http4s.ember.core.h2 classes.
Long-lived HTTP/2 streams in open or half-closed state with no header decode completion.

Detection Strategies

Inspect HTTP/2 traffic at the network layer for anomalous ratios of CONTINUATION frames to HEADERS frames per stream.
Monitor JVM heap metrics via Java Management Extensions (JMX) or Micrometer for abrupt heap saturation on Ember services.
Enable HTTP/2 frame-level logging on staging environments to baseline normal header block sizes.

Monitoring Recommendations

Alert on Ember service memory utilization exceeding 85% of allocated heap for more than 60 seconds.
Track counts of connections closed with GOAWAY frames after applying the patch, which indicates active abuse attempts.
Correlate source IP addresses generating repeated HTTP/2 protocol errors for potential blocklisting.

How to Mitigate CVE-2026-69218

Immediate Actions Required

Upgrade Http4s Ember modules to 0.23.35 on the 0.23.x line or to 1.0.0-M47 on the 1.0.0 milestone line.
Audit deployed services for EmberServerBuilder.withHttp2 or EmberClientBuilder.withHttp2 configurations and prioritize their remediation.
Place an HTTP/2-aware reverse proxy in front of exposed Ember services if immediate patching is not feasible.

Patch Information

The fix is delivered in Http4s v0.23.35 and v1.0.0-M47. Technical details are documented in GitHub Security Advisory GHSA-cp4q-fqw9-4hf6. The remediation is implemented across commit 6e8eccd and commit f9dcca4.

Workarounds

Disable HTTP/2 by removing the withHttp2 builder call and serve traffic over HTTP/1.1 until patching is complete.
Terminate TLS and HTTP/2 at a hardened intermediary such as a load balancer that enforces SETTINGS_MAX_HEADER_LIST_SIZE and per-stream frame limits.
Reduce configured maxHeaderSize on EmberServerBuilder and maxResponseHeaderSize on EmberClientBuilder to constrain post-patch header buffer size.

bash

# Update sbt build definition to a patched Http4s version
libraryDependencies ++= Seq(
  "org.http4s" %% "http4s-ember-server" % "0.23.35",
  "org.http4s" %% "http4s-ember-client" % "0.23.35"
)