Node2Shell: What website owners need to check now

01What happened?

CVE-2026-111497 affects the Brotli decoder used by Node.js. A crafted data stream can write outside the intended memory area. Possible consequences include memory corruption, disclosure of memory contents, crashes and, under suitable conditions, code execution.

Node.js rates the vulnerability as “high”. Google, the CVE Numbering Authority (CNA) responsible for Brotli, gives it a CVSS 4.0 score of 9.2 and a rating of “Critical”. These are different assessments, but that does not make them contradictory. The score does not come from an independent NVD assessment verified here. It describes neither the likelihood of a breach nor observed attacks.

The Node.js fixes were released on 21 October 2026. On 22 October, Imperva reported achieving code execution in a laboratory test using the unchanged official Node.js 24.22.0 image on Linux arm64. The tests covered `fetch()` and certain Express/body-parser configurations with compressed requests. Version 24.22.1 rejected the same inputs. Whether the results apply to other environments remains unclear.

02How serious is the risk?

Imperva’s Proof of Concept (PoC) is a reported demonstration under laboratory conditions. It is neither evidence of an attack on a live website nor confirmation of a breach. When the research was completed on 23 October, the primary sources reviewed contained no confirmed active exploitation. The CVE was also absent from the CISA KEV catalogue checked as of 21 October. This does not rule out unknown attacks.

A basic server using `http.createServer()` does not automatically decompress incoming Brotli bodies. With Express/body-parser, the route, media type and enabled decompression settings must all match. The use of Express alone does not establish exposure. Other entry points include Brotli responses to external requests made with Node’s `fetch()` and direct decompression via `node:zlib`.

You should therefore also have URL imports, previews and image retrieval checked. What matters is whether data controlled by attackers can reach the vulnerable decoder. Compressing your own responses is a separate process.

03Which versions fix the vulnerability?

The following thresholds apply to standard Node.js builds and only to this CVE; they are not a general guarantee of security.

Distributions can backport fixes into packages with older version numbers. Ask for evidence of the full package revision, distribution and vendor advisory. You should also have someone check whether Node.js uses its bundled Brotli library or the system library. On Debian, the system Brotli library is decisive; the tracker information reviewed did not yet list a fixed package. Ubuntu listed Node.js and Brotli as “Needs evaluation”. This research confirms no fixed package number for either distribution.

• Node.js 22.x: at least 22.23.4.
• Node.js 24.x: at least 24.22.1.
• Node.js 26.x: at least 26.12.1.
• Node.js 20: support ended (EOL) on 30 April 2026; the research found no evidence of an official upstream fix release. Move to a supported, patched release line.
• Node.js 18 and earlier, as well as 21, 23 and 25: also EOL. Migrate or ask for evidence of a specific provider fix. Historical individual versions were not all fully assessed for this vulnerability.

04How do I establish whether I am affected?

If you use Shared or Managed Hosting without shell access, ask your hosting provider to check whether and where your project uses Node.js. “The server is up to date” does not prove the patch status of your application. In this context, Node.js is the runtime in which the application runs.

WordPress itself requires PHP. Additional Node backends, separate frontends and build tools still need to be checked. If the application only serves static HTML, CSS and JavaScript files, retrieving them does not involve a Node.js server path for that application. Their creation — the build process — may nevertheless use Node.js and external requests.

For Next.js, the deployment mode and runtime matter: have server-side rendering, API routes, Route Handlers and image optimisation checked. A static export still requires the build environment to be checked. For Edge functions, the provider must identify the actual implementation; Node.js version thresholds cannot be applied across the board.

• Developers should run `node --version` in the application context. In addition, `process.version` and `process.execPath` from the running application process or its startup log must confirm the version and executable path. Checking an arbitrary SSH shell is not enough.
• For containers, document the Image, Tag and Digest; update the base, rebuild, deploy it fully and verify the new running container. Updating the host does not change the image.
• In Plesk, check the runtime selected for the domain. The panel version and available runtimes do not prove what the application is currently running.
• Check automated build jobs, CI runners and their containers as well. Local developer installations do not establish their status.

05What should I write to my hosting provider or developer?

You can send the following enquiry with your domain or project name:

“Subject: CVE-2026-111497 for [domain/project]. Hello, please check whether our application uses Node.js and processes external Brotli data. The corrected official releases are 22.23.4, 24.22.1 and 26.12.1. Which version and executable path are actually running? Please provide evidence from the application process or startup log. For containers: Which Image with Tag and Digest has been deployed? For backports: Which package revision and vendor advisory demonstrate the fix, and is the system Brotli library being used? Have all web processes, workers and instances been restarted or replaced and then checked? Please also check Express/body-parser, `fetch()`, image optimisation, `node:zlib`, additional backends and build runners. If the update is still outstanding: Which temporary measure is in place, which paths remain exposed and when will the update follow? Please provide evidence confirming the deployed status. Thank you.”

A newly built image must also be deployed. After the update, restart or replace all affected processes and have the active status checked again.

06What can help until the update?

Temporary measures do not replace the patch. Developers can use `inflate: false` in all affected Express-/body-parser parsers to reject compressed requests. This applies to more than Brotli and can affect legitimate clients. Other parsers, external requests and direct decoder calls still need to be checked separately.

An upstream proxy or Web Application Firewall (WAF) can reject Brotli-encoded requests. All relevant access routes must be covered; direct access to the origin server must not bypass the filter. This does not protect external responses received by `fetch()`.

Affected import, preview or retrieval functions can be restricted or paused until the patch is applied. Changing the `Accept-Encoding` header is not a reliable barrier against a malicious response server. Disabling Brotli delivery at the CDN also does not demonstrate that the decoder is protected.

In its bulletin of 21 October, Vercel describes WAF rules and an ongoing runtime patch rollout; completion is not established here. For 22.x/24.x, Vercel manages the patch versions. Projects on 20.x should move to 22 or 24 and be redeployed. External backends must be checked separately.

07Frequently asked questions about Node2Shell