CVE-2026-85024: undici WebSocket deflate bug can crash the Node process

CVE-2026-85024: undici WebSocket deflate bug can crash the Node process

How to fix CVE-2026-85024: upgrade undici to 8.10.2 (or 7.29.1 / 6.28.1 on older trains)

3 min read555 words
Contents

A hostile WebSocket peer can take down the whole Node process, not just the socket. undici's WebSocket client (including Node.js's bundled globalThis.WebSocket) crashes the entire Node.js process when a remote WebSocket peer sends a permessage-deflate compressed message that crosses the decompressed-payload size limit and then contains a malformed DEFLATE block. In lib/web/websocket/permessage-deflate.js, the size-limit cleanup calls removeAllListeners() on the internal zlib InflateRaw, removing its error listener, but leaves the stream running.

Upgrade to undici v6.28.1, v7.29.1 or v8.10.2. Current and LTS tip Node builds still ship older undici. App dependencies can bump now. Built-in globalThis.WebSocket waits on a Node security release or an override.

What breaks

GitHub advisory GHSA-3wwx-pv8p-q78v / CVE-2026-85024 rates this Medium CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H). Complexity is high: the client must reach a hostile or compromised WebSocket endpoint. Impact is availability only.

The inflater then emits a Z_DATA_ERROR with no listener attached, which Node.js treats as a fatal unhandled error event and terminates the process. Application error/close handlers on the public WebSocket cannot observe or prevent this, because the failing object is the internal InflateRaw. A malicious or compromised WebSocket server can crash a client with a single connection, unauthenticated and without any application mistake. The attack is asymmetric (about 130 KB on the wire expands past the limit) and can be repeated on reconnect (crash loop). Affected applications are those using the undici WebSocket client (new WebSocket(...)) or Node.js's bundled globalThis.WebSocket that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.

>=6.25.0 <6.28.1, >=7.28.0 <7.29.1, >=8.1.0 <8.10.2. Fixed: 8.10.2, 7.29.1, 6.28.1 (latest=8.10.2).

Node tip builds checked from src/undici_version.h on GitHub still ship older undici: v26.8.1 → 8.10.0, v24.20.0 → 7.29.0, v22.23.2 → 6.28.0. Latest Node GitHub releases as of this write-up were still Aug 26. There is no Node security release with patched undici yet.

Who is not in scope

  • Apps that never open an undici or Node WebSocket client to untrusted or third-party peers.
  • Server-only WebSocket stacks that do not use undici client (ws, uWebSockets, browser-only clients).
  • undici versions outside the three ranges above, including already-patched 8.10.2 / 7.29.1 / 6.28.1.
  • HTTP fetch-only undici usage with no WebSocket client path.

How to check

For app dependencies from the project root:

npm ls undici

If the resolved version falls in an affected range, upgrade. On Node builds that expose the bundled version:

node -p "process.versions.undici"

Compare that string to the fixed trains. Tip Current/LTS builds listed above still report older numbers until Node ships a security release.

How to fix

Upgrade undici to a patched release on your train.

npm install [email protected]
# or on older trains:
# npm install [email protected]
# npm install [email protected]

Pin or override so transitive copies resolve to the patch. That covers direct new WebSocket(...) from the undici package today.

For Node bundled globalThis.WebSocket, wait for a Node security release that bumps the embedded undici, or replace that client with a dependency you control and keep patched. The advisory lists no application-level workaround.

What this is not

This is not remote code execution, not data theft, and not an unauthenticated internet worm. The peer must already be a WebSocket the client chose to connect to. Damage is process exit and restart loops under AC:H.

References

Continue reading

All posts