CVE-2026-54490

What it actually does

The flaw is a denial-of-service/resource-exhaustion weakness in websocket-driver before version 0.7.5 when the permessage-deflate WebSocket extension is enabled. The library enforces the configured maximum message size using the compressed frame length from the WebSocket header rather than the decompressed message size. An unauthenticated network peer can therefore send a small compressed WebSocket message that expands to a much larger payload after decompression, causing the application to process messages beyond its intended size limits and potentially consume excessive memory, CPU, or event-loop time.

Why it matters to the business

Services that accept WebSocket connections using this library may become slow, unstable, or unavailable if an attacker sends highly compressed oversized messages. The direct impact is availability degradation rather than data theft or code execution, but affected real-time features such as dashboards, chat, collaboration, notifications, streaming updates, or API gateways could experience outages. Public exposure increases risk, although the current EPSS score is low, the issue is not in CISA KEV, and there is no known ransomware association or mature public exploitation reported.

How an attack unfolds

An attacker identifies an application endpoint that accepts WebSocket upgrades and negotiates the permessage-deflate extension. The attacker opens a WebSocket connection without needing authentication if the endpoint is publicly reachable or accepts pre-authenticated connections. They then send one or more compressed WebSocket messages whose compressed frame lengths remain below the configured maximum message size, while the decompressed payload expands beyond that limit. Because vulnerable versions check the compressed length instead of the inflated size, the application accepts and decompresses the oversized message. Repeated or concurrent delivery can exhaust memory, increase garbage collection pressure, block the event loop, trigger process crashes, or cause upstream service timeouts.

How to fix it

Upgrade websocket-driver to version 0.7.5 or later wherever it is used directly or as a transitive dependency. If immediate upgrade is not possible, disable WebSocket permessage-deflate compression, enforce decompressed message-size limits at the application or reverse-proxy layer, cap WebSocket connection concurrency and message rates, and ensure Node.js process supervision restarts failed workers safely. Review dependency lockfiles and bundled packages because websocket-driver is commonly pulled indirectly by WebSocket-related libraries.

How to confirm the fix worked

Confirm dependency resolution shows websocket-driver version 0.7.5 or later in package manifests, lockfiles, SBOMs, and deployed artifacts. Verify that no runtime bundle or container image still contains websocket-driver versions earlier than 0.7.5. For mitigation validation, perform a controlled WebSocket test with permessage-deflate enabled and send a compressed payload that inflates beyond the configured message-size limit; the application should reject or close the connection before processing the inflated message. Also confirm WebSocket responses do not negotiate permessage-deflate where compression has been intentionally disabled.

Typical attack path

1. Discover a WebSocket endpoint exposed by the target application.
2. Initiate a WebSocket handshake requesting the permessage-deflate extension.
3. Confirm the server accepts compression through the Sec-WebSocket-Extensions response header.
4. Send a compressed WebSocket frame that is small on the wire but expands to a very large message after decompression.
5. Repeat the oversized compressed-message delivery across one or more connections to increase memory and CPU pressure.
6. Cause degraded application responsiveness, connection failures, process restarts, or service unavailability.

How to detect it

Review WebSocket access logs, reverse-proxy logs, application logs, Node.js process logs, container orchestrator events, and APM metrics for signs of compressed WebSocket traffic followed by resource exhaustion. Focus on endpoints negotiating permessage-deflate, especially from unusual sources, high connection counts, repeated reconnects, or traffic bursts preceding memory growth, garbage-collection pressure, process crashes, HTTP 101 upgrade spikes, 1009 close codes, 5xx errors, pod/container restarts, or out-of-memory kills. In application telemetry, look for WebSocket messages whose compressed byte counts appear small while processing time, heap usage, or decompressed payload handling is unusually large. Because this vulnerability does not create a unique on-disk artifact, detection is behavioral and should correlate compression negotiation with availability symptoms.

• Sec-WebSocket-Extensions: permessage-deflate
• permessage-deflate
• HTTP/1.1 101 Switching Protocols
• Upgrade: websocket
• Connection: Upgrade
• close code 1009
• Message too big
• max message size
• RangeError: Invalid string length
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed
• Allocation failed - JavaScript heap out of memory
• ENOMEM
• process out of memory
• OOMKilled
• Killed process
• websocket-driver
• lib/websocket/driver/hybi.js

What your security team should do

• Inventory applications, containers, serverless functions, and build artifacts that include websocket-driver directly or transitively.
• Prioritize remediation for internet-facing WebSocket endpoints and services that accept unauthenticated or high-volume WebSocket connections.
• Upgrade websocket-driver to 0.7.5 or later and rebuild/redeploy affected packages from clean dependency lockfiles.
• Temporarily disable permessage-deflate on exposed WebSocket services until patched versions are deployed.
• Add monitoring for abnormal WebSocket message sizes, compression negotiation rates, memory spikes, process restarts, and connection floods.
• Apply rate limits, connection quotas, request body/message limits, and autoscaling safeguards around WebSocket ingress.
• Review post-publication telemetry for the last 25 days for signs of oversized compressed WebSocket traffic or unexplained application instability.