CVE-2026-69209

The shared WebSocket decoder in http4s, a Scala HTTP services interface, buffers message fragments without any limit during defragmentation and its FrameTranscoder accepts declared frame lengths up to Int.MaxValue (about 2 GiB). A remote, unauthenticated attacker who completes a WebSocket handshake against a service built on http4s-blaze-server or http4s-ember-server can send oversized frames or heavily fragmented messages to exhaust server memory, causing denial of service (crash or OOM). Any http4s-based application exposing WebSocket endpoints on the Blaze or Ember backends is affected. The flaw is fixed in versions 0.23.35 and 1.0.0-M47, which enforce a configurable 64 MiB default limit on individual frames and defragmented messages via EmberServerBuilder.withMaxWebSocketMessageSize. No public proof of concept or known exploitation in the wild has been reported.

What to do: Upgrade to http4s 0.23.35 (0.23.x line) or 1.0.0-M47 (1.0 milestone line) as soon as possible. If immediate upgrade is not feasible, place WebSocket endpoints behind a reverse proxy that enforces frame/message size limits, and tune EmberServerBuilder.withMaxWebSocketMessageSize appropriately after patching. Monitor server memory and connection behavior for oversized-frame or fragmentation abuse on any internet-exposed Blaze or Ember WebSocket endpoints.