Node2Shell Vulnerability (CVE-2026-111497): What It Is and How to Patch Node.js

The Node2Shell vulnerability, tracked as CVE-2026-111497, is a flaw in the Brotli decoder that ships inside Node.js. Crafted compressed data can corrupt memory in a running Node.js process, which can crash it, leak what is in memory, or let an attacker run code on your server. Node.js fixed it on October 21, and on October 27 CISA added it to its catalog of vulnerabilities being exploited in the wild. This guide explains who is exposed, which versions fix it, and the order we patch in so nothing is missed.

What Node2Shell is

The official Node.js security release of October 21, 2026 describes it plainly. An invalid block switch in a Brotli stream was treated as a temporary need for more input instead of a format error, so the decoder kept appending bytes to a small eight-byte internal buffer until it wrote past the end. Node.js rates it high severity. In its words, an attacker who can supply Brotli data that an application decompresses with node:zlib can corrupt process memory.

"Node2Shell" is a nickname used by security researchers and press, not by the Node.js project. You may also see it called Broccoli2Shell, because the root bug is in Google's Brotli library rather than in Node.js code itself.

The same release fixed nine other CVEs, including several in TLS hostname checks and DNS lookups. Upgrading fixes all of them at once.

Is it being exploited?

Yes, which is why this deserves attention this week rather than in your next maintenance window:

• •Public proof-of-concept exploits are on GitHub, according to Help Net Security.
• •CISA added CVE-2026-111497 to its Known Exploited Vulnerabilities catalog on October 27, 2026.
• •Researchers at ELLIO, as reported by GBHackers, reproduced code execution against unmodified Express and Koa apps and an official Node.js container, and recorded exploit traffic on October 26.

Two details from that research matter for planning. A shell runs with the privileges of the Node.js process, so a container running as root gives the attacker root. And failed attempts can still crash workers, so even an unsuccessful attack can take your API down.

Are you exposed?

Running a vulnerable version is not the whole story. The risk depends on whether your app decompresses Brotli data that someone outside can control. That can happen in more places than most teams expect:

• •Inbound requests with a Content-Encoding: br header.
• •Body-parsing middleware that decompresses request bodies before your route handler runs.
• •Outbound `fetch()` calls, where a compressed response from a server you call is decoded for you.
• •Your own code that decompresses uploads, webhooks, or queued payloads with node:zlib.

If you have to choose where to start, patch public-facing services first: APIs, webhook receivers, and anything that accepts uploads. Then move to internal workers that call outside services, because a compromised or spoofed third party can send a malicious compressed response. Do not try to prove a service is safe by reading code. Patching is faster than auditing every dependency that might decompress a body.

Help Net Security also lists other software that bundles Brotli and has shipped or is shipping its own fixes, including .NET, Bun, Envoy Proxy, Istio, Python HTTP clients, FFmpeg, Apache Arrow, and ClickHouse. If those are in your stack, check each vendor's advisory too. The fixed Brotli library versions are 1.0.10, 1.1.1, and 1.2.1.

Which versions fix it

Upgrade to one of these releases:

• •Node.js 26.x: 26.12.1
• •Node.js 24.x: 24.22.1
• •Node.js 22.x: 22.23.4

If you are on Node.js 20, 23, or 25, there is no patch. Those lines are end of life, and the Node.js project notes that end-of-life versions are always affected when a security release ships. Moving to a supported line is the fix. Our guide to the Next.js 15 end of life covers the same problem one layer up: unsupported software stops receiving exactly these fixes.

This is also separate from the October 2026 Next.js security patch. Upgrading Next.js to 16.4.1 does not change the Node.js runtime underneath it. Most Next.js apps need both.

How to patch, in order

1. 1.Find every runtime. List each place Node.js runs: app servers, Docker images, background workers, CI runners, build images, and serverless functions. Teams usually patch the API and forget the worker or the image used for scheduled jobs.
2. 2.Upgrade Node.js. Bump the version in .nvmrc, the engines field, Dockerfiles, and CI configuration. Pin a fixed base image tag such as node:24.22.1 rather than a floating tag you have not rebuilt.
3. 3.Rebuild and restart. A new lockfile does nothing here, because the bug is in the runtime binary, not in an npm package. Rebuild container images and restart every long-running process.
4. 4.Verify what is running. Check the version reported by live workloads, not your laptop. Researchers warn that process.versions.brotli may still show the old library version on patched builds, so check the Node.js version itself.

On managed serverless platforms, you usually choose the major version and the provider supplies patch releases. Check the provider's notice for when the fixed build rolled out, then redeploy so new instances use it. With containers, the base image is your responsibility.

A stopgap while you patch

If a service cannot be upgraded today, refuse Brotli-encoded request bodies at the edge or in your app. This closes the inbound path only. It does not protect fetch() calls to outside servers, so it is a stopgap, not a fix:

// Temporary: refuse Brotli request bodies until the runtime is patched.
// Register before any body parser.
app.use((req, res, next) => {
  const encoding = String(req.headers["content-encoding"] ?? "").toLowerCase();
  if (encoding.split(",").some((e) => e.trim() === "br")) {
    return res.status(415).send("Unsupported Content-Encoding");
  }
  next();
});

Two other quick wins: run Node.js as a non-root user, so a successful exploit gets less, and turn off core dumps in production, because a crash can write process memory, including secrets, to disk.

If you think you were hit

Signs include unexplained worker crashes since mid-October, large requests with Content-Encoding: br in your logs, and unfamiliar processes or outbound connections from your Node.js hosts. Because the flaw can disclose process memory, treat any environment variables and keys that process could read as exposed. Our guide on how to rotate secrets after a breach gives the order to do that in.

How we handle runtime patches for clients

Every app we build and maintain pins its Node.js version in one place and rebuilds its images in CI, so a runtime patch is a version bump, a rebuild, and a deploy rather than a hunt. Keeping runtimes on supported lines is part of how our web app development service looks after products after launch, alongside framework updates like the Next.js patch above.

The bottom line

The Node2Shell vulnerability is serious because it sits in the runtime, it can be reached through ordinary request handling, and it is already being exploited. The fix is simple: move every Node.js process to 22.23.4, 24.22.1, or 26.12.1, rebuild and restart, and confirm the running version. If you are still on an end-of-life line, this is the push to move.

Need help finding and patching every Node.js runtime in your stack? Contact us and we will take a look.