You build on Node.js, you saw “Node2Shell” on three different timelines, and you want to know one thing before the next standup: do I have to drop everything? The short version is that Node2Shell, tracked as CVE-2026-111497, is serious, it has a clean fix, and it is narrower than the name suggests.
The longer version is below. We are keeping the claims to what the CVE record and the security vendors have actually published.
What Node2Shell (CVE-2026-111497) is
It is an out-of-bounds write in the Brotli decoder that Node.js bundles. Brotli is a compression format. When a client or server sends data with Content-Encoding: br, something has to unpack it, and in Node that something has the bug.
According to the CVE record, a remote attacker with no login can send a crafted Brotli stream that corrupts memory next to the decoder's state. Depending on the situation that can leak memory, crash the process, or possibly run code. The score on CVSS 4.0 is 9.2 in the CVE record, while Node.js itself rates it High and did not publish its own scores for the batch.
The part people skip: it needs Brotli data to reach the decoder
This is why the name oversells it a little. A bare Node.js HTTP server does not decode an incoming Brotli body just because it received one. The flaw triggers when your code, or a library you use, actually decompresses data that an attacker controls.
Node2Shell is not “every Node server is one request from takeover.” It is “anywhere you decompress Brotli from a source you do not trust.”
Typical places that happens:
- An Express 5 app using body-parser 2.x to read request bodies, where a client sends a Brotli-compressed payload.
- Outbound fetch() calls to a server you do not control, which returns a malicious Brotli response.
- Direct use of Node's compression APIs on data that came from outside.
That second one is the awkward case. If your backend fetches third party URLs (link previews, webhooks, scrapers, anything that pulls external content), the attacker does not need to send you anything. They only need you to fetch their server.
How bad is it in practice?
There is a public proof of concept. Imperva reported code execution against an unmodified Node.js 24.22.0 build on Linux arm64, though it took multiple attempts. A separate public write-up reportedly got code execution only on a deliberately weakened build, and on a standard build saw a crash and a limited memory read. In plain terms: exploitation is possible, it is not yet reliable, and nobody has confirmed attacks in the wild as of the reports we read on 23 October.
That window is when you patch. Reliable exploits tend to arrive after the first awkward proof of concept, not before it.
The fix
Upgrade the Node.js runtime itself. The fixed versions are 22.23.4, 24.22.1 and 26.12.1, released on 21 October 2026. Updating npm packages does not fix it, because the decoder is inside the runtime. Google's Brotli library has its own fixes in 1.0.10, 1.1.1 and 1.2.1 if you bundle it elsewhere.
The next post walks through how to check whether your Node app is exposed, and the one after covers what to do about old Node versions.
We build Node.js and Next.js backends for businesses in Delhi NCR and across India, and we are happy to look at yours. Start with our Node.js security patching service page, read how we approach Next.js development in Delhi NCR, or send us your stack and we will tell you whether Node2Shell is your problem.