Node.js October Security Updates Before the Node 26 LTS Transition

Patch the runtime you run today while preparing the next major-version migration separately. As of October 27, 2026, the October security advisory links 22.23.4, 24.22.1, and 26.12.1. It covers high-severity DNS, TLS, and Brotli issues alongside HTTP, snapshot, permission, and dependency fixes. These are runtime updates; updating npm dependencies alone does not replace Node’s bundled components.

The release schedule sets Node 26’s LTS transition for October 28, 2026. The 26.12.1 release page still calls it Current, and the advisory lists 24.22.1 as Latest LTS. Do not describe Node 26 as already LTS on October 27. Recheck the schedule and release announcement when approving a later rollout.

Patch first, rehearse the major upgrade separately

For an application already on a supported 22 or 24 line, validate the security update on that line without waiting for Node 26. Confirm the package or image supplier’s revision and any backport advisory. For an upstream build, compare against the appropriate floor below; for a distributor build, obtain explicit backport evidence instead of assuming that an older version is either fixed or vulnerable.

Pin the candidate runtime in a disposable application checkout or staging image. Use the existing lockfile and installation process, rebuild native add-ons, run the project’s tests, and exercise its network and startup paths. A Node 26 rehearsal should include framework support, native dependencies, build tooling, and runtime flags. Merely changing an image tag is not a compatibility test.

Run an inventory in a scratch directory

Use Bash and the runtime your application actually launches. These examples ran on Debian 13 Linux; executable paths and library versions will differ on your machine. Keep the same terminal open. Stop if setup fails:

start_dir="$PWD"
work_dir="$(mktemp -d)" || exit 1
cd -- "$work_dir" || exit 1

Save this as audit-node.cjs. The .cjs suffix makes the example independent of a surrounding package’s module type:

const { createHash } = require('node:crypto');
const assert = require('node:assert/strict');
const [major, minor, patch] = process.versions.node.split('.').map(Number);
const floors = new Map([[22, [23, 4]], [24, [22, 1]], [26, [12, 1]]]);
const floor = floors.get(major);
console.log('Node:', process.version);
console.log('Executable:', process.execPath);
console.log('LTS metadata:', process.release.lts || 'Current');
console.log('OpenSSL:', process.versions.openssl);
const meetsFloor = floor && (minor > floor[0] || (minor === floor[0] && patch >= floor[1]));
console.log('October advisory floor:', !floor ? 'unlisted line; check support policy' : meetsFloor ? 'met; verify package provenance' : 'not met; check distributor backports');
assert.equal(createHash('sha256').update('abc').digest('hex'),
  'ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad');
console.log('Local crypto smoke check: passed');

Run it:

node audit-node.cjs

Observed output on the available Node 24.19.0 runtime:

Node: v24.19.0
Executable: /opt/codex/runtimes/codex-primary-runtime/dependencies/node/bin/node
LTS metadata: Krypton
OpenSSL: 3.5.7
October advisory floor: not met; check distributor backports
Local crypto smoke check: passed

The inventory and small local crypto assertion were executed on Linux. No patched Node version or Node 26 application migration was tested here. The smoke check verifies one SHA-256 operation; it does not establish that any advisory vulnerability is fixed. The floor check correctly flags the available runtime for further action.

process.release.lts describes the binary’s release metadata. It does not calculate today’s lifecycle phase or discover a newer patch. Likewise, meeting the historical October floor does not establish that the runtime is the latest available release. Recheck the official downloads and supplier advisory at rollout time.

Collect evidence from the running service

Capture the inventory from the same executable used by the service and record the installed package revision or immutable container digest. After deployment, restart workers and verify the replacement process reports the expected runtime. Check CI runners, scheduled jobs, and build images too; they may use separate Node installations.

Keep a previous deployment artifact and an explicit rollback decision, including the security cost of reverting the runtime. Do not disable certificate verification to make a network smoke test pass. Test application-specific HTTPS, DNS, compressed input, and startup behavior in isolation; this article intentionally makes no claims about those unrun tests.

Clean up

rm -- audit-node.cjs
cd -- "$start_dir" || exit 1
rmdir -- "$work_dir"
unset start_dir work_dir

If the directory is not empty, inspect it before removing anything else.

Acknowledgements

This post was created with assistance from AI.