Node.js October 2026 security release: all 10 CVEs ranked

Upgrade to Node.js 26.12.1, 24.22.1 or 22.23.4 this week, and rebuild any snapshot or single executable binaries afterwards. The October 21, 2026 release fixed ten CVEs. Four are rated high, three medium and three low. Node.js 26.x is hit by all ten, 24.x by eight and 22.x by seven. One fix, CVE-2026-106074, needs a rebuild and not just an upgrade.

Most coverage focuses on the Brotli remote code execution flaw. This post ranks the other nine by who is actually affected, and gives a script that reads your runtime version and lists the CVEs that apply.

What did the October 2026 Node.js release fix?

The release fixed ten CVEs across the 26.x, 24.x and 22.x lines, plus updates to bundled dependencies. The Node.js security release post gives severity labels only and no CVSS scores.

Node.js is a JavaScript runtime built on Chrome's V8 engine, and the project ships security fixes as coordinated releases across all supported lines. This one covers three lines. The fixed versions are:

Release line	Fixed in	CVEs that apply
Node.js 26.x	26.12.1	10
Node.js 24.x	24.22.1	8
Node.js 22.x	22.23.4	7
Node.js 20.x and older	None	End of life, always affected

Bundled dependencies also changed. The release updates c-ares on all three lines, the eMudhra intermediate CA certificate on all three, OpenSSL on 24.x and 22.x, SQLite on 22.x, and Undici on all three.

How do the ten CVEs rank by severity and reach?

Four are high, three are medium and three are low. Reach matters as much as severity, so the table below adds the lines each one affects.

CVE	Severity	What it is	Lines affected
CVE-2026-111497	High	Brotli decoder out-of-bounds write that permits remote code execution	26, 24, 22
CVE-2026-105482	High	dns.resolve truncates a name at a NUL character	26, 24, 22
CVE-2026-105483	High	TLS hostname bypass using a fullwidth-digit IP	26, 24
CVE-2026-106069	High	TLS hostname bypass when a host loosely resolves to an IP	26, 24, 22
CVE-2026-105481	Medium	Keep-alive socket accepts a response written before the request	26, 24, 22
CVE-2026-106072	Medium	Non-canonical IPv4 DNS SANs authenticate IP endpoints	26, 24, 22
CVE-2026-106074	Medium	crypto.randomUUID() and randomInt() entropy caches saved in snapshots and SEAs	26, 24, 22
CVE-2026-106070	Low	ZipFile returns prefix bytes after failed header validation	26
CVE-2026-106071	Low	Permission Model wildcard radix lookup over-grants access	26
CVE-2026-106073	Low	Permission Model bypass through fs.realpathSync	26, 24, 22

This table is the quotable core of the post, and it follows the Node.js release page line by line. Two secondary write-ups we read disagree with each other on details such as the Brotli reporter, so we used the Node.js page for every row.

Three patterns help. Only CVE-2026-105483 skips 22.x among the high ones. Two lows, CVE-2026-106070 and CVE-2026-106071, hit only 26.x. And every medium reaches all three lines.

Does the Brotli flaw deserve the headlines?

It deserves attention, but only where untrusted Brotli data reaches your process. CVE-2026-111497 is the only item the Node.js post says permits remote code execution. Its reach depends on your code, which is why we tested it separately.

In short, our lab showed six of eight common Node.js HTTP clients decode a Brotli reply without being asked, and Express 5 decodes Brotli request bodies while Express 4 rejects them with HTTP 415. Our dedicated post on the Brotli CVE covers the details and the checklist. Here we only note where it sits among the ten: it is first in severity, but the other three highs also reach every web service that talks over TLS or resolves hostnames.

Which flaws hit apps that connect out over TLS or DNS?

Three of the four high-rated CVEs sit in networking code: two in TLS hostname checks and one in dns.resolve. They matter to any service that calls other hosts, which is almost every service.

TLS hostname verification is the check that the certificate a server presents matches the name you meant to reach. A bypass means a connection can succeed against the wrong host.

• CVE-2026-105483 involves a fullwidth-digit IP, such as Unicode digits that look like an address. It affects 26.x and 24.x only.
• CVE-2026-106069 involves a host that loosely resolves to an IP, and it affects all three lines.
• CVE-2026-106072, a medium, covers non-canonical IPv4 DNS SANs, meaning certificate names that spell an IP address in an unusual form. It affects all three lines.

The shared theme is IP addresses written in unusual ways. If your code connects to hosts derived from user input, such as webhooks, link previews or custom API endpoints, these are your flaws. If it only connects to a fixed list of hostnames you control, the exposure is much smaller.

CVE-2026-105482 is separate. The dns.resolve function truncates a name at a NUL character. A validation step that sees the full string and a lookup that sees the cut string can then disagree. Astra suggests validating NUL bytes before calling dns.resolve, which is its own advice and not the Node.js project's.

What is the entropy flaw, and why does it need a rebuild?

CVE-2026-106074 means entropy caches used by crypto.randomUUID() and crypto.randomInt() get saved into startup snapshots and single executable applications. Every process started from the same artifact could then begin with the same cached randomness.

A startup snapshot is a saved copy of a Node.js heap that lets a process start faster. A single executable application, or SEA, is a Node.js feature that packages a script and the runtime into one binary. If you build either, the bad cache is baked into the artifact you already shipped.

GBHackers describes the effect as duplicated cached randomness across processes, not a general failure of cryptography. Astra uses harsher wording. The difference matters for your risk, but the remedy is the same.

1. Upgrade the Node.js version you build with.
2. Rebuild every snapshot and SEA binary with the fixed version.
3. Redeploy the new artifacts.

Skipping steps 2 and 3 leaves the old cache in your shipped files. A web service that never builds a snapshot or SEA has nothing to rebuild, and upgrading is enough.

Who should care about the Permission Model and keep-alive fixes?

Few teams, but those who do have a clear reason to patch. The Permission Model fixes are rated low, and the keep-alive fix is rated medium.

The Permission Model is a Node.js feature, enabled with the --permission flag, that limits what a script can read, write or run. If you do not use that flag, CVE-2026-106071 and CVE-2026-106073 do not touch you in practice. If you use it as a sandbox for untrusted code, treat both as relevant. Note that CVE-2026-106071 affects only 26.x.

CVE-2026-105481 concerns a keep-alive socket that accepts a response written before the request was sent. Code that reuses HTTP connections is the area involved. It affects all three lines, and the fix needs no change from you beyond upgrading.

CVE-2026-106070 affects only 26.x and concerns ZipFile returning prefix bytes after a header check failed. It matters only if your app uses that ZipFile code on Node.js 26.

How can you check which CVEs apply to your runtime?

Run this script in the environment that serves traffic. It reads process.version and lists the CVEs that apply, using the table above. We ran it on Node.js 22.23.3, one patch behind the fix.

const FIXED = { 22: [22, 23, 4], 24: [24, 22, 1], 26: [26, 12, 1] };
const CVES = [
  ["CVE-2026-111497", "high", [22, 24, 26]],
  ["CVE-2026-105482", "high", [22, 24, 26]],
  ["CVE-2026-105483", "high", [24, 26]],
  ["CVE-2026-106069", "high", [22, 24, 26]],
  ["CVE-2026-105481", "medium", [22, 24, 26]],
  ["CVE-2026-106072", "medium", [22, 24, 26]],
  ["CVE-2026-106074", "medium", [22, 24, 26]],
  ["CVE-2026-106070", "low", [26]],
  ["CVE-2026-106071", "low", [26]],
  ["CVE-2026-106073", "low", [22, 24, 26]],
];
const [maj, min, pat] = process.version.slice(1).split(".").map(Number);
const fix = FIXED[maj];
if (!fix) { console.log("No patch exists for this line"); process.exit(1); }
const patched = min > fix[1] || (min === fix[1] && pat >= fix[2]);
const hits = CVES.filter(([, , lines]) => lines.includes(maj));
console.log(patched ? "patched" : `${hits.length} CVEs apply`);
if (!patched) hits.forEach(([id, sev]) => console.log(sev, id));

On Node.js v22.23.3 it printed 7 CVEs apply, with three high, three medium and one low (our lab, 2026). A runtime at 22.23.4 or later prints patched. A Node.js 20 runtime exits with a message that no patch exists.

The script checks version numbers only. It cannot tell you whether a Docker image was rebuilt, whether a Linux package carries a backported fix, or whether your snapshots are fresh. Run it inside the running container, not on your laptop.

What is the upgrade order?

Fix networked services first, then build pipelines, then everything else. The order follows how many of the ten CVEs can be reached from outside.

1. Public web services and API gateways. They face Brotli, TLS and DNS input. Upgrade first.
2. Services that fetch user-supplied URLs. Webhook senders, link previews and proxies. These hit the TLS and DNS flaws hardest.
3. Build pipelines producing snapshots or SEAs. Upgrade, then rebuild and redeploy the artifacts.
4. Sandboxes using the Permission Model. Upgrade, and review any rules that relied on wildcards.
5. Internal tools and scripts. Upgrade in the normal patch window.

Node.js 20 users have no fix to wait for. Our post on which Node 20, 22, 24 or 26 version to run after October 28 covers the choice of target line. If you run Node's built-in WebSocket client, our post on the WebSocket DoS bug and the version that fixes it is a useful companion read.

What about managed platforms and containers?

Managed platforms patch on their own schedule, so you need to ask which Node.js version your runtime uses. The Astra Security advisory says Lambda, Vercel, Netlify and Cloudflare Workers are being patched on their own timelines. We did not verify that claim with each provider.

The Vercel security bulletin says its firewall rules block the Brotli attack vector on projects it hosts. It adds that they do not cover responses your functions fetch from other servers. That is a statement about one flaw. The TLS, DNS and entropy fixes still depend on the runtime version.

If you deploy on a platform you do not control, contact your hosting provider or your platform's support team for the exact Node.js version in use. Ask for the patch version number, not just the major line. A reply of "Node.js 22" is not enough, because 22.23.3 is vulnerable and 22.23.4 is not.

For containers you run yourself, rebuild instead of patching in place:

1. Change the base image tag or digest to the fixed release, such as node:22.23.4.
2. Rebuild without the layer cache, so an old Node.js layer does not survive.
3. Deploy and confirm with node -p process.version inside the running container.

An image pinned to node:22 only moves to 22.23.4 after you pull again. A long-running host with a cached layer can stay on the old binary for weeks.

What should you not worry about?

Do not worry about the Permission Model fixes if you never pass --permission. Do not worry about the zip fix if you are on 22.x or 24.x. Do not worry about the TLS fullwidth-digit flaw on 22.x, since the Node.js post does not list it there.

Do not skip the upgrade because only some of the ten apply. Every line gets at least seven fixes, and a single patch bump replaces the whole set. Matching each CVE to your code takes longer than the upgrade itself.