Node2Shell Is Now Under Active Exploitation
CISA added CVE-2026-111497 — the critical Brotli decoder flaw in Node.js known as "Node2Shell" — to its Known Exploited Vulnerabilities catalog on October 27, 2026, with a November 10 fix deadline for federal systems. Exploit traffic is already being logged against unpatched builds in the wild, and researchers put the number of still-exposed, end-of-life Node.js instances at roughly 1.7 million.
Node.js shipped a fix for CVE-2026-111497 on October 21, 2026: an out-of-bounds write in the runtime's bundled Brotli decoder that lets a remote, unauthenticated attacker corrupt memory — and in the worst case run arbitrary code — just by having a vulnerable server decompress a crafted Brotli-encoded payload. Qualys and Rapid7 both scored it critical (CVSS v4.0 base 9.2), and within days independent researchers at Cycode, Ellio, and Imperva had published working proof-of-concept exploit chains under the nickname "Node2Shell." That was enough for CISA: on October 27 the agency added CVE-2026-111497 to its Known Exploited Vulnerabilities catalog, which comes with a hard November 10, 2026 remediation deadline for federal agencies and functions as the industry's loudest possible signal that this is not a theoretical bug. SecurityWeek reported honeypots logging real exploitation attempts within days of the KEV listing, including traffic traced to US-based infrastructure.
The patch itself is simple — move to Node.js 22.23.4, 24.22.1, or 26.12.1 (Bun shops need 1.4.4) — which is exactly why the lingering exposure is so avoidable and so common. Every active Node.js release line prior to the October 21 patch is affected, but the real long tail is the estimated 1.7 million internet-facing instances still running end-of-life branches like Node 20, 23, and 25, which will never get an official fix because their support window has already closed. Those systems do not have a "patch now" option; they have a "migrate off an unsupported runtime" problem, and that is a materially bigger job than bumping a version pin in a lockfile.
Why "just upgrade Node" undersells the actual work
For a team on a currently supported Node line, this genuinely is a dependency bump — update the runtime, redeploy, move on. For a team still running an EOL branch, the honest scope is a migration: validating that native modules, build tooling, and framework versions all work on a supported Node release, then re-testing the application end to end before it goes anywhere near production traffic that an exploit scanner could already be probing. That is precisely the kind of unglamorous, load-bearing engineering work that gets deprioritized every single sprint until an advisory like this one forces the conversation — and by then the team doing the work is often racing a KEV deadline instead of a planned maintenance window. Bringing in a web development team that has handled runtime migrations before tends to compress that timeline considerably, because the dependency-compatibility audit and the regression-testing pass are work they have already done on someone else's legacy stack.
What to check this week
The practical checklist for any team running Node.js in production right now: first, confirm the exact runtime version on every service, including background workers and build pipelines, not just the customer-facing API — Node2Shell is exploitable anywhere Brotli decompression happens on untrusted input. Second, for supported branches, patch immediately; this is a same-day change, not a backlog item. Third, for anything on an EOL line, scope the migration now rather than waiting for a scanner alert, because the gap between "we know we should upgrade" and "we actually upgraded" is exactly where Node2Shell-style exploitation finds its targets.
- Inventory every Node.js process that touches HTTP traffic, including internal services and CI runners — Brotli support ships by default.
- Patch supported branches (22.23.4 / 24.22.1 / 26.12.1, or Bun 1.4.4) immediately; this is not a scheduled-maintenance item given active exploitation.
- For EOL branches (Node 20 and earlier), treat this as a forcing function to finally schedule the runtime migration, not just a reason to add a WAF rule.
- Re-test the full request path after upgrading — compression-handling changes have historically broken edge cases in streaming responses.
A CISA KEV listing is not a warning about the future. It means someone, somewhere, is already being hit — and the only question left is whether it is your server or the next one.