CVE-2026-111497, known as Node2Shell, is a memory safety flaw in the Brotli decoder built into Node.js. In some applications, processing untrusted compressed data could lead to remote code execution. Exposure depends on whether the service passes that data to the vulnerable decoder.
This guide helps you inventory the Node.js instances actually running, identify the path taken by Brotli data, upgrade the runtime, and verify both the deployed image and the production process. You do not need to run a public exploit to confirm the fix.
1. Understand the issue
CVE-2026-111497 is an out-of-bounds write in the native Node.js Brotli decoder. The Node.js project rated it high severity and warned that it could allow remote code execution. Imperva demonstrated code execution on the official vulnerable 24.22.0 Linux arm64 image; the patched 24.22.1 release rejected the same input. This demonstration does not mean every Node.js application is exploitable in the same way.
Open image full size 2. Inventory the Node.js versions actually running
- List public APIs, server-rendered applications, background processes, job workers, containers, serverless functions, and standalone binaries that bundle Node.js.
- Running `node -v` on the host shows only the default binary for that shell. Check the version inside the container, in a running instance, and in the deployment artifact.
- Record the CPU architecture, base image or package source, and the version actually running in production. The Node.js version used in CI also matters for reproducible rebuilds.
- For distribution or enterprise packages, obtain vendor confirmation that CVE-2026-111497 is patched; the version number alone is not always decisive.
node -v
node -p "process.version + ' ' + process.arch + ' ' + process.platform"
docker exec sajat-kontener node -v3. Determine whether untrusted Brotli data reaches the decoder
Imperva examined two specific paths: a compressed response handled by the built-in Node.js `fetch()`, and an incoming request body processed by a suitably configured Express/body-parser path. A basic Node.js HTTP server does not automatically decompress an incoming Brotli body merely by receiving the request. Exposure must be assessed for each application.
| Data path | What should you check? |
|---|---|
| Response to an outbound request | Does the application process Brotli-compressed HTTP responses from external services? |
| Incoming request body | Does the configured middleware decompress request bodies marked `Content-Encoding: br`? |
| Other file or message | Does the code invoke Brotli decompression on untrusted input? |
4. Upgrade to a supported, patched Node.js release
- Create a verified backup and rollback plan to protect application data and configuration.
- Upgrade the Node.js base image or installed package to the appropriate patched release, and update pinned versions in Dockerfiles and CI.
- Rebuild dependencies and the entire container image. Make sure an old Node.js binary is not left in a layer or artifact behind the new configuration.
- Replace and restart all affected processes, pods, and serverless deployments. A process that remains running may still have the old decoder in memory.
| Node.js branch | First patched release |
|---|---|
| 22.x LTS | 22.23.4 |
| 24.x LTS | 24.22.1 |
| 26.x Current | 26.12.1 |
| Branches no longer supported | Move to a supported, patched branch or verified vendor support |
5. Verify the fix in production
- After deployment, check `process.version` and `process.arch` in the application’s actual running environment, along with the image digest or package release.
- Test important business flows, incoming compressed requests, and responses from external APIs using realistic, harmless test data.
- Check Node.js process restart times, pod and container counts, and error counts. Ensure no old replica remains in service.
- Document the services checked, versions, image digests, dates, and the change tied to the security advisory.
6. If you cannot upgrade immediately
- You may temporarily restrict the processing of untrusted Brotli data on affected paths if the service can continue to operate that way.
- Check whether your proxy, CDN, or WAF rules cover all relevant incoming paths. An inbound WAF rule does not protect responses received by outbound `fetch()` calls.
- Watch for unexpected process exits and decompression errors. Their absence does not prove that no attack occurred.
- Schedule the runtime replacement and assign an owner. Temporary filtering is not a permanent fix.
7. Investigate any suspected compromise separately
- Preserve access, application, and system logs, container events, and relevant timestamps.
- Isolate the affected service and investigate unexpected processes, file changes, outbound connections, and changes in access.
- Based on your investigation, rotate any tokens and secrets that may have been exposed. If needed, rebuild from a clean image and verified data.
- After installing a patched Node.js release, run functional and security checks. The upgrade will not remove malware that may already have been placed on the system.
