websocket-driver CVE-2026-54465

Exploitation requires that the target application uses WebSocket::Driver.server() to accept WebSocket connections directly on a raw TCP server, bypassing any HTTP server or framework (such as Rack, Rails, Sinatra, Puma, or Unicorn). Alternatively, exploitation applies to WebSocket client implementations that use this library to parse HTTP responses, where the remote server is attacker-controlled. Applications that integrate websocket-driver through an HTTP framework are NOT vulnerable because the framework's own HTTP parser enforces header limits upstream. No authentication is required in the affected raw-TCP-server pattern, and no special attacker capabilities beyond the ability to open a TCP connection are needed. The limiting factors are entirely architectural: only deployments that expose Driver.server() directly to untrusted peers are at risk.

No CVSS score or vector was assigned by NVD at time of analysis, and no EPSS probability is available, so quantitative risk signals are absent. The vulnerability is not listed in CISA KEV and no public proof-of-concept has been identified, making this a theoretical-but-credible risk rather than an actively exploited threat. The impact is a hard Denial of Service - a single malicious connection can exhaust process memory, potentially crashing the service or triggering OOM kills. Critically, exploitation is constrained to a specific deployment pattern: raw TCP-backed WebSocket servers using Driver.server() or WebSocket client implementations. Most Ruby applications that use websocket-driver transitively (e.g., via faye-websocket or Rails ActionCable) do so behind an HTTP framework that preprocesses headers, effectively eliminating the vulnerable code path. The real-world population of directly vulnerable deployments is therefore a subset of all websocket-driver users. Within that subset, exploitation requires no authentication and no user interaction, and a single connection suffices - making it high-severity for operators who match the affected pattern. Teams should audit whether their websocket-driver usage involves Driver.server() on a raw TCP socket before prioritizing remediation urgency.

An attacker establishes a TCP connection to a Ruby WebSocket server that uses WebSocket::Driver.server() without an intermediary HTTP framework, then transmits an HTTP upgrade request containing thousands of arbitrary header lines in a slow or streaming fashion. The websocket-driver parser appends each header to an in-memory structure without bound, causing the Ruby process heap to grow until available system memory is exhausted, resulting in an OOM kill or process crash and denying service to all legitimate clients. No exploit code is required - a simple netcat or custom socket script suffices.