CVE-2026-54463

What it actually does

websocket-driver versions before 0.8.1 mishandle draft WebSocket protocol length headers. A remote peer can send a length field made of an indefinite sequence of bytes with the high bit set, causing the Ruby parser to keep growing an integer in memory. Because the parsing occurs before meaningful application-level authorization, an unauthenticated network peer can force the Ruby process handling the WebSocket connection to consume excessive memory and potentially terminate from out-of-memory conditions. The impact is denial of service affecting availability, not data disclosure or code execution.

Why it matters to the business

Publicly reachable applications, APIs, background services, or real-time features that use vulnerable websocket-driver versions can be made unstable or unavailable with low-effort network traffic. This may interrupt chat, notifications, collaboration, streaming updates, dashboards, or other WebSocket-backed functionality, and in shared Ruby application processes may degrade the entire service rather than only the WebSocket feature. EPSS is currently low and there is no known KEV listing or reported exploit maturity, but the flaw is network-reachable, unauthenticated, and simple enough that exposed services should still be patched during the next urgent dependency update cycle.

How an attack unfolds

An attacker first identifies a service that accepts WebSocket connections and uses a vulnerable websocket-driver release. The attacker opens a WebSocket connection using a draft protocol path that reaches the vulnerable length-header parser. Instead of sending a normal finite frame length, the attacker sends a long or continuous sequence of bytes with values of 0x80 or greater, which the peer interprets as a length integer that never terminates. The receiving Ruby process repeatedly expands the integer representation and allocates more memory. Repeating this across one or more connections can exhaust process or host memory, leading to request failures, worker crashes, container restarts, process termination by the kernel OOM killer, or broader service degradation.

How to fix it

Upgrade websocket-driver to version 0.8.1 or later wherever it is used, including direct and transitive Ruby gem dependencies. Regenerate and redeploy dependency lockfiles such as Gemfile.lock after updating. If immediate upgrade is not possible, reduce exposure by restricting access to WebSocket endpoints, applying rate limits and connection limits, enforcing request/body/frame parsing limits at reverse proxies where possible, disabling support for obsolete draft WebSocket protocol versions if configurable, and isolating WebSocket workers with memory limits and automatic restart policies. These mitigations reduce blast radius but do not replace upgrading the vulnerable library.

How to confirm the fix worked

Confirm dependency remediation by inspecting deployed artifacts, lockfiles, container images, and runtime gem inventories for websocket-driver version 0.8.1 or later. For Ruby Bundler-based applications, verify that Gemfile.lock no longer lists websocket-driver below 0.8.1 and that production images were rebuilt from the updated lockfile. Exercise normal WebSocket functionality after the upgrade to ensure compatibility. If safe testing is approved, use a controlled non-production environment to send malformed draft-protocol WebSocket frames with repeated high-bit length bytes and confirm the process rejects or closes the connection without unbounded memory growth. In production, confirm that memory usage, worker restarts, OOM events, and WebSocket error rates remain stable after deployment.

Typical attack path

1. Discover an exposed WebSocket endpoint on a Ruby application or service.
2. Establish a WebSocket connection that negotiates or reaches vulnerable draft WebSocket parsing behavior in websocket-driver before 0.8.1.
3. Send a malformed frame length header composed of a long or indefinite sequence of bytes with the high bit set, such as repeated 0x80-or-higher bytes.
4. Keep the connection open or repeat the behavior across multiple connections to increase memory pressure.
5. Trigger Ruby process memory exhaustion, worker crash, container restart, or operating-system OOM termination.
6. Optionally repeat the attack to sustain denial of service until the vulnerable dependency is upgraded or traffic is blocked.

How to detect it

To determine whether exploitation may have occurred, review application logs, reverse-proxy logs, WebSocket gateway logs, container/orchestrator events, host system logs, and application performance monitoring around periods of elevated memory use or service instability. Look for WebSocket connections that open and then abruptly disconnect, unusually long-lived or high-volume connections with little application payload, repeated malformed WebSocket frame errors, and bursts of connections from the same source addresses preceding Ruby worker memory spikes. On Linux hosts and containers, search for OOM killer messages, process kills, container restarts, and Ruby exceptions such as NoMemoryError or allocation failures. Network packet captures, if available, may show WebSocket traffic containing long runs of bytes at or above 0x80 in the frame length area, especially repeated 0x80 bytes, before the connection terminates. Because the vulnerability causes denial of service rather than code execution, durable host artifacts may be limited to logs, crash reports, metrics, and memory/availability telemetry.

• websocket-driver
• NoMemoryError
• failed to allocate memory
• out of memory
• Out of memory
• OOMKilled
• oom-kill
• Killed process
• Memory cgroup out of memory
• worker timeout
• worker process exited
• WebSocket frame error
• malformed WebSocket frame
• invalid WebSocket frame
• \x80\x80\x80\x80
• repeated 0x80 bytes in WebSocket frame length header

What your security team should do

• Inventory Ruby applications, containers, and services that include the websocket-driver gem, especially internet-facing WebSocket endpoints.
• Prioritize upgrading all instances of websocket-driver before 0.8.1 to 0.8.1 or later, even though EPSS is low and the issue is not currently in KEV.
• Rebuild and redeploy application images or packages rather than only updating source repositories, then verify the running version in production artifacts.
• Add or review WebSocket connection rate limits, idle timeouts, maximum connection counts, and per-process/container memory limits to reduce denial-of-service impact.
• Monitor for unexplained Ruby memory growth, worker crashes, OOM killer events, container restarts, and spikes in abnormal WebSocket disconnects.
• If exposed endpoints cannot be patched quickly, temporarily restrict WebSocket access by network location, authentication layer, WAF/reverse-proxy policy, or feature flag where operationally feasible.