CVE-2026-54466

What it actually does

The flaw is an improper input validation issue in websocket-driver before 0.7.5, specifically in the draft WebSocket frame parser at lib/websocket/driver/draft75.js. A remote unauthenticated client can send a malformed draft-protocol frame with an indefinitely long length header made of bytes with the high bit set, such as repeated values >= 0x80. The parser keeps folding those bytes into a growing JavaScript Number; because JavaScript numbers are 64-bit floating-point values, the value eventually loses integer precision. Once precision is lost, subsequent frame length and payload parsing can become incorrect, potentially corrupting message boundaries and causing application-level data to be interpreted differently than intended. The vulnerability is network-exploitable with low attack complexity and no required privileges or user interaction, but public exploit maturity is currently reported as none, EPSS is low, and it is not listed in CISA KEV.

Why it matters to the business

Services that expose WebSocket endpoints through vulnerable websocket-driver versions may incorrectly process attacker-controlled WebSocket messages. In practical terms, this can lead to malformed or shifted application messages reaching business logic, which may affect transaction integrity, command handling, session workflows, or real-time application behavior. The risk is highest for internet-facing Node.js applications that still allow legacy draft WebSocket protocol negotiation. Although current exploitation likelihood is low based on EPSS and lack of KEV listing, the fix is straightforward and should be prioritized for externally reachable services and applications that rely on WebSocket message integrity.

How an attack unfolds

An attacker first identifies an application endpoint that accepts WebSocket connections using a vulnerable websocket-driver release prior to 0.7.5 and supports the legacy draft frame parser. The attacker opens a WebSocket connection and sends a crafted frame whose length header does not terminate normally; instead, it contains a long sequence of bytes with the high bit set, such as 0x80 through 0xff. The vulnerable parser continues treating those bytes as part of the encoded length field, building an increasingly large numeric value. As the value exceeds the precision limits of JavaScript's Number type, the parser loses accuracy. The attacker then sends follow-on payload bytes that are parsed using the corrupted or imprecise length state, which can cause payload boundaries to be miscalculated and application messages to be interpreted incorrectly. Successful exploitation depends on the application accepting this legacy protocol path and on how downstream application logic processes the misparsed data.

How to fix it

Upgrade websocket-driver to version 0.7.5 or later wherever it is used, including transitive dependencies bundled through Node.js package managers. If direct upgrade is not immediately possible, mitigate by disabling support for legacy draft WebSocket protocols, rejecting malformed frames with excessively long variable-length headers, enforcing strict maximum frame-header and frame-payload sizes at the proxy or application layer, and placing WebSocket endpoints behind controls that limit unauthenticated access where feasible. Rebuild and redeploy affected applications after dependency updates, and regenerate lockfiles or software bills of materials so deployed artifacts no longer include vulnerable websocket-driver versions below 0.7.5.

How to confirm the fix worked

Confirm that package manifests, lockfiles, container images, and deployed runtime artifacts resolve websocket-driver to 0.7.5 or later. Use dependency tooling such as npm audit, yarn audit, pnpm audit, SCA scanners, or SBOM inventory checks to verify there are no remaining copies of websocket-driver below 0.7.5, including nested transitive copies. Exercise WebSocket endpoints with normal traffic to confirm compatibility after upgrade. Where safe and authorized, test that malformed draft frames with very long high-bit length-header byte sequences are rejected cleanly and do not produce unexpected application messages, parser desynchronization, crashes, or anomalous logs.

Typical attack path

1. Identify an internet-facing or reachable WebSocket endpoint implemented with websocket-driver before version 0.7.5.
2. Confirm that the endpoint accepts or routes traffic through the legacy draft WebSocket parser.
3. Establish a WebSocket connection to the target service without authentication, if the endpoint permits it.
4. Send a malformed draft WebSocket frame containing an excessively long length header made from repeated bytes with the high bit set, such as 0x80 or greater.
5. Cause the parser to accumulate a length value large enough to lose JavaScript numeric precision.
6. Send subsequent payload data crafted to take advantage of incorrect frame length or boundary parsing.
7. Observe whether application behavior, message handling, authorization decisions, or transaction processing can be influenced by the malformed framing.

How to detect it

To assess possible prior exploitation, review logs and telemetry from WebSocket servers, reverse proxies, WAFs, load balancers, and application runtimes for the period since exposure began, with emphasis on the 25 days since publication and any internet-facing endpoints using websocket-driver before 0.7.5. Look for repeated or malformed legacy WebSocket connection attempts, unusually long or non-terminating frame headers, parser errors involving draft75.js, abnormal connection resets immediately after WebSocket upgrade, and application-level messages that appear truncated, concatenated, shifted, or malformed. Raw HTTP access logs may only show the initial WebSocket upgrade and not the malicious frame bytes, so packet capture, network IDS metadata, WAF body inspection, or application debug logs are more useful when available. Hunt for connections where the client sends a WebSocket upgrade and then transmits long runs of bytes in the 0x80-0xff range before a recognizable payload. No named threat actors or public exploitation campaigns are currently associated with this vulnerability, so detections should focus on protocol anomalies rather than actor-specific infrastructure.

• websocket-driver@0.7.4
• websocket-driver@0.7.3
• websocket-driver@0.7.2
• websocket-driver@0.7.1
• websocket-driver@0.7.0
• lib/websocket/driver/draft75.js
• draft75.js
• WebSocket-Protocol
• WebSocket-Origin
• WebSocket-Location
• Upgrade: WebSocket
• Upgrade: websocket
• \x80\x80\x80\x80\x80\x80\x80\x80
• \x81\x81\x81\x81\x81\x81\x81\x81
• \xff\xff\xff\xff\xff\xff\xff\xff
• RangeError
• parse error
• frame length

What your security team should do

• Inventory all applications, containers, serverless packages, and build artifacts that include websocket-driver and identify versions below 0.7.5.
• Prioritize remediation for internet-facing WebSocket services, unauthenticated real-time APIs, and applications where message integrity affects financial, operational, or authorization decisions.
• Upgrade websocket-driver to 0.7.5 or later and redeploy affected services from clean builds.
• Disable obsolete draft WebSocket protocol support if it is not explicitly required by supported clients.
• Add or verify WebSocket frame-size and header-length limits at application gateways, reverse proxies, and application code.
• Review recent WebSocket traffic and application logs for malformed legacy handshake attempts, abnormal frame parsing errors, or long-lived connections with unusual binary preamble data.
• Add SCA policy checks to prevent reintroduction of websocket-driver versions below 0.7.5 in future builds.
• Because the vulnerability is not currently KEV-listed, not associated with ransomware use, and has low EPSS, treat broad emergency response as unnecessary unless vulnerable internet-facing endpoints are confirmed.