The vulnerability arises because Http4s' WebSocket FrameTranscoder accepts a negative 64‑bit payload length. When a client completes a WebSocket handshake with an Ember server and sends a frame with this negative length, the decoder returns an empty frame without consuming input. The decoding loop then executes indefinitely, tying up CPU and repeatedly appending to an ArrayBuffer until it grows without bound, which leads to denial of service. This flaw is identified by the weakness of an infinite loop (CWE‑835) coupled with improper handling of negative values (CWE‑1284), resulting in a logic error in the decoder’s length validation. An attacker only needs to initiate a WebSocket connection to an Ember server that hosts http4s and transmit a specially crafted frame with a negative length. The resulting resource exhaustion renders the HTTP service unavailable, with no data compromise.

Deployments that use the http4s Scala HTTP interface and support WebSocket connections are affected, specifically all versions prior to 0.23.35 and 1.0‑M47. The vulnerability can be triggered by a remote client that completes a WebSocket handshake through an Ember server and sends such a frame.

The CVSS score is 7.5. The EPSS score is < 1%, and KEV is not listed, which means the risk is primarily derived from the high severity rating. An attacker needs only to establish a WebSocket connection and send a frame with a negative length; no additional privileges are required.