Node.js Nov 11 Security Release: Prep Checklist

The Node.js project has announced a security release for Wednesday, November 11, 2026 (or shortly after), and the highest severity fixed is HIGH on all three lines: 22.x, 24.x and 26.x. As of November 6, there are no CVE numbers, no issue count and no fixed version numbers yet. So you can't patch today, but you can find out exactly which of your servers, Docker images and CI jobs will need the update. This post gives you a checklist and a small script I ran to do that.

My angle: most coverage repeats the announcement. The part nobody can do for you is knowing where Node.js versions are pinned in your own repos, so I built a scanner for that and show its real output.

What is confirmed about the November 11 Node.js security release

The official pre-announcement, last updated November 3, says this much:

• Release date: on or shortly after Wednesday, November 11, 2026.
• Release lines: 26.x, 24.x and 22.x.
• Severity: the highest severity fixed is HIGH in each of those lines.
• Not stated: the number of vulnerabilities, any CVE IDs, descriptions, or the version numbers you should upgrade to.
• End-of-life versions are always affected by a security release, so you need to be on a supported line.

FOSS Linux's summary adds that the pre-alert was posted to the oss-security list on November 4 by Antoine du Hamel, and that this follows the October 21 release. I could not find anything about what the bugs are, and I am not going to guess. If a write-up claims to know the details today, ask where it got them.

Why the October release is the best preview

The last security release on October 21 fixed the Brotli decoder bug nicknamed Node2Shell. I covered it in Node2Shell: the Brotli bug and the fix. The fixed versions then were 22.23.4, 24.22.1 and 26.12.1, and Node.js 20 got no fix because it is end of life. That gives you a baseline: if a service is on an older patch than those, it was already behind before November 11.

Find every place your repos pin a Node.js version

Run node --version on a server and you only learn about that one machine. The real exposure is scattered: Dockerfiles, .nvmrc, GitHub Actions workflows, and engines fields. This script scans a folder for them. It has no dependencies and only reads files:

// node-scope.js - list every Node.js version your repo pins, and whether it is in the Nov 11 release's scope
const fs = require('fs'), path = require('path');
const SUPPORTED = new Set([22, 24, 26]); // lines named in the Nov 11, 2026 pre-announcement
const SKIP = new Set(['node_modules', '.git', 'vendor']);
const found = [];

function major(spec) { const m = String(spec).match(/(\d{1,2})(?:[.\w*-]*)/); return m ? Number(m[1]) : null; }
function add(file, kind, spec) { const mj = major(spec); if (mj) found.push({ file, kind, spec: String(spec).trim(), major: mj }); }

function scan(dir) {
  for (const e of fs.readdirSync(dir, { withFileTypes: true })) {
    if (SKIP.has(e.name)) continue;
    const p = path.join(dir, e.name);
    if (e.isDirectory()) { scan(p); continue; }
    const txt = () => fs.readFileSync(p, 'utf8');
    if (/^Dockerfile/.test(e.name)) for (const m of txt().matchAll(/^FROM\s+node:([^\s]+)/gim)) add(p, 'docker', m[1]);
    else if (e.name === '.nvmrc' || e.name === '.node-version') add(p, 'nvmrc', txt());
    else if (e.name === 'package.json') { try { const n = JSON.parse(txt()).engines?.node; if (n) add(p, 'engines', n); } catch {} }
    else if (/\.ya?ml$/.test(e.name) && p.includes('.github')) for (const m of txt().matchAll(/node-version:\s*['"]?([\d.x]+)/g)) add(p, 'actions', m[1]);
  }
}
scan(process.argv[2] || '.');
for (const f of found) {
  const status = f.kind === 'engines' ? 'RANGE, not a pin - check what actually runs' : SUPPORTED.has(f.major)
    ? 'IN SCOPE - update on/after Nov 11' : 'UNSUPPORTED LINE - move to 22/24/26';
  console.log(`${path.relative(process.argv[2] || '.', f.file).padEnd(38)} ${f.kind.padEnd(8)} ${f.spec.padEnd(14)} ${status}`);
}

Run it with node node-scope.js ./your-projects. I tested it on a small sample tree I built with three services, using a mix of pins. Here is the real output:

api/Dockerfile                         docker   22.23.4-alpine IN SCOPE - update on/after Nov 11
api/package.json                       engines  >=20           RANGE, not a pin - check what actually runs
web/.nvmrc                             nvmrc    v20.11.0       UNSUPPORTED LINE - move to 22/24/26
web/Dockerfile                         docker   24-slim        IN SCOPE - update on/after Nov 11
web/Dockerfile                         docker   24-slim        IN SCOPE - update on/after Nov 11
worker/.github/workflows/ci.yml        actions  18             UNSUPPORTED LINE - move to 22/24/26
worker/Dockerfile                      docker   25             UNSUPPORTED LINE - move to 22/24/26

The first version of my script flagged the >=20 engines field as unsupported. That was wrong. A range is not a pin, and it says nothing about what actually runs, so it now gets its own label. If you write a scanner like this, treat ranges carefully.

What the output means

In scope. Pins on 22, 24 or 26 will need the new release. A pin like node:24-slim is a floating tag, so it should pick up the new version once an updated image is published. Rebuild with docker build --pull --no-cache and confirm with node --version inside the built image instead of assuming it worked.

Unsupported line. Anything on 18, 20 or 25 is not in a line named by the pre-announcement. The Node.js guidance says end-of-life versions are always affected, and the October advisory did not list 25 at all. Moving these to 22, 24 or 26 is the fix. It is not something a patch will give you.

A mismatch you will find. My sample has .nvmrc on 20 and a Dockerfile on 24 in the same project. Dev and production disagreeing is common, and it means your tests were not running on the version you ship.

Your plan for November 11

1. Today: run the scanner, list every service, and mark which are on unsupported lines.
2. Before the 11th: schedule a time to rebuild images and update servers. Test the upgrade on one non-critical service first.
3. When the release lands: read the advisory for the CVE list and fixed versions. Prioritize anything that is internet-facing and parses untrusted input.
4. After upgrading: run node --version on each machine and in each container, and record it.

If you also run PHP, the same habit applies. See my posts on how to check your PHP version after PHP2Shell and on the PHP2Shell flaws.

Frequently Asked Questions

What is fixed in the November 11 Node.js release?

Unknown as of November 6, 2026. The pre-announcement gives the date, the three affected lines and a HIGH top severity, but no CVEs or details. Check the advisory page after the release.

Which Node.js versions should I upgrade to?

The exact version numbers have not been announced. Plan to move to the latest patch of 22.x, 24.x or 26.x that the release publishes. If you are on 18, 20 or 25, move to one of those three lines.

Is Node.js 20 affected?

End-of-life versions are always affected by a security release, and Node.js 20 received no fix for the October bug. Treat it as unsupported.

Can I wait a week after the release, like a dependency cooldown?

That is a tradeoff and not a rule. A cooldown protects you from a malicious new package, but a runtime security patch is different: the risk is staying on the vulnerable version. For a HIGH fix on an internet-facing service, I would not wait.

Next step

Run the scanner on the folder where your projects live and fix the unsupported pins first, since those need work no matter what the release contains. When the release ships, I will check the advisory and update this post with the real versions.

Last checked: November 6, 2026, against the Node.js pre-announcement (last updated November 3) and the FOSS Linux summary. The release had not shipped yet.