The Node.js project has scheduled security releases for the 26.x, 24.x and 22.x lines on or shortly after Wednesday, 11 November 2026. According to the official pre-announcement, the highest severity issue fixed in each of those lines is rated HIGH. This post gives you a practical checklist: what to do before the patches land, how to upgrade quickly when they do, and how to make sure your containers and CI actually pick up the new versions.

What we know (and what we don’t)

  • Affected lines: 26.x (current LTS, “Lithium”), 24.x and 22.x all get fixes.
  • Severity: the top issue in every line is HIGH.
  • End-of-life versions: the Node.js team states that EOL versions are always affected when a security release occurs, and they get no fix.
  • Details: CVE numbers and descriptions are normally published together with the releases. Until then, assume you need to update every supported line you run.

At the time of writing (evening of 11 November, IST), the patched builds had not yet appeared in the official download index. The latest 26.x release was 26.13.0 (LTS, 28 October). Watch the announcement page for the exact patched version numbers rather than guessing them.

Step 1: Inventory every Node.js runtime you run

The hardest part of a Node security release is usually finding all the places Node runs. Start with a quick inventory:

# Local machine
node -v

# Which version each project expects
cat .nvmrc .node-version 2>/dev/null
grep -n '"node"' package.json            # engines field

# Docker images in your repos
git grep -nE '^FROM .*node' -- '*Dockerfile*'

# CI configs (GitHub Actions example)
git grep -n 'node-version' -- .github/workflows

Don’t forget serverless runtimes, build agents, Electron-based internal tools and any VM where Node was installed by hand years ago.

Step 2: Retire end-of-life versions

If the inventory shows any line other than 22, 24 or 26, that runtime will not receive these fixes. Plan its upgrade now. A small script helps you check versions in CI:

// check-node.mjs – fail CI on unsupported major versions
const supported = [22, 24, 26];
const major = Number(process.versions.node.split('.')[0]);

if (!supported.includes(major)) {
  console.error(`Node ${process.version} is not a supported line (${supported.join(', ')}).`);
  process.exit(1);
}
console.log(`Node ${process.version} is on a supported line.`);

Update the supported list whenever the release schedule changes.

Step 3: Upgrade as soon as the patches land

With a version manager

# nvm: install the newest release of your line and switch to it
nvm install 26 --reinstall-packages-from=current
nvm alias default 26
node -v

# fnm
fnm install 26
fnm default 26

Re-run node -v afterwards and compare with the version listed in the security release post.

With Docker

Floating tags such as node:26-alpine move to the patched build once the official images are rebuilt, but your cached image will not. Force a fresh pull and a clean build:

docker pull node:26-alpine
docker build --pull --no-cache -t my-app:patched .

If you pin exact versions (for example node:26.13.0-alpine), bump the tag to the new patch release. Pinning plus a deliberate bump is the more reproducible approach, as long as someone owns the bump.

In GitHub Actions

- uses: actions/setup-node@v4
  with:
    node-version: '26'        # resolves to the newest 26.x
    check-latest: true        # don't reuse an older cached runtime

check-latest: true tells the action to look for the newest matching version instead of using whatever is already cached on the runner.

Step 4: Verify in production

Log the runtime version at startup so you can confirm the rollout from your logs or dashboards:

// server.mjs
console.log(JSON.stringify({
  msg: 'service starting',
  node: process.version,
  openssl: process.versions.openssl,
}));

Including process.versions.openssl is useful because Node security releases sometimes include OpenSSL updates. After deployment, search your logs for the old version string; anything still reporting it is a missed host.

Step 5: Reduce the time-to-patch next time

  • Subscribe to the low-volume nodejs-sec mailing list, which announces security releases in advance.
  • Automate base-image updates with Dependabot or Renovate (both can bump Docker FROM tags).
  • Rebuild images on a schedule (for example weekly) even when your code has not changed, so OS and runtime patches flow in.
  • Keep one owner per runtime inventory. Security releases are routine; finding forgotten servers is what makes them slow.

Common pitfalls

  • Updating the laptop, not the server. Your local node -v says nothing about production. Verify where the code actually runs.
  • Stale CI caches. Cached toolchains and Docker layers can quietly keep the old runtime. Clear or bypass them for this rollout.
  • Multi-stage Dockerfiles. If your build stage and runtime stage use different FROM images, update both. The runtime stage is the one that matters most.
  • Pinned engines. A strict engines field such as "node": "26.13.0" can block installs on the patched version. Prefer a range like ">=26.13.0 <27".
  • Bundled runtimes. Desktop apps built with Electron and single-file executables ship their own Node. They need a rebuild by their maintainers, not just a system update.

Quick checklist

  1. List every Node runtime (laptops, CI, containers, servers, serverless).
  2. Upgrade anything on an end-of-life line.
  3. When the patches are published, install the newest 22.x, 24.x or 26.x release for each line you use.
  4. Rebuild Docker images with --pull, and set check-latest in CI.
  5. Confirm the new process.version in production logs.

Key takeaway

All three supported Node.js lines get HIGH-severity fixes in this release, and end-of-life versions get nothing. Use today to inventory your runtimes and clear out EOL versions, then roll out the patched 22.x, 24.x and 26.x builds as soon as they appear on the Node.js security release page. The faster your rebuild pipeline, the smaller your exposure window.