CVE-2026-54464

What it actually does

CVE-2026-54464 is a denial-of-service and resource-control bypass in a WebSocket library when the permessage-deflate extension is enabled. The configured maximum message size is enforced against the compressed WebSocket frame length rather than the decompressed message length. An attacker can therefore send a compressed message whose on-the-wire size is within the allowed limit but whose inflated size exceeds the intended maximum, causing the application to process unexpectedly large messages and potentially consume excessive memory, CPU, or downstream application resources.

Why it matters to the business

Systems that expose WebSocket endpoints using this library with permessage-deflate enabled may be vulnerable to service degradation or outages from unauthenticated network traffic. The main operational risk is reduced availability: WebSocket services may become slow, unstable, or unavailable if attackers force them to process oversized decompressed messages. EPSS is currently low and the issue is not listed in CISA KEV, but because the attack is network-reachable and requires no authentication, internet-facing real-time applications should still prioritize patching.

How an attack unfolds

An attacker identifies a WebSocket server or client that uses the affected library and negotiates the permessage-deflate extension during the WebSocket handshake. The attacker then sends a deliberately crafted compressed WebSocket message whose compressed frame length is below the configured maximum message size. Because the vulnerable implementation checks the size before extension processing, it accepts the frame. After decompression, the message expands beyond the intended application limit and is passed onward for processing. Repeating this behavior can increase memory pressure, CPU usage, queue sizes, application processing time, or downstream workload, potentially degrading or disrupting service. The same pattern may apply to a WebSocket client if it connects to a malicious server that sends oversized compressed messages.

How to fix it

Upgrade the affected library to version 0.8.1 or later, which enforces message size limits after incoming extensions such as permessage-deflate have been processed. Because the advisory states that no known workarounds exist, patching is the primary remediation. Where immediate upgrade is not possible, reduce exposure by limiting access to WebSocket endpoints, applying rate limits and connection limits at the edge, monitoring memory and CPU thresholds, and considering temporary disablement of permessage-deflate if the application stack permits it safely. Also review dependency lockfiles, container images, and transitive dependencies to ensure the patched version is actually deployed in runtime artifacts.

How to confirm the fix worked

Confirm that deployed applications resolve the affected library to version 0.8.1 or later in package manifests, lockfiles, software composition analysis results, and running container or host images. Validate that WebSocket services using permessage-deflate reject or close connections when the decompressed message size exceeds the configured maximum. Regression testing should include compressed WebSocket payloads whose compressed size is below the limit but decompressed size is above it. Operationally, verify that edge controls, connection limits, and monitoring remain in place and that no vulnerable runtime artifacts remain in production, staging, CI images, or base images.

Typical attack path

1. Discover a WebSocket endpoint or client path using the affected library.
2. Confirm that permessage-deflate is enabled or accepted during the WebSocket handshake.
3. Establish a WebSocket connection without requiring authentication if the endpoint permits it.
4. Send compressed WebSocket messages whose compressed frame sizes are within the configured maximum but whose decompressed sizes exceed it.
5. Repeat or parallelize the traffic to increase memory, CPU, queue, or application-layer resource consumption.
6. Trigger degraded performance, connection churn, application errors, or partial service outage.

How to detect it

Review WebSocket server, reverse proxy, WAF, application, and infrastructure telemetry for signs of compressed WebSocket abuse. Focus on requests or connections that negotiate permessage-deflate and are followed by elevated memory use, CPU spikes, increased garbage collection, process restarts, out-of-memory events, long message-processing times, or a surge in WebSocket close events. Application logs may show oversized-message handling, decompression activity, unexpected message-size limit bypass behavior, failed allocations, request timeouts, or connection resets. Network logs can identify repeated WebSocket handshakes containing Sec-WebSocket-Extensions: permessage-deflate from the same source or many sources. Because there are no public exploit-specific payload signatures in the input, treat detection as behavioral: compressed WebSocket traffic correlated with abnormal resource consumption or large post-decompression message handling. If available, inspect historical logs since publication on 2026-07-17 for suspicious permessage-deflate negotiation and resource-exhaustion events.

• Sec-WebSocket-Extensions: permessage-deflate
• permessage-deflate
• Upgrade: websocket
• Connection: Upgrade
• message too large
• message too big
• max message size
• maximum message size
• PayloadTooBig
• payload too large
• close code 1009
• WebSocket close 1009
• out of memory
• OOMKilled
• JavaScript heap out of memory
• allocation failed
• decompression failed
• inflate
• deflate

What your security team should do

• Inventory applications and services that use WebSockets and enable permessage-deflate.
• Prioritize internet-facing WebSocket services and unauthenticated endpoints for immediate dependency review.
• Upgrade the affected library to version 0.8.1 or later and rebuild/redeploy all dependent artifacts.
• Confirm the patched version is present in lockfiles, deployed containers, and runtime environments, not only source manifests.
• Add regression tests for decompressed message-size enforcement when WebSocket compression is enabled.
• Apply compensating controls such as rate limiting, connection limiting, and access restrictions while upgrades are being rolled out.
• Monitor WebSocket services for abnormal compressed-message traffic, memory growth, CPU spikes, connection churn, and oversized-message errors.
• Create detection logic for WebSocket handshakes negotiating permessage-deflate followed by unusually high decompressed payload handling, service errors, or resource exhaustion.