Node.js 20 End of Life: Node2Shell Won't Be Patched on It (2026)

Node.js 20 reached end of life on 30 April 2026: since then it gets no releases, including security fixes. The cost of that became concrete on 21 October 2026, when the Node.js project fixed Node2Shell (CVE-2026-111497), a remote code execution flaw in the Brotli decoder it bundles, in 22.23.4, 24.22.1 and 26.12.1, and nothing else. CISA added it to its list of actively exploited vulnerabilities on 27 October. If an app, an API or a build pipeline of yours still runs Node 20, it stays vulnerable for good. Upgrade to Node 24 or 26; Node 22 ends in April 2027. Below: the dates, what Node2Shell is, how to check what you run, and what to do when nobody maintains the app anymore.

---

The dates

From the Node.js release schedule and release list:

Odd-numbered versions (21, 23, 25) are never long-term supported and are already out of support. The Node.js end-of-life page is blunt about what that means: an end-of-life version "will no longer receive updates, including security patches", and when a fix lands in newer lines, "even if the same vulnerability affects EOL release lines, there will not be any new releases for them."

Node2Shell: the first big fix Node 20 won't get

CVE-2026-111497 is an out-of-bounds write in Google's Brotli decoder, the decompression library behind br content encoding, which Node.js bundles in its zlib module. A crafted compressed stream can corrupt memory; the Node.js project rates it high and says it permits remote code execution. What happened, in order:

• 21 October 2026: Node.js ships the fix in 22.23.4, 24.22.1 and 26.12.1, part of a release that, per coverage of it, fixed ten vulnerabilities. Brotli itself is fixed in 1.0.10, 1.1.1 and 1.2.1 the same day.
• 25 October: Microsoft ships out-of-band .NET updates for the same CVE (.NET 8 itself reaches end of life on 10 November).
• 27 October: CISA adds CVE-2026-111497 to its Known Exploited Vulnerabilities catalog, with a 10 November deadline for US federal agencies. Sophos reports active exploitation.

Reports differ on how easy exploitation is in practice: one public demonstration reached code execution on an official Node.js 24.22.0 image only after several attempts. That is a reason to schedule the upgrade calmly this week, not a reason to skip it. And coverage of the advisory reports no workaround short of upgrading.

The part that matters for Node 20: Node.js 20, 21, 23 and 25 will not get this fix. Any application on them that decompresses Brotli data it didn't produce itself (an API receiving compressed bodies, a server fetching from other servers, a proxy) carries this hole permanently.

How to check what you run

• On a server: node -v.
• In containers: the base image in each Dockerfile (FROM node:20, node:20-alpine).
• In the repository: .nvmrc, .node-version, the engines field in package.json, and the node-version in CI workflows. Build pipelines count: a site built on Node 20 isn't serving traffic from it, but the build machine is still running unpatched code on your behalf.
• On serverless platforms: the function's runtime setting (for example nodejs20.x). Cloud providers retire old runtimes on their own schedules, so a function may stop deploying before it stops running.
• Desktop apps: Electron apps bundle their own Node.js, and only a new release of the app updates it.

If nobody on your side can answer in an afternoon, that is the most important finding of the exercise.

Your options

1. Upgrade to Node 24 or 26. For a maintained app with tests, this is usually contained work: bump the version everywhere above, update dependencies that pin old Node APIs, run the tests, deploy. Skip Node 22 unless a dependency forces it: it ends on 30 April 2027.

2. Upgrade with a takeover. For an app whose developer or agency is gone, the runtime bump is the easy part. The hard part is that nobody knows what else breaks: dependencies just as out of date, no tests, no reproducible deployment. That needs an audit first (taking over abandoned software).

3. Buy time, temporarily. The Node.js project lists commercial providers that backport security fixes to end-of-life versions (HeroDevs, NodeSource, TuxCare), and says this "should be viewed as a temporary solution—the goal should always be to upgrade". Useful if a hard freeze blocks the upgrade this quarter; not a plan.

What doesn't work is waiting. Node 20 has been out of support for six months without anything visibly breaking. Node2Shell is what that looks like.

What we do

We take over applications other teams built, and keep them current. Our own production services are written in Go, and we say so: on a Node.js application, our job is the audit, the upgrade path and the maintenance around it. The audit reads the code, lists what is out of support (runtime, framework, libraries) and what is exposed, and gives a costed order of work. Then, if you want, we do the upgrade and keep it current.

Node.js does run in our own tooling: the build of this website and our end-to-end test runner. When we checked our own repositories for this post, the website's build was pinned to Node 22.22.0, one release short of the fix. We moved it to 22.23.4 in the same change that published this article. Across our repositories, Dependabot watches dependencies and a scheduled scan re-checks the main branch of every live application, filing anything it finds as an issue. Details on our security page.

Related: .NET 8 end of life, PHP2Shell explained for CEOs, what the CISA KEV list means for your software, Windows Server 2016 end of life, and software maintenance and support services.