CVE-2026-54465

What it actually does

The flaw is an uncontrolled memory consumption denial-of-service condition in websocket-driver before version 0.8.1. When the library is used to implement a WebSocket server with WebSocket::Driver.server() on top of a TCP server, or when it is used as part of a WebSocket client, a remote peer can send an HTTP upgrade request or HTTP response containing an indefinitely long sequence of headers. The parser continues accumulating header data without an effective bound, allowing a single network connection to drive process memory growth until the receiving process slows, crashes, is killed by the operating system, or becomes unavailable.

Why it matters to the business

A vulnerable service that accepts WebSocket traffic can be made unstable or unavailable by a remote unauthenticated peer. The likely consequence is service degradation, dropped real-time connections, restart loops, increased infrastructure costs from memory pressure, and potential interruption of customer-facing features that depend on WebSockets. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported exploit maturity, but it is network-reachable and simple enough to warrant routine patching, especially for internet-exposed WebSocket endpoints.

How an attack unfolds

An attacker identifies an application endpoint that uses websocket-driver before 0.8.1 for WebSocket handling. They open a TCP connection and begin the WebSocket HTTP handshake or, for client-side use cases, provide a crafted HTTP response. Instead of completing the handshake normally, the attacker sends a request or response with a continuously growing list of HTTP headers. Because the vulnerable parser does not enforce a practical upper bound on header count or accumulated header memory, the process keeps allocating memory for that single connection. If memory consumption exceeds available limits, the application may become slow, fail health checks, terminate with an out-of-memory condition, or be killed by the runtime or operating system. Repeating the technique or holding connections open can extend the outage until the service is patched, protected by upstream limits, or restarted behind effective request-size controls.

How to fix it

Upgrade websocket-driver to version 0.8.1 or later wherever it is used. If websocket-driver is pulled transitively through another package, update the parent dependency or lockfile so the resolved websocket-driver version is at least 0.8.1. Rebuild and redeploy affected services after updating dependencies. As defense in depth, enforce maximum HTTP header count, maximum header size, request timeout, connection timeout, and per-process/container memory limits at reverse proxies, load balancers, WebSocket gateways, and application servers. Restrict direct TCP access to WebSocket services where possible, and ensure process supervisors restart failed services without creating unbounded restart loops.

How to confirm the fix worked

Confirm dependency inventories, package lockfiles, container images, and deployed artifacts no longer include websocket-driver versions earlier than 0.8.1. Validate at runtime by checking the loaded gem/package version in the application environment. Exercise WebSocket endpoints with normal handshake traffic to ensure compatibility after upgrade. Where safe and authorized, perform a controlled negative test that sends excessive HTTP headers and confirm the connection is rejected, timed out, or bounded without abnormal memory growth. Verify upstream controls enforce header-size and header-count limits before traffic reaches the application.

Typical attack path

1. Discover an internet-facing or reachable WebSocket service using a vulnerable websocket-driver version before 0.8.1.
2. Open a TCP connection to the WebSocket endpoint or position as a peer returning an HTTP response to a websocket-driver-based client.
3. Send an HTTP WebSocket handshake request or response containing a very large or never-ending sequence of headers.
4. Keep the connection open so the receiving process continues parsing and storing header data.
5. Cause excessive memory consumption in the application process.
6. Trigger degraded performance, process termination, container eviction, restart loops, or denial of service for legitimate users.

How to detect it

Review application, reverse proxy, load balancer, container runtime, orchestration, and host logs for memory exhaustion or abnormal WebSocket handshake behavior. Focus on periods with spikes in memory usage, process restarts, HTTP 400/431 responses, failed WebSocket upgrades, long-lived incomplete connections, or many header-heavy requests from the same source. In application telemetry, look for rapid resident memory growth correlated with a small number of inbound TCP/WebSocket connections. In containerized environments, inspect OOMKilled events, restart counts, and memory-limit breaches. Network captures or WAF logs may show HTTP upgrade attempts with unusually high header counts, oversized headers, repeated header lines, or handshakes that never complete. There are no public threat actors or ransomware campaigns associated with this issue in the provided data, so detection should focus on behavioral evidence of denial-of-service attempts rather than actor-specific indicators.

• websocket-driver (< 0.8.1)
• WebSocket::Driver.server
• OOMKilled
• OutOfMemoryError
• out of memory
• Cannot allocate memory
• Killed process
• memory cgroup out of memory
• HTTP 431
• Request Header Fields Too Large
• Upgrade: websocket
• Connection: Upgrade
• Sec-WebSocket-Key:
• Sec-WebSocket-Version:
• failed WebSocket upgrade
• websocket-driver-0.8.0
• websocket-driver-0.7.
• websocket-driver-0.6.

What your security team should do

• Inventory applications, containers, and repositories for websocket-driver usage, including transitive dependencies and lockfiles.
• Prioritize remediation for internet-facing WebSocket endpoints, high-availability real-time services, and services without upstream request-size limits.
• Upgrade websocket-driver to 0.8.1 or later and redeploy affected workloads.
• Add or verify reverse proxy, load balancer, and application-level limits for HTTP header size, header count, connection duration, and idle timeouts.
• Monitor memory utilization, process restarts, container OOM kills, and abnormal WebSocket handshake failures for signs of attempted denial-of-service activity.
• Because this is not KEV-listed, not associated with ransomware, and has low EPSS, treat it as routine but time-bounded remediation rather than an emergency unless exposed services are business-critical or already showing memory-pressure symptoms.