CVE-2026-73493: Http4s Blaze Server DoS Vulnerability

CVE-2026-73493 Overview

CVE-2026-73493 is a denial of service vulnerability in http4s-blaze-server, a Scala HTTP server component of the http4s project. The flaw affects versions prior to 0.23.18 and 1.0.0-M42. The server aggregates incoming WebSocket message fragments without enforcing a limit on total aggregate size or fragment count. A remote client that completes a WebSocket handshake can send an unterminated fragmented message and drive unbounded Java Virtual Machine (JVM) heap growth. The result is an OutOfMemoryError that terminates the blaze selector thread and the server process. The weakness is classified as [CWE-770] Allocation of Resources Without Limits or Throttling.

Critical Impact
A single unauthenticated WebSocket client can exhaust server heap memory and crash the JVM, causing full service outage for any http4s application serving WebSocket routes over BlazeServerBuilder.

Affected Products

http4s-blaze-server versions prior to 0.23.18
http4s-blaze-server 1.0.0 milestone releases prior to 1.0.0-M42
Any http4s application exposing WebSocket routes through BlazeServerBuilder in default configuration

Discovery Timeline

2026-08-12 - CVE-2026-73493 published to the National Vulnerability Database (NVD)
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-73493

Vulnerability Analysis

The vulnerability resides in the WebSocket frame aggregator used by http4s-blaze-server. The RFC 6455 WebSocket protocol permits messages to be split across continuation frames, where only the final frame carries the FIN bit. The blaze aggregator buffers every continuation frame into memory until a frame with FIN is received. Prior to the patch, no upper bound existed on the aggregate payload size or the number of fragments accepted per message. The maxWebSocketBufferSize setting bounds only individual frame size and does not constrain the aggregate. A client can therefore hold a single logical message open indefinitely while streaming continuation frames.

Root Cause

The WSFrameAggregator in blaze-core accumulated fragment payloads without validating cumulative size. The absence of a MessageTooLarge check meant that heap allocations grew linearly with the volume of received continuation frames. Small fragments amplify the impact through per-frame object overhead in the JVM, so a modest volume of wire bytes produces disproportionate heap pressure.

Attack Vector

An unauthenticated remote attacker completes a normal WebSocket handshake to any exposed WebSocket route. The attacker then sends continuation frames with the FIN bit cleared and never terminates the message. The server buffers each fragment until heap exhaustion triggers an OutOfMemoryError on the blaze selector thread, halting the JVM.

scala

         case t: UnknownOpcodeException =>
           F.delay(logger.error(t)("Decoded a websocket frame with an unknown opcode")) *>
             F.fromEither(Close(1002))
+        case t: WebSocketMessageTooLargeException =>
+          F.delay(logger.error(t)("Aggregated websocket message exceeds size limit")) *>
+            F.fromEither(Close(1009))
         case t: ProtocolException =>
           F.delay(logger.error(t)("Websocket protocol violation")) *> F.fromEither(Close(1002))
       }

Source: GitHub commit 173e8ca. The patch introduces WebSocketMessageTooLargeException handling in Http4sWSStage.scala and maps oversized aggregated messages to a WebSocket Close(1009) ("Message Too Big") response.

Detection Methods for CVE-2026-73493

Indicators of Compromise

Sudden JVM termination accompanied by java.lang.OutOfMemoryError: Java heap space in application or systemd logs
Long-lived WebSocket connections from a single client sending continuous continuation frames without a FIN-terminated message
Rapid growth in JVM heap usage metrics correlated with a small number of active WebSocket sessions
Crashes on the blaze selector thread visible in thread dumps or crash reports

Detection Strategies

Instrument WebSocket handlers to log per-connection cumulative payload size and fragment counts
Monitor JVM heap allocation rate and garbage collection pressure using JMX or a metrics exporter such as Micrometer
Alert when a WebSocket connection buffers more than an application-defined threshold of continuation frames without FIN
Correlate remote IP addresses of WebSocket clients with server memory spikes to identify the source of abusive sessions

Monitoring Recommendations

Ship JVM crash logs and hs_err_pid files to a centralized log platform for OutOfMemoryError alerting
Track WebSocket connection duration and byte throughput per client at the reverse proxy or load balancer layer
Configure application performance monitoring to alert on abnormal heap growth in http4s services
Review dependency inventories for http4s-blaze-server versions below 0.23.18 or 1.0.0-M42

How to Mitigate CVE-2026-73493

Immediate Actions Required

Upgrade http4s-blaze-server to version 0.23.18 on the 0.23.x branch or 1.0.0-M42 on the 1.0.0 milestone branch
Audit all deployed Scala services for transitive dependencies on vulnerable blaze-core artifacts
Restart affected JVM processes after upgrade to load the patched aggregator code
Restrict WebSocket endpoints to authenticated clients where feasible to reduce exposure to unauthenticated attackers

Patch Information

The fix is delivered in http4s/blaze v0.23.18 and http4s/blaze v1.0.0-M42. The patch adds WebSocketMessageTooLargeException and caps aggregate WebSocket message size in WSFrameAggregator. Oversized messages are terminated with a Close(1009) control frame. Full technical details are in the GHSA-7ppr-r889-mcf2 security advisory.

Workarounds

Migrate to an alternative http4s server backend such as http4s-ember-server where feasible
Terminate TLS and WebSocket traffic at a reverse proxy such as NGINX or Envoy configured with per-connection byte limits and idle timeouts
Disable WebSocket routes on internet-exposed http4s-blaze-server instances until the upgrade is applied
Enforce short WebSocket idle timeouts and maximum connection duration at the network edge

bash

# Example sbt dependency update to a patched version
libraryDependencies += "org.http4s" %% "http4s-blaze-server" % "0.23.18"

# Or for the 1.0.0 milestone branch
libraryDependencies += "org.http4s" %% "http4s-blaze-server" % "1.0.0-M42"