Node.js End of Life: Node 20 Is EOL, and the October 2026 Security Release

Node.js 20 reached end of life on April 30, 2026. Six months later, on October 21, 2026, the Node.js project shipped security releases for the 26.x, 24.x and 22.x lines fixing ten vulnerabilities, four of them rated high. Node 20 was not patched, and it never will be.

Node.js end-of-life dates

Even-numbered releases become Long Term Support (LTS) and are maintained for about 30 months in total. Odd-numbered releases are short-lived.

Check the current schedule at nodejs.org/en/about/previous-releases before you plan an upgrade.

What the October 21, 2026 release fixed

• CVE-2026-111497: Brotli decoder out-of-bounds write. Node's advisory says it permits remote code execution. Any server that decompresses attacker-controlled Brotli data (an HTTP client fetching untrusted URLs, a proxy, an upload endpoint) is exposed.
• TLS hostname verification bypasses. Several issues could let a certificate for the wrong host be accepted, which undermines HTTPS calls your server makes to other services.
• DNS lookup issues, plus dependency updates to c-ares, OpenSSL (22.x and 24.x), SQLite (22.x) and Undici.

Patched versions reported for this release: 26.12.1, 24.22.1 and 22.23.4. Confirm against the official advisory before you pin a version.

Where old Node versions hide

The node -v on your laptop is rarely the one serving traffic. After a security release, check each of these:

• Docker images. FROM node:20-alpine in a Dockerfile keeps shipping Node 20 until someone edits it. Rebuild images even on the same major version, because tags like node:22-alpine only pick up the fix when you pull and rebuild.
• Platform runtime settings. Vercel, Netlify, Render, Railway, AWS Lambda and similar platforms each have a Node version setting per project. Some patch minor versions automatically; few move you off an EOL major on their own.
• engines and .nvmrc / .node-version files that pin CI and deploys to an old major.
• Process managers and system packages. PM2, systemd units and /usr/local/bin/node installed by a pkg installer years ago.
• Background jobs on a separate server that nobody remembers until they break.

Node.js does not announce its version over HTTP, so an external scan cannot tell you the version directly. The website vulnerability scanner does flag framework fingerprints such as X-Powered-By: Express, which are worth removing anyway.

Upgrading from Node 20

1. Move to Node 22 at minimum, preferably 24, which is supported until 2028.
2. Update native modules (bcrypt, sharp, better-sqlite3 and similar) since they compile against a specific Node ABI.
3. Run tests on the new version in CI before switching production; most apps move from 20 to 22 or 24 without code changes.
4. Update the Dockerfile base image, the platform setting and engines in the same pull request so the three cannot drift apart.
5. Deploy, then confirm the running version from inside the process (log process.version at startup).

If your fleet has many small services, that last step matters most: the project that broke last time is usually the one where only two of the three places were updated. If you want this handled for you, managed patching applies Node.js security releases within 72 hours.