Node2Shell: What CVE-2026-111497 Means for Your Node.js App

The condition is specific: attacker-controlled Brotli data has to reach the decompressor. A bare Node.js HTTP server does not decompress request bodies on its own, according to Aikido's analysis. That does not mean you are in the clear, because a lot of common software does it for you.

Aikido reports that Express 5 and body-parser 2.x decompress request bodies sent with Content-Encoding: br. It also points out the other direction: fetch() automatically decompresses Brotli responses. An application that fetches a URL a user supplied, a webhook target, or a page an AI agent decided to visit may be handling attacker-controlled Brotli without a single line of compression code in the repository.

We could not establish whether a default Next.js app decompresses request bodies, and we found no statement on it. Vercel does warn that Next.js does not block Brotli responses in image optimization, and that self-hosted users should upgrade Node.js.

CISA's listing is based on evidence of active exploitation, and that should drive your priority. The public picture of reliability is more mixed. As of late October, Aikido reported that one public proof of concept worked only on a weakened test build, and that researchers had reported unreliable code execution against an unmodified Node.js image on Linux arm64.

Read that as early days, not reassurance. Memory corruption exploits generally improve with time and attention. The bug can also cause denial of service, and repeated crashes are an outage even without code execution.

Move to Node.js 22.23.4, 24.22.1, or 26.12.1, or later. Node.js published no workaround. Because the decoder ships inside the runtime, updating npm packages will not fix this, and neither will a new lockfile. It is the node binary that has to change.

Some distribution builds of Node.js link against a system Brotli library, so those systems also need the operating system package updated. The flaw reaches well past Node: Rapid7 notes affected implementations in Bun, Python's Brotli and brotlicffi packages, .NET, Envoy, Istio, brotli4j, and operating system packages.

Platforms are often the easiest place to be patched, but read the details. Vercel's bulletin says that as of October 28 at 11am PT, all new deployments use a patched Node.js, and that projects on 22.x or 24.x do not need to change their version setting. The word new matters. Vercel says it will update the page as remediation completes, and it does not confirm that existing deployments are patched, so a project that has not deployed since then is worth redeploying.

Other platforms vary. Aikido warns that managed platforms bundling their own Node.js runtime can lag, and Qualys counts serverless functions, including AWS Lambda's Node runtimes, as in scope. We did not find an AWS bulletin on this flaw in its security bulletin list, so check your provider's runtime version directly.

Node.js only patches supported lines, and it states that end-of-life versions are always affected when a security release occurs. Versions 20.x, 21.x, 23.x, and 25.x get no fix. Vercel's bulletin confirms that Node 20 will not receive this one, and says it disables Brotli response handling on outbound requests for unpatched versions, which is a runtime mitigation and not a patch.

Node 20 and older are extremely common in applications generated from slightly dated templates and training data. An AI assistant can happily scaffold a new project on a runtime that is already out of support. Migrating from Node 20 to 22 is usually modest work when done deliberately, but it can be stressful when forced by an active exploit, particularly with native modules involved or without a test suite.

Aikido suggests rejecting requests with Content-Encoding: br at your proxy, which covers inbound request bodies but does nothing for responses to fetch(). Qualys recommends limiting payload size and decompression ratio at the proxy or firewall. You can also restrict which hosts your server is allowed to fetch from, which is a good idea on its own merits. These measures narrow the attack without removing it, so treat them as a matter of days.

Node2Shell is a clean example of the gap between working and maintained. Nothing in your app has to be wrong. A dependency decompresses data, a base image gets stale, and a template pinned an old runtime a year ago. The product keeps earning money, and nobody gets an alert. Automated dependency tools do not necessarily help either, since many of them focus on packages and not on the runtime underneath.

If customers rely on your product, someone should own the answers to a few basic questions. What runtime version is in production? When did it last change? Which features fetch URLs influenced by outsiders? How quickly could you ship a runtime upgrade with confidence?

If those answers are hard to come by, that is the point where an experienced engineer pays off. We help teams with AI-built products move to supported runtimes, add the tests that make upgrades safe, and set up a routine that keeps them current, as a production hardening engagement or an ongoing retainer.