GHSA-7ppr-r889-mcf2 blaze: Unbounded WebSocket message aggregation in http4s-blaze-server

• Maven org.http4s:http4s-blaze-server_2.13: < 0.23.18 → fixed in 0.23.18 • Maven org.http4s:http4s-blaze-server_2.13: >= 1.0.0-M1, < 1.0.0-M42 → fixed in 1.0.0-M42 • Maven org.http4s:http4s-blaze-server_2.12: < 0.23.18 → fixed in 0.23.18 • Maven org.http4s:http4s-blaze-server_3: >= 1.0.0-M1, < 1.0.0-M42 → fixed in 1.0.0-M42

Summary `http4s-blaze-server` aggregates the fragments of an incoming WebSocket message with no limit on total size or fragment count. A client that completes a WebSocket handshake can send an unterminated fragmented message and drive unbounded heap growth in the server JVM, resulting in denial of service via `OutOfMemoryError`. Impact Any http4s application serving WebSocket routes over `BlazeServerBuilder` is affected; no non-default configuration is required, and `maxWebSocketBufferSize` does not bound the aggregate (it bounds only individual frames). A single connection sending continuation frames that never set FIN forces the server to buffer every fragment until the heap is exhausted, terminating the JVM with `OutOfMemoryError` on the blaze selector thread. Small fragments amplify the cost through per-frame object overhead, so a modest volume of wire bytes is sufficient. Where the WebSocket endpoint is reachable without authentication the attacker is unauthenticated and remote; where the handshake requires a principal, any authenticated client can still trigger it. Workarounds • No blaze-server configuration bounds the aggregate; `maxWebSocketBufferSize` is not a mitigation. • Terminate/limit WebSocket traffic at a fronting layer that enforces message-size and fragment limits, or disable WebSocket routes. • Longer term: blaze is EOL upstream; plan migration to a maintained backend (e.g. ember).