Is Node2Shell as dangerous as PHP2Shell?

No, the situation is different. PHP2Shell hit every PHP website with a single request. Node2Shell requires the application to decompress Brotli data from an untrusted source. Node.js rates the flaw high, not critical, and no attacks were known as of 22 October 2026.

Is my Astro website affected by Node2Shell?

A static Astro website is not affected in operation: it serves finished files, and no Node.js runs on the server. Node.js is only used at build time. Server-side rendering with the Node adapter is different: Node.js then runs permanently and should be updated to a fixed version.

Which Node.js versions are safe?

Node.js 22.23.4, 24.22.1 and 26.12.1, released on 21 October 2026. Older versions of these lines are affected. Node.js 20 and other end-of-life versions get no fix.

How do I check whether my application is affected?

Check the version on servers, CI and in Docker images with node --version. Run npm ls express body-parser to see whether Express 5 or body-parser 2 is in use. Search the code for brotliDecompress and createBrotliDecompress, and note fetch() calls to servers you do not control.

Node2Shell: Who the Node.js Flaw Really Affects

Two days after PHP2Shell, the next name is doing the rounds: Node2Shell. The name suggests the same scale, but it is not. Below is what is behind it, who it hits and what to do. We name the sources in the text.

What Node2Shell is

Node2Shell is the nickname for CVE-2026-111497, a flaw in the Brotli decoder that ships with Node.js. Brotli is a compression method browsers and servers use to transfer data in smaller form. According to the Node.js security advisory, the decoder can write past the end of a memory buffer when fed manipulated compressed data. That is a classic route to crashes and, at worst, to running foreign code.

Node.js rates the flaw “high”, one level below critical. The bug actually sits in Google’s Brotli library. According to Aikido it was fixed there as early as February 2026, but only now picked up in Node.js.

The timeline:

21 October 2026: Node.js releases 22.23.4, 24.22.1 and 26.12.1. The release closes nine further flaws, including two high-rated bypasses of the hostname check for TLS certificates.
22 October: a public proof of concept shows code execution on the official Node.js 24.22.0 Docker image for Linux arm64. According to Aikido it does not work reliably.
As of the evening of 22 October: according to Brandefense, no confirmed attacks and no entry in the US agency CISA’s catalogue of exploited vulnerabilities.

Who is affected

This is the big difference from PHP2Shell. There, one request to any PHP site was enough. With Node2Shell, the application has to decompress Brotli data an attacker controls. According to Aikido, that happens in three cases:

Express 5 or body-parser 2.x: these automatically decompress requests with Content-Encoding: br. An attacker sends the manipulated content directly.
fetch() against third-party servers: Node.js decompresses Brotli responses automatically. If you fetch data from servers you do not control, you invite the attack in yourself.
Direct use of node:zlib: code that calls brotliDecompress or createBrotliDecompress with untrusted data.

Anything where no Node.js runs at runtime is not affected in operation. That covers many websites that only use Node.js to build.

What it means for typical website setups

Static Astro website. Node.js only runs during the build. The server holds finished HTML files served by an ordinary web server. There is nothing from outside that could send Brotli data to Node.js. Update the build machine anyway, if only because of the other nine flaws.

Astro with the Node adapter, Next.js, Nuxt or your own Express server. Here Node.js runs permanently and accepts requests. That belongs on the update list, whether or not you use Express 5.

Laravel or WordPress projects with Vite. Node.js only builds CSS and JavaScript there. In operation, PHP runs, not Node.js. For these projects, PHP2Shell is the more urgent job.

Headless setups. A build that fetches content from your own CMS via fetch() calls a server you control. That is a low risk. Builds that load data from third-party APIs or feeds are a different matter.

What to do now

Check the version. node --version on servers, CI runners and development machines. For containers: docker run --rm <image> node --version. Safe are 22.23.4, 24.22.1, 26.12.1 and newer.
Rebuild containers. Images pinned to a version such as node:24.22.0-alpine stay vulnerable until the base image is bumped and rebuilt.
Move off Node.js 20. Node.js 20 and older get no fix. Vercel says projects on Node.js 20 need to move to 22 or 24 and redeploy.
Check Linux packages. Node.js from distribution packages partly uses the system’s Brotli library. According to Brandefense, the picture at Debian was mixed on 23 October: a fixed brotli package existed for bookworm, but not yet for trixie.
Don’t forget Python. According to Open Source Malware, the same Brotli library is in the Python package Brotli, fixed from version 1.2.1, and in brotlicffi from 1.2.1.0. HTTP clients such as urllib3, httpx and aiohttp are affected when they decompress responses from third-party servers.

If you cannot update right away

According to Aikido, rejecting requests with Content-Encoding: br at the reverse proxy or load balancer helps as a stopgap. Vercel enabled a firewall rule for this across all projects on 21 October. Both only protect incoming requests. They do not cover responses your application loads from third-party servers via fetch(). For that, only the update helps.

What we do at Codeäffchen

Our website is a static Astro site. Node.js only runs in the build, and that only processes our own content. The site we serve contains no Node.js. For client projects running Node.js in operation, the list above applies: check the version, rebuild images, move off Node.js 20.

The lesson is the same as with PHP2Shell, just on a smaller scale: if you know where which runtime runs in which version, a day like this takes minutes.

You run a Node.js application or an Astro site with server-side rendering and are unsure whether it is affected? Find out more about our work with Astro on the Astro agency page, or send us a short message.