When Node.js patched an out-of-bounds write in its Brotli decoder on 21 October, we covered it in The Brotli Bomb. At the time, the main known risk was servers that fetch content from other sites. New research published on 26 October changes that picture: the bug now has a name, Node2Shell, a critical score, and a second way in.
The short answer: upgrade to Node.js 24.22.1, 22.23.4 or 26.12.1 or later. If you run Express 5, your server can be reached through ordinary incoming requests, so don't treat this as a low-priority client-side bug. There is no official workaround.
What changed
- It's now rated critical. Google, which assigned the CVE, scores it 9.2 under CVSS v4: network attack, low complexity, no login and no user interaction needed. Node.js itself still labels it high.
- It has a name. Akamai's analysis calls it Node2Shell and says 61% of the networks it monitors run affected Node.js versions.
- The root cause is clear. When a Brotli stream contains an invalid block switch, the vulnerable decoder waits for more input instead of rejecting the data. It keeps appending bytes to an 8-byte internal buffer and writes past the end of it. That can crash the process, leak memory, or lead to code execution.
The new risk: Express servers
Express 5 and body-parser 2 automatically decompress request bodies sent with . That means an attacker can send a malicious compressed body straight to your API, and your server decodes it before any of your code runs. You no longer have to be fetching attacker-controlled URLs to be exposed.
According to Akamai, the vulnerable decoder is reached through:
- Express 5 and body-parser 2, which decode Brotli request bodies by default (incoming attacks).
- The built-in fetch(), which decompresses Brotli responses, so a malicious server can attack the client: webhooks, link previews, scrapers, image proxies and AI agents that call tools.
- Direct use of node:zlib on untrusted data, through brotliDecompress() or createBrotliDecompress().
A bare Node.js HTTP server does not decompress request bodies on its own. If you use another framework, check whether its body parser decompresses Brotli. Next.js apps remain exposed through server-side fetch on a vulnerable Node.js runtime.
It's not only Node.js
The bug sits in Google's Brotli library, which Node.js bundles. Rapid7 notes that the same upstream flaw reaches other software that ships the library, including Bun, Python's brotli and brotlicffi packages, .NET, Envoy, Istio, brotli4j and some operating system packages. Having the library installed doesn't automatically mean you're exposed, but check each vendor's advisory and update.
Is it being exploited?
Not that anyone has reported. As of 27 October, Rapid7 knew of no exploitation in the wild, the CVE is not on CISA's Known Exploited Vulnerabilities list, and no public proof of concept has been reported. That's the window to patch: PHP2Shell went from patch to public exploit in four days.
How to fix it
- Upgrade Node.js to 24.22.1, 22.23.4 or 26.12.1 or later. Node.js 20, 23, 25 and older are end-of-life and get no fix; move to 24.x or 22.x.
- Rebuild containers on a pinned patched tag such as with caching off, then redeploy.
- Restart every Node process (PM2, systemd, serverless functions) and confirm with inside each running container.
- Update other Brotli users: Bun, Python services, .NET apps and Envoy or Istio proxies.
Can't upgrade today? Reduce the risk
None of these is a fix, but they close the most likely paths while you schedule the upgrade:
- Turn off body decompression in Express if your API doesn't need compressed request bodies, for example . Compressed bodies are then rejected with HTTP 415.
- Reject Brotli request bodies at your reverse proxy. In NGINX, for example: . Browsers almost never send compressed request bodies, so this rarely breaks anything.
- Limit outbound fetches to trusted hosts, and pause features that fetch arbitrary user-supplied URLs.
- Restrict network access to internal Node.js services so only the systems that need them can reach them.
Need help?
Peham runs Node.js and Next.js in production for clients and for our own SaaS products. Our Cloud & DevOps team can find every vulnerable runtime across your servers and containers, upgrade them and verify the fix.
Book a free 30-minute runtime security check and talk it through with our engineers.
