CVE-2026-54466: websocket-driver: message corruption via abuse of draft-WebSocket length headers

websocket-driver (npm package websocket-driver, repo faye/websocket-driver-node) versions before 0.7.5 mishandle an overlong variable-width length header in the legacy draft-75 / draft-76 (hixie-75 / hixie-76) WebSocket parser. The stage-1 base-128 length accumulator in lib/websocket/driver/draft75.js (this._length = (octet & 0x7F) + 128 * this._length) has no upper bound, so a small, attacker-controlled wire sequence makes the declared _length exceed _maxLength (0x3ffffff = 67108863). The driver stays open and enters stage-2 "skip" mode with a gigantic _length, which then consumes, loses, or misframes a subsequent valid text frame instead of delivering its intended message boundary. The 0.7.5 fix adds a per-octet guard if (this._length > this._maxLength) return this.close(); immediately after accumulation.

• Package/component affected: websocket-driver, the Draft75/Draft76 parser path (lib/websocket/driver/draft75.js), reached via Driver.server(...) / Server.parse(chunk).
• Affected versions: websocket-driver < 0.7.5 (representative vulnerable build 0.7.4; fixed control 0.7.5).
• Risk level and consequences: Critical protocol-level message corruption / message loss on any server that accepts legacy hixie-75/76 framing. An attacker who can write raw bytes to an established connection can cause the parser to drop the framing boundary of the following legitimate frame and emit a stale/misframed application message, defeating message integrity. This is a denial-of-integrity / message-corruption issue, not RCE and not memory exhaustion; the wire allocation stays tiny.

Impact Parity

• Disclosed/claimed maximum impact: Protocol message corruption / message loss (impact class other), via abuse of the draft-75/76 length header on a negotiated hixie-75/76 connection.
• Reproduced impact from this run: On 0.7.4, the driver remained open (readyState=1) after the oversized length header, did not deliver the uniquely-marked sentinel text frame, and instead re-emitted a stale copy of the previous (positive-control) message — i.e. the sentinel was consumed/misframed. On 0.7.5, the identical stream closed (readyState=3, close event) while accumulating the over-limit length header and emitted no corrupted application message. Positive control delivered in both builds, proving the parser/listener path was operational.
• Parity: full — the reproduced behavior matches the disclosed message-corruption/message-loss impact and the fixed-build negative control exactly.
• Not demonstrated: No code execution, no memory exhaustion, no native crash — none claimed.

Root Cause

In Draft75.prototype.parse the per-octet state machine has three relevant stages:

• stage 0 (_parseLeadingByte): a leading byte with the high bit set ((octet & 0x80) === 0x80) initializes _length = 0 and moves to stage 1 (binary/control frame with a variable-width length header).
• stage 1 (length accumulator): for every octet, _length = (octet & 0x7F) + 128 * this._length. An octet whose high bit is clear is the terminator; if _length !== 0 the parser transitions to stage 2 with _skipped = 0.
• stage 2 (skip mode): while _length is truthy, each incoming octet increments _skipped until _skipped === _length; the only early exit is octet === 0xFF, which emits Buffer.from(this._buffer) as a message and resets to stage 0. Crucially, in the high-bit-set leading-byte branch _parseLeadingByte does not reset this._buffer, so the stale buffer from a prior text frame is still referenced.

In versions < 0.7.5 there is no bound check on _length during stage 1. The minimal deterministic sequence

0x80  0xFF  0xFF  0xFF  0x7F

drives the accumulator: 0 → 127 → 16383 → 2097151 → 268435455. The terminating 0x7F (high bit clear) produces _length = 268435455, which exceeds _maxLength (0x3ffffff = 67108863), and the parser falls through to stage-2 skip mode. A following valid sentinel text frame (0x00 <utf8 "SENTINEL-VULN-XYZ-12345"> 0xFF) is then consumed byte-by-byte as "skipped" payload; when the sentinel's 0xFF terminator is reached, stage 2 emits Buffer.from(this._buffer) — the stale previous message (POSITIVE-CTRL-OK) — and resets to stage 0. The sentinel text is never delivered; a corrupted/stale message is delivered in its place. The connection stays open, so the corruption is silent and ongoing.

The 0.7.5 patch (lib/websocket/driver/draft75.js, one added line in case 1) inserts the guard immediately after accumulation:

this._length = (octet & 0x7F) + 128 * this._length;
if (this._length > this._maxLength) return this.close();   // <-- added in 0.7.5

so the over-limit header closes the driver (readyState=3, close event) before any sentinel is accepted and before any corrupted message can be emitted.

Fix reference: websocket-driver@0.7.5 release — https://github.com/faye/websocket-driver-node/releases/tag/0.7.5 ; advisory GHSA-xv26-6w52-cph6.

Reproduction Steps

1. Reference: bundle/repro/reproduction_steps.sh (driver script) and bundle/repro/harness.js (Node TCP peer harness). Both are self-contained; the script reuses the prepared project cache (bundle/project_cache_context.json, prepared=true) when available and otherwise falls back to npm install websocket-driver@0.7.4 / @0.7.5.
2. What the script does:
   • Resolves the vulnerable (0.7.4) and fixed (0.7.5) published websocket-driver packages from the durable project cache (or installs them).
   • Verifies the versions and the presence/absence of the _maxLength guard in draft75.js for each build.
   • For each build, runs harness.js, which starts a real loopback TCP server using net.createServer + Driver.server({requireMasking:false}), pipes connection ↔ driver.io, and a raw TCP client performs a draft-75 handshake (no sec-websocket-* headers, so Server.http selects Draft75), waits for the 101 response, then sends (a) a positive-control text frame 0x00 "POSITIVE-CTRL-OK" 0xFF, then (b) the malicious overlong length header 0x80 0xFF 0xFF 0xFF 0x7F immediately followed by (c) a uniquely-marked sentinel text frame 0x00 "SENTINEL-VULN-XYZ-12345" 0xFF. All emitted open/message/close/error events, the readyState, and the exact wire bytes are recorded to JSON.
   • Evaluates the oracle: vulnerable build must deliver the positive control, stay open (no close), not deliver the sentinel, and emit a corrupted/stale message; fixed build must deliver the positive control, emit close on the malicious header, and emit no corrupted message.
   • Writes bundle/repro/runtime_manifest.json, bundle/repro/validation_verdict.json, and best-effort copies proof artifacts into the project-cache proof-carry directory.
3. Expected evidence of reproduction (see bundle/logs/oracle_eval.txt, bundle/logs/vuln_result.json, bundle/logs/fixed_result.json):
   • Vulnerable 0.7.4: positive_delivered=true, sentinel_delivered=false, close_after_malicious=false, corrupted_message_after_malicious=true, positive_count=2 (stale re-emit), readyState_final=1.
   • Fixed 0.7.5: positive_delivered=true, sentinel_delivered=false, close_after_malicious=true, corrupted_message_after_malicious=false, positive_count=1, readyState_final=3.
   • Oracle CONFIRMED=true only when both paths match.

Evidence

• bundle/logs/reproduction_steps.log — full driver script transcript.
• bundle/logs/vuln_result.json — events + wire bytes for 0.7.4.
• bundle/logs/fixed_result.json — events + wire bytes for 0.7.5.
• bundle/logs/vuln_run.log, bundle/logs/fixed_run.log — raw harness stdout per build.
• bundle/logs/oracle_eval.txt — oracle evaluation summary.
• bundle/repro/runtime_manifest.json — runtime manifest (entrypoint_kind=tcp_peer, service_started=true, healthcheck_passed=true, target_path_reached=true).
• bundle/repro/validation_verdict.json — structured verdict (claim_outcome=confirmed).

Key excerpt (vulnerable 0.7.4 events):

[
  {"type":"open"},
  {"type":"message","data":"POSITIVE-CTRL-OK"},
  {"type":"message","data":"POSITIVE-CTRL-OK"}   // stale re-emit; sentinel "SENTINEL-VULN-XYZ-12345" never delivered
]

Key excerpt (fixed 0.7.5 events):

[
  {"type":"open"},
  {"type":"message","data":"POSITIVE-CTRL-OK"},
  {"type":"close"}                                // guard closes on over-limit length header; no corrupted message
]

Wire bytes (hex): malicious header 80ffffff7f → computed _length = 268435455 > maxLength 67108863; sentinel 0053454e54494e454c2d56554c4e2d58595a2d3132333435ff.

Environment: Node.js v24.x on Linux; net loopback TCP; websocket-driver 0.7.4 (vulnerable) and 0.7.5 (fixed) from the published npm package; no sanitizers (production path, sanitizer_used=false).

Recommendations / Next Steps

• Upgrade: Pin websocket-driver to >= 0.7.5 (the guard if (this._length > this._maxLength) return this.close(); is the canonical fix).
• Defense in depth: Where legacy hixie-75/76 framing is not required, disable draft-75/76 negotiation at the HTTP upgrade layer so Server.http never selects Draft75/Draft76.
• Testing: Add a regression test that feeds 0x80 0xFF 0xFF 0xFF 0x7F + a sentinel text frame through Driver.server() over a real socket and asserts (1) a close event fires and (2) no message event carries stale/sentinel content. Also assert the positive-control text frame still delivers.
• Variant exploration (next stage): Confirm the same accumulator path is reachable through Draft76 (hixie-76) once the 8-byte challenge body is satisfied, and check whether intermediate _length values just under _maxLength can still cause partial misframing without tripping the guard.

Additional Notes

• Idempotency: The script was run twice consecutively with identical results (oracle CONFIRMED=true both times, identical event shapes and wire bytes); the only nondeterministic field is the event timestamp t.
• Minimal deterministic octet sequence derived from shipped source: 0x80 0xFF 0xFF 0xFF 0x7F (5 bytes) drives _length to 268435455, the smallest terminator-using sequence that exceeds _maxLength (67108863) using all-high-bit continuation octets. The physical wire input (header + sentinel) is under 40 bytes — no resource exhaustion.
• Real package, real socket: The proof exercises the published websocket-driver package through Driver.server(...).parse(chunk) over a real loopback TCP socket (not a copied parser or reimplementation), satisfying the network_protocol / tcp_peer entrypoint requirement.
• Limitations: The oracle uses an in-process net loopback peer; no external network is involved. The driver's close() in the fixed build ends the connection before the sentinel, so sentinel_delivered=false in both builds — the discriminator is the close event plus the absence of a corrupted/stale message in the fixed build versus the stale re-emit + open state in the vulnerable build.