Brotli Vulnerability in Node.js: What Next.js and Node Apps Need to Patch

When I wrote up this week's October 2026 security patches, the Brotli vulnerability in Node.js was item three: a High-severity bug in the Brotli decoder that ships with Node. Three days later it's a bigger story. The bug is in Google's Brotli C library itself, the CVE record rates it 9.2 Critical, and Bun, Envoy, Istio and the Python Brotli packages have all shipped fixes.

Imperva's red team named it Node2Shell. They showed code running inside an app on the official Node.js 24.22.0 image, and the same input was rejected on 24.22.1.

If you run a Next.js site, a Node API or anything that fetches data from other servers, here's what I'd check.

Brotli is a compression format, the br you see in Content-Encoding headers. CVE-2026-111497 is an out-of-bounds write in the Brotli decoder. According to Node.js, an invalid block switch was treated as "send me more input" instead of a format error, so the decoder kept writing input into an eight-byte internal buffer past its end.

Node.js says an attacker who can get your app to decompress their Brotli data through node:zlib can crash the process, read process memory, or run code.

The CVE record lists Google Brotli 1.0.3 through 1.2.0 as affected, with fixes in 1.0.10, 1.1.1 and 1.2.1. Google, which assigned the CVE, rates it CVSS 4.0 9.2 (Critical). Node.js rates it High in its own advisory and doesn't give a number. Same bug, different scales, so don't be surprised when articles quote different scores.

Node.js doesn't decode Brotli just because it's installed. Vercel's bulletin puts it plainly: you're exposed when your code, or a library you use, decompresses Brotli data an attacker controls. There are two common paths:

1. Incoming request bodies. Some body parsers decode a request body sent with Content-Encoding: br. Imperva reproduced code execution through Express 5.0.0 to 5.3.0 and body-parser 2.0.0 to 2.3.0 using raw() and json().
2. Responses your server fetches. Node's built-in fetch() decodes Brotli responses. If your app fetches from a server someone else controls, that server controls the input. Webhooks you call out to, scrapers, link previews and remote images all count.

Calling zlib.brotliDecompress() or createBrotliDecompress() yourself on untrusted data counts too.

On the Python side, the advisory explains why this matters even if you never import Brotli yourself. With one of these packages installed, common HTTP clients decode Brotli responses automatically, including requests through urllib3, httpx with the brotli extra, and aiohttp. The Bun advisory, Envoy advisory and Istio bulletin have the details for those runtimes.

Vercel deployed WAF rules on October 21 that block the inbound attack for every project, with no setup needed. It's also rolling patched Node.js versions across its managed runtimes. Here's what Vercel says to do:

• On Node.js 22.x or 24.x: no version change needed. Vercel manages the patch version.
• On Node.js 20.x: switch to 22.x or 24.x in project settings or engines.node, then redeploy. Node 20 won't get this fix.
• Don't treat the WAF as the fix. It only sees traffic coming in through Vercel. It doesn't cover responses your functions fetch from other servers, and only the runtime patch does.

As of Vercel's bulletin, the runtime rollout wasn't marked complete. On October 23, a developer on Vercel's community forum said a Node 24.x deployment still reported v24.21.0 after a fresh redeploy. So I'd confirm it instead of assuming. Log process.version from a function after you redeploy and compare it to the versions above.

If Node runs anywhere outside Vercel's managed runtime, upgrade it now. That covers a VPS, a container platform, a Node backend behind Vercel, CI runners and your laptop. Vercel also points out that Next.js image optimization doesn't block Brotli responses. If your next.config allows remote image hosts, those servers can send your app Brotli data.

The trap is the same one I flagged in the October patches post: Node usually lives inside an image you built weeks ago.

1. Run node -v inside the image you deploy, not on the host.
2. Bump the base image tag (for example node:24 to a build on 24.22.1 or later), rebuild without cache, and redeploy.
3. Pin the Node version in your platform's settings or engines.node, so a host default doesn't quietly pick an older one.
4. Check for a bun binary in the image too, and anything built with bun build --compile.
5. For Python services, run pip show brotli brotlicffi and upgrade whichever is installed.

One gotcha: the Node.js fix was a cherry-picked patch, not a Brotli version bump. Don't use process.versions.brotli to decide whether you're patched. Check the Node.js version.

Distro packages follow their own numbers. Debian's security tracker notes that Debian's nodejs package uses the system Brotli library. There, patching libbrotli (the brotli source package) is what matters. Check your vendor's advisory, not just upstream version numbers.

End-of-life runtimes stay vulnerable. Node 20 and older, and Istio lines past end of life, won't get fixes. This is the push to finally upgrade.

A WAF reduces exposure and nothing more. Outbound fetches never pass through it.

None of the official advisories I read reported attacks in the wild. That isn't a reason to wait, though, since a working proof of concept is already public.

I'd start with anything that accepts request bodies from the internet or fetches from servers I don't control, then work back through internal services and CI. If you run Node or Next.js apps and aren't sure which runtime they're actually on, that's the kind of audit I do for clients around Nashville and remotely. You can see how I work on my Nashville web developer page.

Not sure what your stack is running? Get a free quote and I'll tell you what needs patching first.

What is Node2Shell?

Node2Shell is Imperva's name for CVE-2026-111497, an out-of-bounds write in Google's Brotli decoder. Imperva showed that crafted Brotli data could run code in a Node.js app on an unpatched official image.

Which Node.js versions fix the Brotli vulnerability?

Node.js 22.23.4, 24.22.1 and 26.12.1, released October 21, 2026. Node.js 20.x and older are end of life and won't get a fix.

Is my Next.js site on Vercel safe?

Vercel's WAF blocks the inbound attack for every project, and Vercel is rolling patched runtimes for Node 22.x and 24.x. Projects on Node 20.x have to switch to 22.x or 24.x and redeploy. The WAF doesn't cover responses your functions fetch, so confirm your runtime version after redeploying.

Does this affect Bun and Python?

Yes. Bun 1.0.21 through 1.4.3 bundle an affected Brotli. Upgrade to Bun 1.4.4 and rebuild compiled executables. In Python, upgrade Brotli to 1.2.1 and brotlicffi to 1.2.1.0.

What CVSS score does CVE-2026-111497 have?

The CVE record from Google gives it CVSS 4.0 9.2, Critical. The Node.js project rates it High without a numeric score.

• Node.js, "Wednesday, October 21, 2026 Security Releases"
• Node.js 26.12.1 release notes
• CVE.org, CVE-2026-111497
• NVD, CVE-2026-111497
• google/brotli v1.2.1 release
• GitHub Advisory GHSA-9v8h-qqgm-4m35 (Python Brotli and brotlicffi)
• Bun security advisory GHSA-663w-cv8g-jj2p
• Envoy security advisory GHSA-3wvj-j6qm-62mr
• Istio, ISTIO-SECURITY-2026-007
• Vercel, "Node.js security advisory: Brotli decoder RCE (CVE-2026-111497)"
• Imperva, "Node2Shell: From Brotli Data to Remote Code Execution"
• Debian security tracker, CVE-2026-111497