GHSA-7PPR-R889-MCF2: Unbounded WebSocket Message Aggregation in http4s-blaze-server leads to Denial of Service

An uncontrolled resource consumption vulnerability exists in the http4s-blaze-server component of the Scala HTTP library ecosystem. The vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling).

The vulnerability is located within the server's WebSocket message aggregation system. WebSocket connections that use message fragmentation can be manipulated by an unauthenticated remote attacker to consume unbounded amounts of heap memory on the host Java Virtual Machine (JVM). This resource exhaustion can occur regardless of the actual data payload size transmitted over the network.

Because the underlying library did not impose a limitation on the number of accumulated fragments or the overall size of buffered payloads, it created a severe vector for remote Denial of Service (DoS) attacks. The threat can be realized through low-bandwidth streams of small frames, making traditional traffic rate-limiting or firewall payload checks ineffective.

The root cause of this vulnerability lies in the implementation of the WSFrameAggregator class inside the http4s-blaze-server packet pipeline. This component is designed to reconstruct fragmented WebSocket frames according to RFC 6455 specifications.

RFC 6455 permits a WebSocket message to be split into multiple frames starting with a non-final frame (FIN=0) and followed by any number of continuation frames (opcode 0x0, FIN=0). The aggregation layer stores incoming fragments within an internal Scala queue called the Accumulator until a frame with the FIN bit set to 1 is received.

Two critical flaws occurred within this processing model. First, there was no cap on the maximum cumulative payload size of aggregated messages. Second, and more importantly, each incoming frame requires the allocation of several JVM metadata objects, including a WebSocketFrame instance, an internal ByteVector wrapper, and list elements within Scala's mutable.Queue. This metadata represents approximately 64 bytes of object overhead per frame on the JVM heap. An attacker can stream millions of 0-byte continuation frames to exhaust heap memory using minimal network transit.

Before the patch, WSFrameAggregator lacked size checks during its accumulation cycle, allowing the internal Accumulator queue to grow without bounds. This section demonstrates how the patch resolves this memory leak.

// Patched message size validation helper
private[this] def messageTooLarge(next: WebSocketFrame): Boolean = {
  val charged = accumulator.length.toLong + next.length.toLong +
    (accumulator.frames.toLong + 1L) * WSFrameAggregator.FragmentOverheadBytes
  maxMessageSize > 0 && charged > maxMessageSize.toLong
}

To address object metadata expansion, the patch charges a virtual penalty of 64 bytes (FragmentOverheadBytes) for each accumulated fragment. This prevents the queue from expanding indefinitely even when receiving empty payloads. When the computed size exceeds maxMessageSize, the accumulator is purged, and a WebSocketMessageTooLargeException is thrown.

Additionally, the patch links the maximum size thresholds between the frame aggregator and the low-level frame decoder, preventing single-frame buffer exploits:

// Aligning aggregator and decoder bounds
val wsMaxMessageSize =
  maxBufferSize.getOrElse(WSFrameAggregator.DefaultMaxMessageSize)
...
    .prepend(new WSFrameAggregator(wsMaxMessageSize))
    .prepend(new WebSocketDecoder(wsMaxMessageSize))

Exploitation of GHSA-7PPR-R889-MCF2 can be executed by an unauthenticated remote adversary with network access to a WebSocket endpoint exposed by an affected http4s-blaze-server instance.

The attack flow is executed as follows:

1. Establish a standard TCP connection to the server.
2. Initiate a standard WebSocket upgrade handshake to negotiate the protocol.
3. Send an initial frame (such as a Text frame) with the FIN bit set to 0.
4. Continually transmit a stream of continuation frames (opcode 0x0) with the FIN bit set to 0 and minimal or 0-byte payloads.

By withholding the final frame (FIN=1), the attacker ensures that the server's WSFrameAggregator maintains state and continues to allocate memory structures on the heap. This causes the JVM to consume heavy CPU cycles attempting garbage collection before crashing with an OutOfMemoryError.

The impact of a successful exploit against GHSA-7PPR-R889-MCF2 is high. Since the http4s-blaze-server process runs inside a single JVM container, an OutOfMemoryError will terminate the active thread pool or cause the JVM process to crash. This completely disrupts service for all active users.

Because the vulnerability requires no special privileges and does not depend on specific application states or configurations, any endpoint supporting WebSockets is fully exposed. The CVSS score for this vulnerability is assessed at 7.5 (High) under vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.

Because GHSA-7PPR-R889-MCF2 is an advisory published within the GitHub Advisory Database without a matching CVE ID, organizations relying on basic CVE scanner databases may fail to recognize the exposure of their software. This necessitates active dependency audits of all Scala microservices using the http4s backend.

To remediate the vulnerability, users must upgrade their dependencies to one of the patched versions: 0.23.18 or 1.0.0-M42. These releases configure WSFrameAggregator to use a default 4 MiB payload cap and apply the per-fragment overhead penalty.

If upgrading is not immediately possible, the following mitigations can reduce exposure:

• Configure any downstream proxy, load balancer, or API gateway to throttle the duration or packet count of individual WebSocket connections.
• Ensure that your application's BlazeServerBuilder is not configured with negative or zero limits, which will bypass the newly introduced security boundaries.

// Secure configuration example enforcing validation:
BlazeServerBuilder[IO]
  .bindHttp(8080, "0.0.0.0")
  .withMaxWebSocketBufferSize(4 * 1024 * 1024) // 4MB maximum buffer