CVE-2026-69209: Http4s WebSocket DOS Vulnerability

CVE-2026-69209 Overview

CVE-2026-69209 is a denial-of-service vulnerability in http4s, a Scala interface for HTTP services. The shared WebSocket decoder in versions prior to 0.23.35 and 1.0.0-M47 permits unbounded message buffering. Defragmentation accumulates fragments without any size limit, and FrameTranscoder accepts declared frame lengths up to Int.MaxValue. A remote client that completes a WebSocket handshake against an http4s-blaze-server or http4s-ember-server endpoint can exhaust server memory using oversized frames or fragmented messages. The weakness is classified as [CWE-400] Uncontrolled Resource Consumption.

Critical Impact
Unauthenticated remote attackers can exhaust server memory by sending oversized or fragmented WebSocket frames, causing service-wide denial of service.

Affected Products

http4s versions prior to 0.23.35
http4s versions prior to 1.0.0-M47
Deployments using http4s-blaze-server or http4s-ember-server with WebSocket endpoints

Discovery Timeline

2026-09-15 - CVE-2026-69209 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-69209

Vulnerability Analysis

The vulnerability resides in the http4s WebSocket implementation shared across server backends. The FrameTranscoder component parses incoming WebSocket frames and honors declared payload lengths without enforcing any upper bound. In parallel, the defragmentation logic buffers continuation frames into a single logical message without capping cumulative size.

A remote client only needs to complete the WebSocket handshake against an exposed endpoint. Once the connection is established, the client can advertise very large frame lengths or stream an unbounded sequence of continuation frames. The server allocates memory to satisfy these declared or accumulated sizes, driving the JVM toward memory exhaustion and process termination.

Root Cause

Two compounding issues drive the bug. First, getMsgLength in FrameTranscoder.scala accepted length fields up to Int.MaxValue without reference to any configured maximum. Second, the defragmentation path concatenated fragments without a ceiling. The patch introduces a DefaultMaxMessageSize constant of 64 MiB and threads a maxFrameSize parameter through the decoder path.

Attack Vector

Exploitation requires network reachability to a WebSocket endpoint but no authentication or user interaction. An attacker completes the WebSocket upgrade, then either sends a single frame with an inflated declared length or streams a long chain of continuation frames. A small number of concurrent connections can exhaust heap memory on the target server.

text

// Patch excerpt: core/shared/src/main/scala/org/http4s/websocket/FrameTranscoder.scala
     } else throw new FrameTranscoder.TranscodeError("Length error")
   }
 
-  private def getMsgLength(in: ByteBuffer) = {
+  private def getMsgLength(in: ByteBuffer, maxFrameSize: Int) = {
     var totalLen = 2
     if ((in.get(1) & MASK) != 0) totalLen += 4

// Patch excerpt: core/shared/src/main/scala/org/http4s/websocket/package.scala
       case _ =>
         throw new UnknownOpcodeException(opcode)
     }
+
+  private[http4s] val DefaultMaxMessageSize: Int = 64 * 1024 * 1024
 }

Source: GitHub Commit d578c3c

Detection Methods for CVE-2026-69209

Indicators of Compromise

Sudden JVM heap growth on http4s servers correlated with WebSocket upgrade requests from a single or small set of client IPs.
OutOfMemoryError exceptions in application logs following WebSocket traffic bursts.
WebSocket connections receiving unusually large declared frame lengths approaching Int.MaxValue.
Long sequences of continuation frames without a terminating FIN frame on a single connection.

Detection Strategies

Instrument WebSocket handlers to log frame length headers and continuation counts per connection.
Compare deployed http4s dependency versions against 0.23.35 and 1.0.0-M47 in build manifests and software bill of materials.
Monitor JVM metrics for abnormal allocation rates tied to WebSocket-handling threads.

Monitoring Recommendations

Alert on repeated TranscodeError or memory-related exceptions originating from org.http4s.websocket packages.
Track per-client connection duration, byte counts, and fragment counts on WebSocket endpoints.
Ingest application and JVM telemetry into a centralized analytics platform to correlate resource-exhaustion patterns with source IPs.

How to Mitigate CVE-2026-69209

Immediate Actions Required

Upgrade http4s to version 0.23.35 or 1.0.0-M47 across all services exposing WebSocket endpoints.
Configure EmberServerBuilder.withMaxWebSocketMessageSize to a value appropriate for your workload, using the 64 MiB default as a starting point.
Inventory services using http4s-blaze-server and http4s-ember-server and prioritize internet-exposed deployments.

Patch Information

The fix is delivered in GitHub Release v0.23.35 and GitHub Release v1.0.0-M47. See GitHub Security Advisory GHSA-jrxx-w2m8-5hf5 for the full advisory. The patched decoder enforces a configurable 64 MiB default limit on individual frames and defragmented messages.

Workarounds

Place a reverse proxy or WebSocket-aware gateway in front of http4s services and enforce message size limits at that layer.
Restrict WebSocket endpoints to authenticated clients and apply per-client connection and rate limits.
Disable WebSocket routes that are not required until patched versions can be deployed.

bash

# Configuration example: update sbt dependency to a patched version
libraryDependencies += "org.http4s" %% "http4s-ember-server" % "0.23.35"

# Apply a WebSocket message size limit when building the server
# EmberServerBuilder
#   .default[IO]
#   .withMaxWebSocketMessageSize(64 * 1024 * 1024)
#   .build