websocket-driver EUVD-2026-45310

Exploitation requires the attacker to establish a valid WebSocket connection to the target - the HTTP upgrade handshake must succeed. If the WebSocket endpoint requires HTTP authentication, session cookies, or API tokens before upgrading, unauthenticated remote exploitation is blocked at that layer (the protocol-level PR:N does not override application-layer auth). The draft WebSocket protocol length-header parsing path must be reachable, which is the case for any connection handled by a vulnerable version of websocket-driver < 0.8.1. No specific configuration setting or non-default feature flag is required - the vulnerable code path is exercised by normal frame parsing on every connection. What limits exploitation: application-layer authentication before WebSocket upgrade, network-level access controls (firewalls, VPN requirements), and process isolation (containerization bounds the OOM blast radius to a single worker rather than the full host).

No CVSS vector was provided in the source data, so scoring is independently assessed below. EPSS and KEV data are absent, and no POC is publicly documented at time of analysis, which places this in a lower-urgency tier despite the clear exploitability. The attack is technically trivial - a peer simply holds a WebSocket connection open and sends a continuous stream of high-bit-set bytes - requiring no memory corruption, no ROP chain, and no authentication at the WebSocket protocol layer. The primary real-world constraint is that the attacker must be able to reach the WebSocket endpoint, and many deployments gate that endpoint behind HTTP authentication or session cookies before the protocol upgrade occurs. The impact is a clean DoS: process memory exhaustion causing an OOM kill, with no confidentiality or integrity impact. In single-process Ruby servers (e.g., Puma single-mode, older Thin/Unicorn), a single malicious connection can take down the entire application. In multi-process or containerized deployments the blast radius is bounded to the affected worker. No conflicting signals exist - all data consistently indicates an unauthenticated network DoS with no exploitation in the wild confirmed.

An attacker connects to a publicly accessible WebSocket endpoint - for example, a Faye pub/sub server or a Rails ActionCable endpoint not gated by authentication - and after the HTTP upgrade handshake completes, begins streaming a continuous sequence of 0x80 bytes as the frame length field without ever completing the frame. The vulnerable parser accumulates these bytes into an ever-growing Ruby Bignum object, causing heap memory to grow without bound until the Ruby process is killed by the OS out-of-memory manager, taking down all WebSocket sessions on that worker. No public POC has been identified, but the technique is mechanically trivial to implement.