Node's built-in WebSocket client had a DoS bug: which version fixes it

Node.js 22.23.0 and Node.js 24.17.0 are the first versions that ship a patched undici, the library behind Node's built-in WebSocket client. We checked this ourselves by pulling deps/undici/src/package.json from the Node.js source tree at every recent release, rather than trusting a blog post's version table. Below 22.23.0 or 24.17.0, your Node process carries a high-severity denial-of-service bug in any code that opens a WebSocket connection with the built-in client.

What is undici, and why does a Node.js CVE involve it?

A CVE is a Common Vulnerabilities and Exposures identifier, a standardized name assigned to a publicly disclosed security flaw so different tools and advisories can reference the same issue consistently.

Undici is the HTTP client library that powers Node.js's built-in fetch() and WebSocket APIs, maintained as part of the Node.js project itself. Since Node.js 21, Node's own WebSocket client has been built on undici, and that client reached stable status in Node.js 22.4.0. Any code calling new WebSocket(url) without importing a separate library — ws, socket.io-client, or anything else — is using undici underneath.

Because undici ships inside Node.js itself, a bug in undici's WebSocket client becomes a Node.js vulnerability. It doesn't show up as an outdated npm install — it is part of the runtime, and the fix only arrives through upgrading Node.js itself or, in projects that pin their own undici package, upgrading that package directly.

What the bug actually does

A denial-of-service bug is a flaw that lets an attacker make a system unavailable to legitimate users, typically by exhausting memory, CPU, or another finite resource rather than by stealing data.

The vulnerability, tracked as CVE-2026-12151 and published as GHSA-vxpw-j846-p89q on June 19, 2026, is a denial-of-service flaw with a CVSS severity of High. The advisory's own description: undici's WebSocket client enforces a maximum payload size on the cumulative byte count of a message's fragments, but it does not limit how many fragments a message can contain.

A WebSocket server you connect to — malicious or compromised — can exploit that gap. It streams many small or empty continuation frames. Each one passes the per-frame and cumulative-size checks individually. Collectively, they cause unbounded memory growth in the client process, which is the denial of service: the process runs out of memory and crashes, or becomes unresponsive before it does.

The advisory states plainly that no workaround exists. The fix has to come through an upgrade — there is no configuration flag or request option that closes the gap.

Who is affected

Per the advisory, every application is at risk if it uses new WebSocket(...) or the WebSocketStream API — Node's built-in client — and can be made to connect to a server the attacker controls or has compromised. That includes:

• A Node.js backend that connects out to a third-party WebSocket API or webhook endpoint supplied by a user or a configurable integration.
• Any server-side code that proxies or relays WebSocket traffic to an upstream the client doesn't fully trust.
• Command-line tools or scripts that open WebSocket connections to URLs passed in as arguments.

A typical frontend-only React or Vue app using new WebSocket() in the browser is not running Node's undici client — that code path only applies server-side, in Node.js itself. Browser WebSocket implementations are unrelated to this bug.

The Node.js version matrix we checked ourselves

Security advisories for npm packages report the fixed package version. They do not report which Node.js release first bundles that fix — and for a bug baked into the runtime, that is the number that actually matters to most developers, who upgrade Node, not individual bundled dependencies. Our methodology: we pulled it directly from the Node.js GitHub repository's deps/undici/src/package.json file at each tagged release, for example checking v22.23.0, v22.23.3, and v24.17.0 directly. Here is what that check found:

Node.js version	Bundled undici	Vulnerable to CVE-2026-12151?
22.22.0	6.23.0	Yes
22.23.0	6.27.0	No — first fixed 22.x
22.23.3 (latest 22.x)	6.28.1	No
24.16.0	7.25.0	Yes
24.17.0	7.28.0	No — first fixed 24.x
24.22.0 (latest 24.x)	7.29.1	No

If you're running Node.js 22.23.0 or later, or Node.js 24.17.0 or later, your built-in WebSocket client already has the fix — no further action needed for this specific CVE. If you're on an earlier patch release of either line, the built-in client is vulnerable until you upgrade Node.js itself.

Node.js 23.x reached end-of-life before this patch cycle and never received it on that line specifically; anyone still on Node 23 should move to 24 regardless of this CVE, since Node 23 is no longer a supported release. Node.js 18 and 20 predate the built-in WebSocket client reaching stable status. Node 18 is also no longer an available runtime on Vercel as of October 2026. If your code is on either, this bug doesn't apply the same way, but you should be upgrading for other reasons already.

If you can't upgrade Node.js yet

Some projects pin their own undici as a direct dependency, either for a feature the bundled version doesn't have yet or because an older Node.js is otherwise required. In that case, the fix is a normal npm upgrade, independent of the Node.js runtime version:

npm install undici@latest
npm install undici@8.5.0

Check which undici your project is actually running. A transitive dependency can pull in its own copy separate from Node's built-in version:

npm ls undici

If that command reports a version below 6.27.0, 7.28.0, or 8.5.0 for your major line, that copy needs the direct upgrade above. This holds even if your Node.js runtime itself is current.

Two related undici CVEs from the same patch cycle

The GitHub advisory for CVE-2026-12151 isn't the only fix in this area. Two related bugs in the same client shipped around the same time:

• CVE-2026-9675, a cumulative-size check bypass. OSV describes it as a regression specific to undici 8.1.0 and later. The 6.x and 7.x lines were never affected by this variant, since they shipped the equivalent check from the start.
• CVE-2026-1526, published earlier, in March 2026 — unbounded memory use during permessage-deflate decompression, where a small compressed WebSocket frame can expand to consume excessive memory. Fixed in undici 6.24.0 and 7.24.0.

The Node.js version matrix above already accounts for all three, since every Node release we checked at 22.23.0+ and 24.17.0+ bundles an undici version past all three fixes.

How Node.js ships a security fix like this one

Node.js doesn't publish a separate advisory feed for every bundled dependency. A fix inside undici typically reaches users through Node's own security release process, which batches dependency fixes into a regular Node.js patch release rather than shipping them as a standalone npm update. That's why checking node -v matters more here than it would for an ordinary npm package: the fix isn't one npm install away unless you've separately pinned undici yourself.

This also explains why the Node.js version matrix above has sharp boundaries rather than a gradual rollout. Node 22.23.0 either bundles the fixed undici or it doesn't — there's no partial patch, no feature flag, no opt-in. Once a Node.js release ships, every application running on it inherits whatever undici version that release bundled, for better or worse.

What to do right now

1. Check your Node.js version: node -v. Compare it against the table above, or against Node's own release schedule if you need to confirm a line is still supported.
2. If you're below the fixed patch release, upgrade Node.js. This is a runtime upgrade, not an npm audit fix — the vulnerable code ships inside Node itself for the built-in client.
3. Separately, run npm ls undici to catch any package in your tree pinning its own older copy, which the Node.js upgrade alone won't fix.
4. If your code uses ws or socket.io-client instead of the built-in WebSocket, this specific CVE doesn't apply to you — but it's worth confirming which client your code actually uses, since both APIs share the same global name in some setups.

A checklist before you close this out

1. Run node -v and compare it against the table above. This is the single fact that decides whether you're exposed.
2. If you're below the fixed patch release, schedule the Node.js upgrade. Treat it as a runtime upgrade, not a dependency bump — npm audit fix will not touch it.
3. Run npm ls undici regardless of your Node version. A pinned transitive dependency can carry its own older copy that the runtime upgrade doesn't fix.
4. Note which WebSocket client your code actually uses. If it's ws or socket.io-client, this specific CVE doesn't apply, but confirm rather than assume — some codebases mix both across different services.
5. Set a reminder to re-check npm ls undici after any dependency bump. A future package update can silently reintroduce an older undici as a transitive dependency, and the npm overrides field can pin a minimum version across your whole dependency tree if that keeps happening.