Node.js 20 gets nothing on November 11, 2026. The security releases cover 26.x, 24.x, and 22.x only, because Node.js 20 reached End-of-Life on April 30, 2026. Your last patch was 20.20.2, built March 24. Since then, 33 CVEs have shipped without a 20.x build. Move to 24 or 26 this week.
Those CVEs came in three security releases that left 20 out. The fourth is days away, and the pre-announcement rates its worst issue HIGH on every supported line.
What November 11 is, and why Node.js 20 is left out
The Node.js project will ship new 26.x, 24.x, and 22.x builds on or shortly after Wednesday, November 11, 2026. No CVE details are public yet, and they stay private until the builds land. Our countdown guide to the November release covers the runtime inventory and the patch-day commands, so this post skips them.
Node.js 20 isn’t on the list because the project stopped maintaining it. The End-of-Life page is blunt: when new security releases reveal issues, “even if the same vulnerability affects EOL release lines, there will not be any new releases for them.”
The advisory adds one more line that matters to you: “End-of-Life versions are always affected when a security release occurs.”
What Node.js 20 has already missed
Three security releases have shipped since 20 went End-of-Life. None has a 20.x build.
| Advisory | CVEs | High | Medium | Low | Fixed in |
|---|---|---|---|---|---|
| June 18, 2026 | 12 | 2 | 6 | 4 | 26.3.1, 24.17.0, 22.23.0 |
| July 29, 2026 | 11 | 3 | 5 | 3 | 26.5.1, 24.18.1, 22.23.2 |
| October 21, 2026 | 10 | 4 | 3 | 3 | 26.12.1, 24.22.1, 22.23.4 |
| Total | 33 | 9 | 14 | 10 | No 20.x build |
The code these fixes touch is the code an API server runs all day:
- TLS hostname checks. June and October both fixed ways to get a certificate accepted for the wrong host.
- HTTP/2. July’s high-severity fixes include a heap use-after-free and a remote memory exhaustion bug.
- DNS. October fixed
dns.resolve*()truncating hostnames at a NUL byte, which can fool an allowlist. - Compression. October fixed an out-of-bounds write in the Brotli decoder that can end in remote code execution. We cover it in the Brotli RCE check.
Read that list carefully. The project doesn’t assess End-of-Life lines, so its advisories name supported versions only. Some of these bugs live in code that 20 may not contain: one October CVE is a regression that the project scopes to 26.x and 24.x alone. So the honest status of each CVE on Node.js 20 is unpatched and unassessed. Nobody has told you you’re safe, and nobody is going to check.
Bug chains make this worse. October’s DNS fix completes a June fix, and a July fix completes another June fix. Every later patch builds on one you don’t have.
“But it still works”
It does. That’s the problem.
An End-of-Life runtime doesn’t fail. node -v prints the same version, your tests pass, and your dashboards stay green. The risk shows up in places you don’t watch:
- The patch itself is the map. Fixes, advisories, and commits go public together, so anyone can read exactly what changed on a supported line and check whether the same code exists in 20.
- Your platform may keep deploying it. AWS Lambda marked
nodejs20.xdeprecated on April 30, 2026, but it doesn’t block function creation until July 29, 2027, or updates until August 31, 2027. - Packages and audits move on. The Node.js project warns that popular packages drop End-of-Life versions over time, and that many industry audits forbid unmaintained runtimes.
Pick a target: Node.js 24 or 26, not 22
Move to 24 this week if you need the shortest path. Choose 26 if you can absorb more removals now and want the longest runway. Skip 22: it does get the November fix, but it ends April 30, 2027, less than six months from now, so you’d repeat this project by spring.
| Line | Status | Latest on Nov 5 | Support ends | Best for |
|---|---|---|---|---|
| 26.x “Lithium” | Active LTS since Oct 28, 2026 | 26.13.0 | Apr 30, 2029 | Services you can fully retest now |
| 24.x “Krypton” | Maintenance LTS since Oct 20, 2026 | 24.22.2 | Apr 30, 2028 | The fastest safe exit from 20 |
| 22.x “Jod” | Maintenance LTS | 22.23.4 | Apr 30, 2027 | Not worth a migration today |
Dates come from the Node.js release schedule. Check your platform before you commit. On Lambda, for example, the Node.js 26 runtime is in public preview and isn’t covered by the Lambda SLA, so 24 is the safer production target there today.
Migration steps and what breaks
Everything in this table comes from the official release notes for 22.0.0, 24.0.0, 25.0.0, and 26.0.0, plus the v22 to v24 migration guide. It’s the short list for API services, not the full changelog.
| Arrived in | Change | Who feels it |
|---|---|---|
| 22 | import ... assert { type: 'json' } removed; use with |
ESM code importing JSON |
| 22 | crypto.createCipher() and createDecipher() removed |
Legacy encryption code |
| 23 and 24 | No prebuilt 32-bit Windows or 32-bit armv7 Linux binaries; macOS 13.5 minimum | Old hosts and edge boxes |
| 24 | OpenSSL 3.5 at security level 2: RSA, DSA, and DH keys under 2048 bits, ECC keys under 224 bits, and RC4 are prohibited | mTLS and old upstreams |
| 24 | tls.createSecurePair removed; url.parse() runtime-deprecated |
Old networking code |
| 24 | Stricter fetch() compliance, AbortSignal validation, stream and pipe errors now throw |
HTTP clients, proxies |
| 24 | V8 13.6; addons may need C++20 | Native modules |
| 25 (if targeting 26) | SlowBuffer and fs.F_OK, R_OK, W_OK, X_OK removed; Corepack no longer ships |
Old utilities, Yarn or pnpm via Corepack |
| 25 (if targeting 26) | IP address as TLS servername moved to End-of-Life |
Clients connecting by IP |
| 26 | _stream_* modules and writeHeader() removed; module.register() runtime-deprecated; Undici 8 |
Old stream code, custom loaders |
The OpenSSL row is the one that bites quietly. Your code doesn’t change, but a handshake with an old partner system fails at runtime.
On a branch, update .nvmrc, engines, your Dockerfile, and CI to the target line (for a clean machine, use the Node.js install guide). Then reinstall so native modules rebuild, scan for removed APIs, run the official codemods, and start the service with deprecation tracing on:
nvm install 24 && nvm use 24
rm -rf node_modules && npm ci
grep -rnE "assert \{ *type|createCipher\(|createDecipher\(|url\.parse\(|fs\.[FRWX]_OK|SlowBuffer|createSecurePair|_stream_[a-z]+|module\.register\(" \
--include="*.js" --include="*.mjs" --include="*.ts" --exclude-dir=node_modules .
npx codemod run @nodejs/import-assertions-to-attributes
npx codemod run @nodejs/crypto-createcipheriv-migration
npx codemod run @nodejs/tls-create-secure-pair-to-tls-socket
npx codemod run @nodejs/fs-access-mode-constants
NODE_OPTIONS="--trace-deprecation" npm start
Review codemod output by hand. The createCipher one is explicit: its generated code can’t decrypt data encrypted with the old API, so plan a data migration if you have any.
The Node.js site has no 24 to 26 guide yet, so use the 25.0.0 and 26.0.0 notes for that hop.
Prove the API behaves the same on the new line
Unit tests don’t show what a new TLS stack and HTTP client do to real traffic. For a jump of two or three majors, you want a before-and-after comparison of the running service, and that’s a good job for your coding agent.
Apidog CLI lets Claude Code, Codex, or Cursor run your Apidog test suites from the terminal. Set it up once:
npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com # pick your agent when prompted
Then give your agent one prompt:
My service runs on Node.js 20 in staging. Run Apidog test suite <suiteId> in project
<projectId> against environment <envId> and save reports to reports/node20. When I
redeploy on Node.js 24, run the same suite into reports/node24. List every request
whose status, body, or TLS behavior changed. Then read the service logs for deprecation
warnings and check each failure against the 22, 24, and 25 release notes: removed APIs,
changed defaults, stricter fetch and AbortSignal handling, OpenSSL key size rejections.
The agent runs the same suite on each side of the migration:
apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
-r cli,junit --out-dir reports/node20
# redeploy the service on the target line, restart it
apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
-r cli,junit --out-dir reports/node24
Two things keep the comparison honest:
- Never pass
-k. That flag disables SSL validation, which hides the exact TLS failures you’re looking for. - Include the calls your service makes upstream. An OpenSSL rejection shows up as an API error on an endpoint that depends on the old partner system, so test those paths, not only
/health.
Once the migration passes, keep the line in your pipeline. The Apidog CLI CI/CD guide has the workflow, and the Claude Code walkthrough covers agent setup.
If you can’t move this week
Buy patched builds. The Node.js End-of-Life page names three partners through the OpenJS Ecosystem Sustainability Program. HeroDevs offers Never-Ending Support with security patches. TuxCare’s Endless Lifecycle Support backports fixes for End-of-Life versions. NodeSource offers upgrade assessments and support. The project calls this a temporary solution, and it is.
Shrink what can reach the process. These steps reduce exposure to the bug classes above. They don’t fix anything:
- Terminate TLS and HTTP/2 at a maintained proxy or load balancer, and speak plain HTTP/1.1 to Node.js on a private network.
- Stop decompressing Brotli from untrusted sources, on both inbound requests and fetched content.
- Reject hostnames with NUL bytes or non-canonical IP spellings before any allowlist check or outbound call.
- Isolate the service: least-privilege credentials, restricted egress, and no shared secrets with patched services.
Write down the risk. Name an owner, a migration date, and the compensating controls, so that “temporary” has an end.
FAQ
Is Node.js 20 still supported? No. It reached End-of-Life on April 30, 2026. The last build is 20.20.2 from March 24, 2026, and the project won’t release another.
Is Node.js 20 vulnerable to the November 11 bugs? No CVE details are public yet, so nobody can say which ones apply. The advisory states that End-of-Life versions are always affected when a security release occurs, and the project doesn’t assess them individually.
Should I upgrade to Node.js 22 instead? No. It’s the smallest jump, but it ends April 30, 2027. Moving to 24 buys another year of support, and 26 buys two.
Node.js 24 or 26? Take 24 if you need out this week or your platform doesn’t fully support 26 yet. Take 26 if you can retest everything now, since it runs until April 30, 2029.
I’m on Node.js 25. Does this apply to me? Yes. Node.js 25 reached End-of-Life on June 1, 2026, with 25.9.0 as its last build. It gets no November fix either, and moving to 26 is one major away.
