Node2Shell: what the October Node.js security release means for your apps

On Wednesday 21 October 2026, the Node.js project shipped security updates for all three of its supported release lines. The batch fixes ten vulnerabilities. The one drawing attention is CVE-2026-111497, nicknamed "Node2Shell": a flaw in Node's built-in Brotli decoder that the project rates high severity and says can permit remote code execution.

If your product runs on Node.js, and a lot of web apps, APIs, SaaS back ends and Amazon seller tools do, this is a patch for this week rather than next quarter.

What has actually changed?

Node.js published fixed versions 22.23.4, 24.22.1 and 26.12.1 (Node.js security release). Of the ten flaws, four are rated high, three medium and three low.

Node2Shell sits in Brotli decompression. Brotli is a compression format used widely for web traffic, alongside gzip. The advisory describes the bug as an out-of-bounds write in the decoder, meaning data can be written past the end of a memory buffer. Bugs of that kind can sometimes be turned into running an attacker's code on your server.

The other three high-severity issues matter for anything that makes outbound connections. One affects how dns.resolve handles names containing a null character. Two allow TLS (the encryption behind HTTPS) hostname checks to be bypassed in edge cases involving IP addresses.

The medium-rated fixes include a keep-alive socket issue and a flaw where crypto.randomUUID() and randomInt() can repeat values in apps built from snapshots or single executable applications. If you use those features to generate tokens or IDs, that one deserves a look too.

The release also updates bundled components, including OpenSSL, c-ares, Undici and the trusted certificate store.

Does this apply to you?

Very likely, if you run Node.js 22, 24 or 26 and haven't upgraded since 21 October.

The official advisory doesn't say exactly what input triggers Node2Shell, or whether default setups are reachable. Researchers at Imperva published their own analysis on 22 October (Imperva). In their testing, two routes worked:

an app using Node's built-in fetch() to read a Brotli-compressed response from a server the attacker controls;
an app on Express 5.0.0 to 5.3.0, or body-parser 2.0.0 to 2.3.0, that decompresses incoming request bodies.

They also note that a bare Node.js HTTP server doesn't decode Brotli bodies simply by receiving them, and that exploitation took several attempts in their lab. None of the sources we checked report attacks in the wild as of 23 October. That is a reason to patch calmly, not a reason to wait.

Two groups need extra attention.

Teams on end-of-life versions. Node.js 20 reached end of life on 30 April 2026, and versions 23 and 25 are also unsupported (Node.js release schedule). The project's position is that end-of-life versions are always affected when a security release lands, and they get no fix.

Teams who aren't sure what's running. Container base images, CI runners, serverless functions and bundled binaries often pin a Node version nobody has checked in months. Upgrading your laptop or one server doesn't patch those.

What should you do this week?

Find every place Node.js runs. Production servers, containers, serverless functions, build pipelines and internal tools. Record the exact version (node --version) for each.
Upgrade within your line. Move to 22.23.4, 24.22.1, 26.12.1 or later. Rebuild and redeploy container images rather than only patching hosts.
Plan your way off Node 20, 23 or 25. If anything still runs on them, treat moving to a supported line as a priority project, not a backlog item.
Review where you decompress untrusted input. Check which routes parse compressed request bodies, especially if you run Express 5 or body-parser 2, and whether they need to accept Brotli from the public at all.
List outbound fetch() calls to servers you don't control. Webhooks, scrapers and third-party integrations come first in your patch order.
Check your scanning covers the runtime. Many dependency scanners only read package.json. Make sure something flags an out-of-date Node binary or base image too.
Keep the evidence. Note what you patched, where and when. If you're working towards SOC 2, ISO 27001 or Cyber Essentials, dated patch records are exactly what an assessor will ask to see.

Where does this leave you?

Node2Shell is serious on paper, but the fix is simple: upgrade Node.js, rebuild your images and retire unsupported versions. The harder part is usually knowing where every copy of Node lives, and proving afterwards that each one was patched.

That's the part we build into our own delivery. Our application development work includes dependency and secret scanning on every commit, and our support plans cover dependency patches and security monitoring with agreed response times. If you'd like a second pair of eyes on how your team handles runtime updates, have a look at how we build and maintain applications.