Introduction
Node.js is widely used to build web applications, REST APIs, microservices, and backend platforms. Its built-in networking capabilities and support for compressed HTTP content make it a popular choice for modern application development. However, a newly disclosed high-severity vulnerability, CVE-2026-111497, demonstrates how a flaw in a low-level compression component can expose an entire application to remote code execution (RCE).
The vulnerability, referred to as Node2Shell by Imperva Threat Research, affects the Brotli decompression functionality bundled with Node.js. Under certain conditions, an attacker can supply specially crafted compressed data that triggers memory corruption and may lead to arbitrary code execution within the vulnerable Node.js process.
The Node.js project released security updates on October 21, 2026. Organizations running affected versions should prioritize upgrading their Node.js runtimes and validating their deployments.
1. Important vulnerability details
| Field | Detail |
|---|---|
| CVE | CVE-2026-111497 |
| Name | Node2Shell — Brotli decoder memory corruption |
| Severity | High |
| Vulnerability type | Out-of-bounds write |
| Potential impact | Remote code execution |
| Affected component | Node.js bundled Brotli decoder |
| Affected release lines | Node.js 22.x, 24.x, 26.x |
| Fixed releases | 22.23.4 · 24.22.1 · 26.12.1 |
| Disclosure | October 21, 2026 |
Why is this vulnerability important?
The problem exists inside the Node.js runtime rather than exclusively in a third-party application package. Consequently, updating Express, body-parser, or other application dependencies alone does not fix the underlying flaw.
Successful exploitation may allow an attacker to execute arbitrary code within the vulnerable process, crash an application through memory corruption, potentially disclose sensitive information held in process memory, and affect application data and other resources accessible to the compromised process.
The actual impact depends on the application, its exposure to untrusted compressed data, the runtime build, and the privileges available to the process.
2. Technical overview: How Node2Shell works
1. Attacker supplies malformed Brotli data A crafted HTTP request body or compressed HTTP response 2. Node.js invokes Brotli decompression The bundled decoder processes the untrusted stream 3. Invalid decoder state causes memory corruption An out-of-bounds write can corrupt memory 4. Potential security compromise Application crash, memory disclosure, or remote code execution
Understanding the root cause
Brotli is a compression algorithm used to reduce the size of transmitted data. Node.js includes a Brotli decoder and exposes decompression functionality through its `node:zlib` module.
The vulnerability involves an invalid block-switch condition in the decoder:
The decoder encounters a block transition that is invalid for the supplied compressed stream. Instead of correctly propagating a permanent format error, the vulnerable code can treat the condition as a temporary need for additional input. The streaming decoder continues processing an invalid internal state, resulting in an out-of-bounds write. The resulting memory corruption may crash the process, expose memory, or enable code execution.
The underlying issue is in the bundled Brotli implementation, not simply in the JavaScript code handling an HTTP request. The security fix ensures the invalid stream condition is reported as a format error rather than allowing decoding to continue incorrectly.
Where can an application be exposed?
Two important paths deserve investigation:
Incoming HTTP requests: An application using Brotli-capable request parsing middleware, such as certain Express 5 and body-parser 2 configurations, may pass attacker-controlled request bodies to the vulnerable decoder.
Outgoing HTTP requests: An application using Node.js's built-in `fetch()` may automatically decompress a Brotli-encoded response received from an external server.
A plain HTTP server does not necessarily decompress incoming Brotli request bodies automatically. Exposure depends on how the application processes the data. Similarly, calling an external service does not automatically imply exploitability; the response must reach the affected decoding path and contain suitable malicious input.
3. Affected versions and patch fixes
The official Node.js security advisory identifies the following affected release lines and fixed versions.
| Node.js release line | Affected versions | Fixed version |
|---|---|---|
| 22.x | Earlier than 22.23.4 | 22.23.4 |
| 24.x | Earlier than 24.22.1 | 24.22.1 |
| 26.x | Earlier than 26.12.1 | 26.12.1 |
What does the patch change?
The fix incorporates a change from the upstream Brotli project that detects an invalid block switch earlier and propagates the appropriate decoder error. Node.js also exposes the corresponding decoder error constant so the failure can be handled correctly.
The intended outcome is straightforward: malformed compressed data is rejected instead of being processed in a way that corrupts memory.
Step-by-step remediation
1. Identify the installed runtime. Run the following commands on the relevant host or inside the application container. On Windows, use `where node` to locate the executable. Check the runtime actually used by the running service, not just the version installed in your interactive shell.
node --version which node npm --version
2. Upgrade Node.js to a fixed release. Select the appropriate supported release line and install its latest security-patched version. For example, with nvm:
nvm install 24.22.1 nvm use 24.22.1 node --version
This is an example of the minimum fixed version for Node.js 24.x. Use the current patched release where a newer one is available.
3. Rebuild and redeploy containerized applications. Update the Node.js base image in your Dockerfile to a fixed image tag, rebuild the image, and redeploy it. Recreating a container from an old image does not remediate the vulnerability.
FROM node:24.22.1
Use an approved, maintained image and verify the actual Node.js version inside the resulting container.
4. Restart and verify the application. Restart all affected services so they run the patched runtime. Verify the version in each environment, including production replicas, background workers, scheduled jobs, and serverless deployments.
5. Run regression and security tests. Test normal Brotli-compressed requests and responses, application startup, API behavior, and error handling. Confirm malformed compressed streams are rejected safely and that the application continues to operate normally.
4. Important security notes for system administrators
Patching the runtime is the primary remediation, but administrators should also verify how the application is deployed and which data sources it trusts.
Audit all Node.js installations. Check production servers, development environments, CI/CD runners, container images, serverless runtimes, and applications that bundle their own Node.js executable.
Review Brotli decompression paths. Identify request parsers, compression-handling libraries, and outbound HTTP clients that process compressed content from untrusted sources.
Use temporary compensating controls. Where feasible, restrict untrusted Brotli request bodies on affected endpoints until patching is complete. A web application firewall (WAF) may provide additional protection, but inbound filtering alone does not address malicious compressed responses received by outbound clients.
Review logs and investigate suspicious behavior. Examine unexpected process crashes, decompression errors, unusual outbound connections, and suspicious application activity. These observations are investigation leads, not proof of exploitation.
Apply defense in depth. Run services with least privilege, restrict filesystem and network access, keep secrets out of unnecessarily exposed processes, and maintain monitoring and tested recovery procedures.
5. Remediation checklist
| Step | Action | Purpose |
|---|---|---|
| 1 | Inventory Node.js versions | Record runtime versions across hosts, containers and serverless environments. |
| 2 | Identify vulnerable deployments | Prioritize affected versions that process untrusted Brotli data. |
| 3 | Upgrade the runtime | Install a fixed or newer supported Node.js security release. |
| 4 | Rebuild and redeploy | Update images and bundled runtimes, then restart affected services. |
| 5 | Verify the patch | Confirm the runtime version in the actual running process. |
| 6 | Test application behavior | Validate normal compression, malformed-input handling and service stability. |
| 7 | Review security telemetry | Investigate suspicious crashes, network activity and process behavior. |
6. Frequently asked questions
Is Node2Shell a vulnerability in Express or Node.js? The underlying vulnerability is in Node.js's bundled Brotli decoder. Express and body-parser can expose a route to that decoder when configured to decompress incoming Brotli request bodies. The built-in `fetch()` API can also encounter the vulnerable decoder when consuming compressed responses.
Will updating npm packages fix the issue? No. Updating application dependencies alone does not replace the vulnerable runtime. You must upgrade Node.js itself and rebuild any deployment artifacts containing an affected Node.js binary.
Can a WAF completely protect against Node2Shell? No. A WAF can reduce risk on traffic it inspects, but it may not protect against malicious compressed responses received through outbound requests. A WAF should be treated as a temporary or supplementary defense, not a substitute for patching.
Does running an affected Node.js version automatically mean the application is exploitable? Not necessarily. Exploitation depends on whether attacker-controlled Brotli data reaches the vulnerable decompression functionality and on the target environment. Nevertheless, all affected deployments should be updated because exposure can be difficult to assess completely.
7. Conclusion
Node2Shell (CVE-2026-111497) highlights an important cybersecurity lesson: vulnerabilities in underlying runtimes and native libraries can undermine the security of otherwise well-designed applications.
The flaw in Node.js's Brotli decoder can cause an out-of-bounds write when processing malformed compressed data, potentially leading to memory disclosure, denial of service, or remote code execution. The availability of common decompression paths, including configured HTTP request parsers and outbound response handling, makes runtime inventory and exposure assessment essential.
The most important actions are to patch immediately to Node.js 22.23.4, 24.22.1, 26.12.1, or a newer security-fixed release in the appropriate supported line; audit all deployment environments, including container images, CI/CD systems, serverless services, and bundled runtimes; use temporary mitigations and monitoring while upgrades are being completed; and verify remediation by confirming the running runtime version and testing application behavior.
Ultimately, dependency management, runtime patching, least-privilege execution, and continuous security monitoring must work together. Node2Shell is a reminder that timely security updates are not merely a maintenance task; they are a fundamental part of protecting production systems and the data they process.
References and further reading
- Node.js official security release — October 21, 2026
- Imperva: Node2Shell — From Brotli Data to Remote Code Execution
- Tenable: CVE-2026-111497
- Cyber Security Agency of Singapore: Node.js vulnerability alert
- Node.js official releases on GitHub
