Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| org.http4s:http4s-blaze-server_2.13 | maven | < 0.23.18 | 0.23.18 |
| org.http4s:http4s-blaze-server_2.13 | maven | >= 1.0.0-M1, < 1.0.0-M42 | 1.0.0-M42 |
| org.http4s:http4s-blaze-server_2.12 | maven | < 0.23.18 | 0.23.18 |
| org.http4s:http4s-blaze-server_3 | maven | >= 1.0.0-M1, < 1.0.0-M42 | 1.0.0-M42 |
Miggo AIRoot Cause AnalysisThe vulnerability, described as unbounded WebSocket message aggregation, allows a remote attacker to cause a denial of service (DoS) via an OutOfMemoryError. This is achieved by sending a specially crafted sequence of WebSocket frames that the server buffers without limit.
My analysis of the provided patches identified two key vulnerable components:
org.http4s.blaze.server.WSFrameAggregator: This class is responsible for assembling fragmented WebSocket messages. The readRequest method would continuously append incoming continuation frames to an internal buffer without enforcing any size limit. The patch 173e8ca820a0d12110bfe409c72e9b9c3d28d471 introduces a maxMessageSize check within readRequest to cap the total size of the aggregated message, thus mitigating the vulnerability for fragmented messages.
org.http4s.blaze.server.WebSocketDecoder: While the primary vulnerability concerned fragmented messages, commit fadbe6d0f7f59045425688d313c8d4804973d12f reveals a related issue. The WebSocketDecoder, which handles the initial parsing of frames from bytes, was configured with an unbounded buffer size for single (non-fragmented) frames. This meant a single, very large frame could also exhaust memory. The decode method is the core of this component's logic. The patch applies the same message size limit to the decoder, ensuring both single and fragmented messages are bounded.
Therefore, an exploit would involve a stack trace showing repeated calls to org.http4s.blaze.server.WSFrameAggregator.readRequest (for a fragmented message attack) or a long-running call to org.http4s.blaze.server.WebSocketDecoder.decode (for a large single-frame attack) as the server's heap is consumed.
org.http4s.blaze.server.WSFrameAggregator.readRequestblaze-server/src/main/scala/org/http4s/blaze/server/WSFrameAggregator.scala
org.http4s.blaze.server.WebSocketDecoder.decodeblaze-server/src/main/scala/org/http4s/blaze/server/WebSocketDecoder.scala