Node2Shell: is the Brotli flaw hiding in your Node.js?

Short read

This post covers Node2Shell (CVE-2026-111497), a critical flaw in the Brotli compression library that ships inside Node.js and many other products. CISA added it to its list of actively exploited vulnerabilities on 27 October, and attack attempts have already been logged against honeypots.

You'll learn why you may be exposed even if nobody on your team ever chose to use Brotli, how to find the Node.js you're actually running, and what signs of a failed or successful attack look like in your logs.

Node2Shell is the name given to CVE-2026-111497, a critical vulnerability in Google's Brotli decompression library. It matters to far more organisations than the word "Brotli" suggests, because Brotli is bundled inside Node.js and a long list of other software. On 27 October, the US Cybersecurity and Infrastructure Security Agency (CISA) added Node2Shell to its Known Exploited Vulnerabilities catalogue, and security firms have recorded the first attack attempts.

This article explains what Node2Shell is, why it can reach you without anyone choosing to use Brotli, and the practical steps that tell you whether you're exposed and whether anyone has tried their luck.

What Node2Shell is

Brotli is a compression format used, among other things, to shrink web traffic. According to SecurityWeek, the flaw is an out-of-bounds write in the Brotli decoder affecting versions 1.0.3 to 1.2.0. With specially crafted compressed data, an attacker could crash the application, expose the contents of its memory, and potentially run their own code.

Akamai's analysis describes the root cause: when a malformed stream signals an invalid switch between block types, the vulnerable decoder treats it as "waiting for more input" rather than an error, and keeps writing past the end of a small internal buffer. No login is needed. The CVSS score is 9.2, which is critical.

Node.js and Google released fixes on 21 October. Microsoft, Bun, Envoy, Istio and the maintainers of two Python packages have also shipped fixes, and Palo Alto Networks is rolling out hotfixes for PAN-OS, according to SecurityWeek.

Why you might be exposed without knowing it

The awkward part of Node2Shell is that most applications don't call Brotli directly. Akamai lists three routes by which attacker-supplied Brotli data can reach the vulnerable decoder in Node.js:

• The node:zlib module, where an application decompresses untrusted input.
• The built-in fetch() API, which automatically decompresses Brotli responses. A malicious or compromised server can therefore target the application calling it.
• Express 5 and body-parser 2, whose parsers decompress request bodies sent with Brotli encoding by default. Any client can send one.

Node.js also turns up inside products you might not think of as "a Node.js app". Broadcom warned on 27 October that SDDC Manager in VMware Cloud Foundation and vSphere Foundation is affected because it uses Node.js. SecurityWeek reports that Broadcom rates it critical for SDDC Manager 9.1.1, that patches are still pending, and that workarounds have been published.

The scale is significant. Akamai says its telemetry shows 61% of networks running affected Node.js versions, and Wiz told The Hacker News that 91% of cloud environments have resources vulnerable to the flaw.

What attackers are doing so far

The early activity is real but rough. SecurityWeek reports that Previdian recorded an exploitation attempt on 27 October, and that ELLIO's sensors caught a malicious request aimed at Node.js 24.22.0 on x86-64 on 26 October, after a public tool had been used the day before to find which hosts process Brotli data.

ELLIO says the attacker's final stage was broken and produced no shell in 50 tests. That's not a reason to relax. ELLIO itself achieved code execution against four different setups running official Node.js builds, Imperva has demonstrated code execution on an official Node.js image, and the attacking IP address had previously been seen exploiting PHP2Shell. ELLIO also warns that failed attempts can crash the target process, so the flaw can be used to knock services over even when it doesn't hand over control.

What to do now

1. Find every Node.js you run. Include containers, build servers, internal tools and third-party appliances, not just your main web app. Discontinued release lines (25.x, 23.x, 20.x and earlier) won't get a fix, according to Akamai.

2. Upgrade to a fixed version. Node.js fixed the flaw in 22.23.4, 24.22.1 and 26.12.1. Akamai notes the Node.js advisory offers no workaround, so upgrading is the only complete fix. For other products, follow each vendor's advisory, and track Broadcom's pending patches and workarounds if you run VMware Cloud Foundation.

3. Check the right version number. ctxsec's write-up of ELLIO's findings points out that the reported Brotli version reads 1.2.0 on both patched and unpatched Node.js builds, so check the Node.js release version instead.

4. Look at your logs for signs of attempts. The same write-up suggests watching for:

• inbound requests with Content-Encoding: br and unusually large bodies, which are rare in normal traffic
• bursts of Node.js crashes or restarts straight after such requests
• crash dump files, which can contain other users' session cookies and tokens, so restrict who can read them and delete them promptly

5. Reduce exposure while you patch. Akamai suggests segmenting Node.js services to limit who can reach them and turning off compressed request bodies where you can.

The bigger lesson

Node2Shell arrived days after PHP2Shell, and both follow the same pattern: a flaw in a common building block, buried inside software that never advertises it, with attackers scanning within days of disclosure. Patching quickly matters, but so does knowing what you run and having someone watching for the crashes, odd requests and unexpected processes that show an attempt has been made. Our platform overview explains how we approach that.