Node.js 18, 20 and 25: No Upstream Node2Shell Fix

No fix is coming for Node.js 18, 20 or 25. The Node.js project doesn't release security patches for end-of-life lines, so waiting for one only extends your exposure.⁠¹ The real options are to move to a supported line, to buy commercial support as a bridge, or to cut off the paths that feed attacker-controlled Brotli data to the runtime. The complete PHP2Shell and Node2Shell guide covers both flaws. This page covers teams on Node.js lines that will never be patched.

CISA added the flaw to its KEV catalog on 27 October, based on evidence of active exploitation, and published no attack details.⁠⁶ BleepingComputer reports a 10 November deadline for federal agencies, which CISA's bulletin does not state.⁠⁷ A 23 October vendor post that says the flaw wasn't exploited predates the listing.⁠⁵ Status as of 4 November 2026. The fixed versions and update steps cover the lines that do have a fix.

Why no fix is coming

Node.js lists 18, 20 and 25 as end-of-life, along with 23, 21 and everything older. Its EOL page says these lines receive no updates, including security patches, and that when a security release fixes a flaw in newer lines, no new release follows for an end-of-life line the flaw also affects.⁠¹ The final releases were 18.20.8 (27 March 2025), 20.20.2 (24 March 2026) and 25.9.0 (31 March 2026).⁠⁸ The project's blog gives the reason: fixing every old line would be an ever-growing task, and some fixes depend on a pile of other patches.⁠⁹ The project set this policy deliberately.

Reported HeroDevs says it read the Brotli decoder source at the final release of each end-of-life line back to 10.x and found the vulnerable code still present.⁠⁵ That does not show that every application on those lines can be exploited. The same release also fixes nine other vulnerabilities on 22, 24 and 26, and the other fixes in the same release make the upgrade worth doing even for apps that never touch Brotli.⁠²

How you'd notice

Run node --version on every host and inside every container image. Then look for runtimes you didn't install: Electron apps, CLI tools, serverless runtimes and vendor products that bundle their own Node.js. SecurityWeek reported on 27 October that Broadcom warned VMware Cloud Foundation's SDDC Manager is affected because it uses Node.js.⁠¹⁰

The Node.js project's is-my-node-vulnerable package compares your process.version with the Node.js Security Database and treats an end-of-life version as vulnerable by default.⁠¹¹ Run npx is-my-node-vulnerable from a trusted machine, since npx downloads and runs a package.⁠¹¹ It reads a version number, so it can't tell you whether a distribution or vendor build carries a backport.

Reported Debian's tracker, read on 4 November, lists fixed brotli packages for bookworm and trixie and notes that its nodejs packages use the system Brotli library, yet still marks nodejs 18.20.4 (bookworm) and 20.19.2 (trixie) as vulnerable.⁠¹² Check your distribution's tracker before concluding either way.

Your three options

Upgrade to a supported line

Node.js lists 22, 24 and 26 as LTS, and each carries the fix at 22.23.4, 24.22.1 and 26.12.1 or later.⁠²⁠⁸ Reported HeroDevs says a move within a supported line is a patch-level change, while leaving 18 or 20 can mean native module rebuilds, OpenSSL behavior changes and dependency conflicts.⁠⁵ Rebuild every image and executable that embeds the runtime, then restart. CISA's guidance, as BleepingComputer reports it, says the same.⁠⁷ Opinion Aim for 24 or 26. The Node.js blog gives April 2027 as the end of 22's support, so 22 only buys a few months.⁠⁹

Buy commercial extended support

The Node.js project calls this a temporary solution.⁠¹ Its EOL page names three vendors in the OpenJS Ecosystem Sustainability Program: HeroDevs (Never-Ending Support), NodeSource (upgrade assessments and an upgrade program) and TuxCare (Endless Lifecycle Support, with fixes backported from upstream).⁠¹

These offerings are not equivalent. An upgrade assessment or upgrade program helps you migrate, and it does not give you a patched runtime. Only a maintained build helps if you must stay on an unsupported line. Before you pay, get written answers to four questions:

1. Does the vendor ship a maintained build for your exact Node.js version and platform, meaning operating system, architecture and package or container format?
2. Does that build's changelog or advisory name CVE-2026-111497, and what is the build number?
3. How will you receive future fixes for the same line?
4. Is the fix in a binary you can verify on your hosts after you install it?

Reported HeroDevs, which sells this product, said on 23 October that it will ship remediated builds for end-of-life Node.js starting with 20.x, then 18.x, then the remaining lines.⁠⁵ Its NES page lists support for 12, 14, 16, 18 and 20 and doesn't mention 25, 23 or 21.⁠¹³ We couldn't confirm that a Node2Shell build has shipped, and we haven't checked NodeSource's or TuxCare's status for this CVE.

Reduce exposure and accept the risk

Treat this as a stopgap with an end date. These measures reduce exposure; they don't fix the decoder. Two paths matter: the built-in fetch(), which decodes Brotli responses, and body-parsing middleware that inflates compressed request bodies.⁠⁵ Reported Imperva reported code execution against the official Node.js 24.22.0 Linux arm64 image through both paths, though not on every attempt. HeroDevs says other architectures and the 22.x and 26.x lines weren't tested, and 24.22.1 rejected the same input.⁠⁵

CISA's guidance, as BleepingComputer reports it, says teams that can't update should block incoming Brotli-compressed requests at the proxy or firewall, or disable Brotli decoding.⁠⁷ That covers inbound traffic only. Blocking Content-Encoding: br on incoming requests does not protect outbound decoding: an application that fetches a response from a server an attacker controls still runs that response through the decoder. A WAF is a temporary layer, not a repair.⁠²

So for outbound traffic, disable or restrict untrusted fetches, and use allowlists of destinations where practical. The aim is to keep attacker-controlled Brotli responses away from vulnerable decoding paths. Opinion Stopping every fetch of user-supplied URLs is the broadest version of this, and many applications won't need to go that far. Allowlisting is the more reliable control, because a hostile server can send whatever encoding it likes. Isolate the service as well. How to limit Brotli in an Express app covers the application-level steps. Updating the npm package named brotli changes nothing, because the flaw is in the Node.js binary.⁠⁵

Do this

Do today

1. List every runtime on an end-of-life line, internet-facing ones first, including bundled and vendor-supplied Node.js.
2. Block inbound Brotli at the proxy for apps that can't move yet. Disable or restrict untrusted outbound fetches, with destination allowlists where practical.
3. Pick a path, a date and an owner: upgrade, bridge or accepted risk. The update steps for supported lines apply once you land on 22, 24 or 26.

Do this week

4. Put the upgrade on a ticket with an owner and a date.
5. Test native modules and OpenSSL differences in staging.
6. Check Docker base images and CI caches for pinned 18, 20 or 25 tags.
7. If you choose a vendor bridge, get the written answers listed above and verify the build on one host before you rely on it.

Can wait

8. Choosing between 24 and 26 on minor feature differences.
9. Dependency modernization that isn't tied to the upgrade.