In brief
Node2Shell is Imperva’s name for the high-severity Node.js Brotli decoder flaw CVE-2026-111497. Not every Node.js application has the same attack path: the risk arises where untrusted Brotli data reaches the native decoder. Node.js releases 22.23.4, 24.22.1, and 26.12.1 fix the flaw. Replace running instances as well, then verify the actual production version.
Mi a Node2Shell?
Node2Shell is the name Imperva Threat Research uses for Node.js vulnerability CVE-2026-111497. The flaw is in the native Brotli decoder built into Node.js. On 21 October 2026, the Node.js project disclosed it as a high-severity security issue that could lead to an out-of-bounds memory write and remote code execution.
The name does not cover every Node.js flaw fixed that day. The security releases also addressed separate DNS, TLS, and other vulnerabilities, while the research called Node2Shell specifically concerns the Brotli decoder. Naming the exact CVE helps avoid confusion.
How does the vulnerability arise?
Brotli is a compression format. A Node.js application uses the decoder when it decompresses Brotli data. The vulnerable native code fails to reject certain malformed data streams properly, and processing may continue in an invalid internal state. That can lead to a write beyond the allocated memory boundary.
Imperva reports demonstrating code execution on the official vulnerable Node.js 24.22.0 Linux arm64 container image. Attacker-controlled data ran within the tested application process; the patched 24.22.1 release rejected the same input. The experiment required multiple attempts and did not cover every Node.js version, architecture, or application. It is concrete evidence of possible impact, not proof that every installation was compromised.
What happened in the incident?
On 21 October 2026, the Node.js project published security releases for the 22.x, 24.x, and 26.x branches. The advisory rates CVE-2026-111497 in the Brotli decoder as high severity and warns that it could allow remote code execution. The releases also fixed several separate DNS and TLS issues.
On 22 October, Imperva published its research under the name Node2Shell: it demonstrated code execution on the official Node.js 24.22.0 Linux arm64 image, while the patched 24.22.1 release rejected the same Brotli input. This was a laboratory demonstration; the sources do not establish that every affected service was attacked or that exploitability is identical on every platform.
Which applications may be exposed?
The key question is whether untrusted Brotli data reaches the built-in Node.js decoder. That can happen when a service processes a Brotli-compressed HTTP response from an external server, or when configured application middleware decompresses the body of an incoming request marked `Content-Encoding: br`.
Imperva examined both an external response handled by built-in `fetch()` and an incoming body processed through configured Express/body-parser middleware. In those cases, Express and body-parser are paths to the decoder, not the source of the native flaw. A bare Node.js HTTP server does not automatically decompress an incoming Brotli body merely because it receives the request. Assess actual exposure for each application.
What's the consequence?
If exploitation succeeds, an attacker could execute code with the privileges of the Node.js process. The effect depends on the application and container permissions: environment secrets, files, data connections, and service availability may be affected. An unexpected process exit or decompression error warrants investigation but does not by itself prove exploitation.
The official Node.js release advisory documents the vulnerability and fix; it does not report a broadly confirmed active attack campaign. A public demonstration and a confirmed attack in production are different claims. Security communications should preserve that distinction.
Which Node.js versions are patched?
The Node.js project published the following first patched releases on 21 October 2026. Branches 22.x and 24.x are LTS; 26.x is Current. For an older unsupported branch, move to a supported release or verify specific vendor support and a patch. For distribution backports, check the package identifier and the advisory for this CVE.
| Node.js branch | First patched release | Action |
|---|---|---|
| 22.x LTS | 22.23.4 | Upgrade to this or a later patched release |
| 24.x LTS | 24.22.1 | Upgrade to this or a later patched release |
| 26.x Current | 26.12.1 | Upgrade to this or a later patched release |
| Older branches | No new regular upstream security release | Move to a supported branch or a verified vendor patch |
Patching production: package updates are only the first step
Inventory every production Node.js process, container, serverless deployment, and standalone binary. `node -v` on a developer laptop does not establish the production version. Check the image digest and the binary running inside each container.
Upgrade the base image or installed Node.js package, build a new image, replace every running replica, and check the actual `process.version`. Test key application functions and normal Brotli traffic. `npm audit` is useful for package dependencies, but does not by itself prove that the native Node.js decoder is patched. The related knowledge-base article provides a detailed checklist.
- Record the running version, architecture, package source, and image digest for each service.
- Check external Brotli responses and the middleware configuration that decompresses incoming request bodies.
- After deployment, confirm that all old pods and processes have stopped and that the logs show no regressions.
- Preserve evidence for incident investigation if you suspect unusual activity or crashes.
What can you do if the upgrade is delayed?
Temporarily restricting the processing of affected untrusted Brotli data may reduce risk on some paths, but can affect operations. An inbound WAF rule does not protect a compressed response that the service downloads from an external server. Traffic visible to a proxy or CDN may not cover every data path.
The permanent fix is to replace the vulnerable Node.js runtime. Updating packages, reviewing code, or passing a functional test does not replace verifying that production processes are running the new binary.
Frequently asked questions
Are all Express sites affected? Both a vulnerable Node.js version and decoding of untrusted Brotli data matter. Examine the application configuration and the actual data path.
Is `node -v` on my laptop enough? No. The server, container, and running replica may each use a different version.
Does upgrading guarantee that no earlier attack took place? No. The upgrade closes the future exploitation path; suspected compromise requires a separate incident investigation.




