Node2Shell (CVE-2026-111497): Patch Node.js now

21 October 2026 was a double hit for IT teams. While everyone was still busy with PHP2Shell, the Node.js project released a security update on the same day: ten vulnerabilities, four of them rated “High”. The most dangerous one, CVE-2026-111497, sits in the Brotli decoder and can lead to the execution of attacker code. Imperva’s Red Team named it Node2Shell.

Node.js powers countless online shops, customer portals, APIs, internal tools, build servers and desktop apps. Often nobody knows exactly where a Node version is running. That is what makes this update tricky.

This article explains what the four most important flaws mean, how to find out whether you are affected and how to patch step by step.

What is Node2Shell?

Brotli is a compression format browsers and servers use to transfer data in smaller form. Node.js ships its own Brotli decoder. With a specific malformed stream, the decoder mistakes the error for “more input needed” and keeps writing into an internal buffer of just eight bytes. In the worst case, the attacker decides what ends up in memory next.

The consequences range from a crash to memory disclosure to code execution with the privileges of the Node.js process. Google, as the CNA, rates the flaw CVSS 9.2 (critical); the Node.js project rates it “High”.

Any application that decompresses Brotli data from an untrusted source is affected. That happens more often than you might think:

• The built-in fetch() asks HTTPS servers for Brotli-compressed responses by default. If your application fetches from external or manipulable servers, a crafted response may be enough.
• Express and body-parser: According to Imperva, Express 5.0 to 5.3 and body-parser 2.0 to 2.3 with the json() and raw() parsers are an attack path, because they decompress incoming requests.
• Your own code using zlib.createBrotliDecompress() or zlib.brotliDecompress().

A bare Node.js HTTP server, on the other hand, does not decompress incoming requests on its own.

The three other “High” flaws

Node2Shell is the loudest flaw, but not the only one. Three more concern trust in connections, in other words: am I really talking to the server I want to talk to?

The two TLS flaws risk impersonation and intercepted data; the DNS flaw may route traffic to a completely different server. This matters most for applications that connect to addresses supplied from outside, such as webhooks, link previews or integrations with a configurable target URL.

On top of that come six “Medium” or “Low” flaws, including the keep-alive HTTP agent, randomUUID() in startup snapshots and the Permission Model. Bundled libraries were updated at the same time: c-ares, the CA certificates (compromised eMudhra intermediate CA), OpenSSL, SQLite and Undici. One more reason not to weigh individual flaws but to install the whole update.

Timeline

With PHP2Shell, the gap between “proof of concept” and “real attacks” was just a few hours. Hoping it takes longer this time is not a plan.

Am I affected?

How to patch Node.js

Safe versions are 22.23.4, 24.22.1 and 26.12.1 or newer. If you are still on Node.js 20, 23 or 25, there is no fix; move to 24 (current LTS).

1. Check the version

On every server, in every container and on every build server:

node -v
# inside a running container
docker exec <container> node -v

2. Update Node.js

Depending on how Node.js is installed:

# nvm
nvm install 24.22.1 && nvm alias default 24.22.1

# fnm
fnm install 24.22.1 && fnm default 24.22.1

# Volta
volta install node@24.22.1

# macOS with Homebrew
brew update && brew upgrade node

# Debian/Ubuntu with the NodeSource repository
sudo apt update && sudo apt install --only-upgrade nodejs

Then check node -v again and restart the application. A running process otherwise keeps using the old version. With packages from your Linux distribution, check whether the fix has arrived: a few days after the release, some distributions still had no fixed packages.

3. Rebuild Docker images

An image is frozen: it contains the Node version from the day it was built. So pin a fixed version in the Dockerfile and rebuild without cache:

FROM node:24.22.1-alpine

docker build --pull --no-cache -t my-app .

Then redeploy and check the version in the running container with docker exec. Check third-party base images as well.

4. Build servers and CI

In GitHub Actions, actions/setup-node does not automatically fetch the newest version if an older one is cached. Either pin a fixed version or set check-latest:

- uses: actions/setup-node@v6
  with:
    node-version: '24'
    check-latest: true

With managed serverless runtimes (e.g. AWS Lambda), the provider usually installs updates itself. The actual version is shown in the logs or the provider’s documentation. Custom container images for serverless need to be rebuilt by you.

5. Check dependencies

npm ls express body-parser
npm install body-parser@latest

body-parser 2.4.0 and 1.20.9 additionally close a separate denial-of-service flaw on the same path (CVE-2026-111181). That does not replace the Node.js update.

6. Don’t forget

Electron apps, CLI tools and desktop applications often ship their own Node runtime. Only the vendor’s update helps there.

Stopgaps until the patch is in

Node.js lists no official workarounds. These measures reduce the attack surface but don’t replace the update:

1. If a service doesn’t need compressed requests, set body-parser’s inflate: false. This only protects incoming requests, not responses your application fetches with fetch().
2. Limit compressed requests from untrusted sources at the proxy or web application firewall. Vercel points out that WAF rules don’t cover fetched responses.
3. Strictly validate host names and target URLs supplied from outside: no NUL characters, no fullwidth digits, no IP addresses with leading zeros, hex or short notation.
4. Address internal services by host name rather than IP address when TLS is involved.

A message you can send to your agency

If a service provider runs your application, copy this text into an email:

Subject: Node.js security update of 21 October 2026

Hello

Is Node.js running in our applications, Docker images or build processes? If so: has the security update of 21 October 2026 (including CVE-2026-111497, “Node2Shell”) been installed? At least Node.js 22.23.4, 24.22.1 or 26.12.1 is required. Node.js 20, 23 and 25 no longer receive fixes.

Many thanks for a short confirmation.

Is Saldio affected?

No. The saldio.ch website consists of ready-made static files delivered via a CDN. There is no Node.js server accepting requests. Node.js only runs on our build server while the website is being generated, processes no external data there and fetches the latest version on every build. The Saldio app itself does not run on Node.js.

You don’t need to do anything. Your accounting keeps running as usual. Independently of Node2Shell, Saldio offers:

• Hosting in Switzerland, your data stays in the country.
• Sign-in with MFA and passkey via AWS Cognito, tokens are kept server-side.
• Every change in the audit log, retention according to GeBüV.

The features overview shows what belongs to security and the platform.

Conclusion

Node2Shell is serious but easy to fix: take inventory, bring Node.js to 22.23.4, 24.22.1 or 26.12.1, rebuild images, done. The hardest part is usually not the update itself but finding every place where Node.js is running. Share this article with everyone who looks after applications. A single forgotten Docker image might be what makes the difference.

And if you’d like to move your accounting to a solution without patch stress while you’re at it: try Saldio free for 7 days, no payment method required, then from CHF 15 per month according to our pricing. Until 31.01.2027, the year-end special gives you a one-time 50 % off the first year.

Take care.

Frequently asked questions

What is Node2Shell?

Node2Shell is the name Imperva's Red Team gave to CVE-2026-111497. A flaw in the Node.js Brotli decoder allows an out-of-bounds write and can lead to code execution. Google rates it CVSS 9.2.

Which Node.js versions fix the flaws?

Node.js 22.23.4, 24.22.1 and 26.12.1 and newer. Node.js 20, 23 and 25 are end of life and receive no fix; moving to 24 (LTS) is required.

Is npm update enough?

No. The flaws are in the Node.js runtime itself. You need to update Node.js on servers, in Docker images and on build servers and restart or redeploy the applications.

Is Node2Shell already being exploited?

Up to 23 October 2026, neither Node.js nor national CERTs reported attacks. Proof-of-concept code is public, though, so don't wait.

Is Saldio affected?

No. The saldio.ch website consists of static files without a Node.js server, and the Saldio app does not run on Node.js. Saldio customers don't need to do anything.