Key takeaways
- CVE-2026-111497 is an out-of-bounds write in Google's Brotli decompressor, the C library that Node.js, .NET, Python packages and many other tools copy into their own code. It is nicknamed Node2Shell (also Broccoli2Shell / HTTP2Shell) (Akamai).
- What changed in the last few days: CISA added it to its Known Exploited Vulnerabilities catalogue on 27 October with a 10 November deadline, and Singapore's CSA issued an active-exploitation alert on 30 October (Rescana, CSA Singapore).
- Fixed versions: Node.js 22.23.4, 24.22.1, 26.12.1; .NET 8.0.33, 9.0.22, 10.0.14; Brotli 1.0.10 / 1.1.1 / 1.2.1; Python
brotli1.2.1. Node 20, 21, 23 and 25 get no fix. - You are exposed only if your app decodes Brotli data an attacker controls — but Express 5 body parsers and Node's built-in
fetch()do that by default. - There is no Node.js workaround. Upgrade, rebuild container images and restart processes; patching the host package alone does not fix a running service.
1. What the bug is, in plain terms
Brotli is the compression format behind Content-Encoding: br on the web. When the decoder met a malformed "block switch" in a compressed stream, it treated it as "wait for more input" instead of an error, and kept writing bytes past the end of a small 8-byte internal buffer. That is a classic memory-corruption bug, and the upstream fix simply returns a format error instead (Akamai).
Affected upstream releases are Brotli 1.0.3 to 1.2.0. The fix was committed quietly in February 2026, but no release or advisory followed until Node.js disclosed and patched on 21 October (Help Net Security). Because so many projects vendor (copy) the decoder rather than link to a system library, every one of them needs its own patched build.
How bad is it? Ratings differ: NVD scores it 9.8 (CVSS 3.1), Google 9.2 (CVSS 4.0), Node.js calls it High and Microsoft rates the .NET exposure 8.1 with high attack complexity (Rescana, HeroDevs).
2. Is it really being exploited?
The evidence, in order:
| Date | Event | Source |
|---|---|---|
| 21 Oct | Node.js security releases; Brotli 1.0.10 / 1.1.1 / 1.2.1 published | Qualys |
| 25 Oct | Microsoft ships out-of-band .NET fixes | The Next Web |
| 26 Oct | ELLIO reports exploit traffic in the wild (observed chain crashed the process rather than running code) | Help Net Security |
| 27 Oct | Added to CISA KEV, due 10 Nov | Rescana |
| 30 Oct | CSA Singapore alert: public PoC, reportedly exploited | CSA |
Imperva reported getting code execution on the official Node.js 24.22.0 Linux arm64 image "after multiple attempts" but has not released its exploit. Other researchers argue that public PoCs only crash a process or work on weakened builds (The Next Web). For planning, treat it like this: a remote crash (denial of service) is easy today; remote code execution is demonstrated but harder. Either is reason enough to patch an internet-facing API this week.
3. Who is actually exposed
The bug only fires when your process decompresses Brotli data from someone you don't trust. That happens in more places than people expect:
| Setup | Exposed by default? | Why |
|---|---|---|
Express 5 / body-parser 2 (express.json(), urlencoded, text, raw) |
Yes | inflate defaults to true, so a request with Content-Encoding: br gets decoded before your code runs |
Node app calling fetch() to third-party URLs (webhooks, scrapers, link previews, payment/OTP vendor APIs) |
Yes, for responses | Built-in fetch() auto-decompresses br responses |
Code using zlib.brotliDecompress() / createBrotliDecompress() on uploads |
Yes | Direct decoding of untrusted input |
Bare http.createServer without a body parser |
No | Node doesn't decode incoming bodies by itself |
| ASP.NET Core / .NET apps | Only if enabled | Exposed via request-decompression middleware with br, HttpClient AutomaticDecompression set to Brotli or All, or direct BrotliStream use |
| .NET Framework 4.x | No | Not affected |
Python apps using brotli / brotlicffi (e.g. via HTTP clients) |
Yes if decoding remote content | Fixed in 1.2.1 / 1.2.1.0 |
Sources: Akamai, HeroDevs, Rescana.
Also reported as affected or patched: Bun (upgrade to 1.4.4+), Envoy and Istio, FFmpeg, ClickHouse and Apache Arrow (Help Net Security). Linux distributions are shipping patched brotli packages; check your distro's security tracker for the CVE rather than trusting a version string.
4. Which version do you need?
Node.js (check with node -v on every host and inside every container image):
| Line | Status (Nov 2026) | Fixed release |
|---|---|---|
| 26.x | Active LTS since 28 Oct | 26.12.1 |
| 24.x | Maintenance LTS | 24.22.1 |
| 22.x | Maintenance LTS | 22.23.4 |
| 25.x, 23.x, 21.x | End of life | None — move to 24 or 26 |
| 20.x and older | End of life (20.x ended 30 Apr 2026) | None — move to 24 or 26 |
.NET (check with dotnet --list-runtimes):
| Line | Fixed release | Note |
|---|---|---|
| .NET 10 | 10.0.14 | LTS |
| .NET 9 | 9.0.22 | Support ends 10 Nov 2026 |
| .NET 8 | 8.0.33 | Support ends 10 Nov 2026 |
| .NET 11 | RC3 | Preview |
| .NET 6 / 7 | No Microsoft fix | Out of support; vendored decoder reported unpatched |
Sources: Qualys, HeroDevs, Rescana.
If you were already planning the move to Node 26, our Node.js 26 LTS upgrade guide covers what breaks. For .NET 8 and 9 shops, note that the patch lands days before both lines go out of support — budget the jump to .NET 10 now.
5. The India angle
A large share of Indian agency-built and startup backends run Node.js on a single VPS or a small Kubernetes cluster, often pinned to whatever version was current at launch. Node 20 was the default "safe LTS" for most of 2024–25 and is now end of life with no fix. That is the most common gap we expect to see.
Three practical points for Indian teams:
- Payment, OTP and KYC integrations use
fetch()or SDKs built on it. A compromised or spoofed upstream returning craftedbrresponses is a realistic path. Patch even "internal" services that only call out. - CERT-In's 2022 directions require reporting certain cyber incidents within six hours of noticing them (CERT-In directions). If you see unexplained Node process crashes on a public API since 26 October, investigate and log it rather than just restarting.
- Patching costs nothing in licences; the cost is engineering time. A same-line bump (22.x → 22.23.4) is usually a one-line Dockerfile change. A jump from 20 to 24/26 is a small project — plan a day of testing per service, not a weekend rewrite.
6. A 48-hour plan
- Inventory (2 hours). List every Node, Bun and .NET runtime: servers, Docker images, CI runners, serverless functions, and bundled runtimes in Electron or desktop tools.
node -v,dotnet --list-runtimes,pip show brotli. - Patch internet-facing services first. Bump base images (
node:22.23.4,node:24.22.1,node:26.12.1), rebuild, redeploy, and restart — running processes keep the old decoder. - Stop-gap where you can't patch today. On Express 5 / body-parser 2, set
inflate: falseon body parsers you don't need compressed input for — encoded requests then get HTTP 415 before any decompression (Akamai). At the reverse proxy or WAF, cap request body size. Neither protects outboundfetch()responses. - .NET: install the October out-of-band runtime, then search your code for
AutomaticDecompression,UseRequestDecompressionandBrotliStreamto know where you were exposed. - Look back. Review logs since 21 October for crashes or 5xx spikes on endpoints that accept JSON or form bodies, and requests carrying
Content-Encoding: brfrom unusual sources. - Retire EOL lines. Any Node 20/21/23/25 or .NET 6/7 service gets a migration ticket with a date.
7. Bottom line
Node2Shell is not a "the internet is on fire" bug like a pre-auth RCE in a VPN appliance — exploitation for code execution is still hard and the exposure depends on how your app handles compressed input. But it is on CISA's exploited list, crashing a vulnerable Express 5 API is easy, and the fix is a minor-version bump. Do it this week, and use it as the push to get off end-of-life runtimes.
Need someone to inventory and patch your Node.js or .NET servers, containers and CI images? Our managed IT services team handles patch cycles like this end to end — and you can check your server headers and TLS setup with our free HTTP headers checker and uptime & SSL check.