CVE-2026-85014 is a medium severity (CVSS 5.9) denial of service flaw in undici's experimental WebSocketStream. A server that drops the connection without a close handshake crashes the whole Node.js process. Upgrade the npm package to 7.29.1 or 8.10.2, as the advisory says.
What's affected
The record and the GitHub advisory agree. The affected package is undici on npm, from 7.0.0 up to but not including 7.29.1, and from 8.0.0 up to but not including 8.10.2. Patched versions are 7.29.1 and 8.10.2. The advisory rates it Moderate, and the record scores it 5.9, so they match. WebSocketStream arrived in 7.0.0, so every release since then is affected.
Only applications that use the experimental WebSocketStream API are exposed, and specifically those that write through a writer, which the advisory calls the standard way to write. The advisory says no workaround is available, so upgrading is the only listed route.
The trigger is an unclean close: a TCP reset, a proxy teardown or a protocol violating frame. A malicious or compromised WebSocket server can crash a client with a single connection teardown.
How to check if you're exposed
List the undici versions in your dependency tree:
npm ls undici
npm explain undici
Anything from 7.0.0 up to 7.29.0, or from 8.0.0 up to 8.10.1, is in range. Then check whether you use the affected API at all:
grep -rn "WebSocketStream" --include=*.js --include=*.ts --include=*.mjs .
If nothing in your own code or in the packages that call undici uses WebSocketStream, the issue cannot be triggered, even though the vulnerable package is installed. Note that the package is experimental, so many applications have not adopted it. A reachability check, which asks whether the vulnerable function is actually called, gives you that answer faster than reading code by hand.
What to do now
- Upgrade undici to 7.29.1 or 8.10.2, matching your major version, and commit the new lock file.
- Find any use of WebSocketStream in your services and prioritize those that connect to servers you do not control.
- As a safety net, run Node.js services under a supervisor that restarts them, and alert on repeated restarts.
- Add a process level handler for unhandled rejections only after thinking through what state your service is in, since the advisory notes that the default behaviour ends the process.
- Add a dependency scan to CI so future advisories in undici reach you.
Why it matters
The record lists an uncaught exception, CWE-248, and an improper check for unusual conditions, CWE-754. When the socket closed uncleanly, undici called abort on a writable stream that was locked by the application. The Streams standard says that returns a promise that rejects, and undici discarded the promise. Nobody was left to handle the rejection, so Node.js applied its default and ended the process.
This is a denial of service with a very small trigger. No account is needed, and the application has made no mistake. If your service keeps long lived WebSocket connections to third party servers, an abrupt disconnect from any of them could bring the service down. The record does not list this CVE as exploited in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a workaround?
The advisory says no workaround is available. Upgrade to 7.29.1 or 8.10.2.
Do I need to worry if I do not use WebSocketStream?
The flaw can only be triggered through that API. Without it the package is present but the vulnerable code is not used. Upgrade anyway.
Sources
Last reviewed: 18 October 2026.