If you run a Node.js backend, check the Node version running in production. The October security release fixes a bug that can allow an attacker to run code by sending specially crafted compressed data to a vulnerable application.
That does not mean every Node.js app is exploitable. The risk depends on whether the app processes that data. Here is what to check, what to update, and how to confirm the update reached your server.
What happened?
Brotli is a compression format: it makes data smaller before it travels over the network. The receiving application decompresses it to read the original content.
Node.js has built-in support for this. The vulnerability is in the part that decompresses Brotli data. A malicious input can make it write outside the memory it should use. In certain circumstances, that can let an attacker execute code inside the Node.js process.
The issue is tracked as CVE-2026-111497 and rated High by the Node.js project. “Node2Shell” is the name Imperva uses for its research into the bug.
Could my app reach the vulnerable code?
Start with two places: data your server receives and data it fetches.
1. Your app accepts compressed request bodies.
Check the middleware that reads incoming requests. Imperva tested an application using configured Express/body-parser middleware that decompressed incoming Brotli data. Simply using Express does not establish that your app follows this path.
2. Your app fetches a compressed response from another server.
Think of a backend that downloads content from a URL. The response can be compressed, and the client may decompress it for your code. Imperva also demonstrated the issue through Node’s built-in fetch.
This second case is easy to overlook: your app makes the request, but another server supplies the response. A firewall filtering incoming requests to your site may not cover it.
A basic Node HTTP server does not automatically decompress every request body. Look at the libraries and code that handle the data. If you are unsure which paths your app uses, update the runtime while you investigate.
Which versions contain the fix?
The Node.js security release lists these fixed versions:
| Your Node.js version line | Fixed release |
|---|---|
| 22.x | 22.23.4 |
| 24.x | 24.22.1 |
| 26.x | 26.12.1 |
Use the listed release or a newer release in that line that includes the fix. These are the release lines covered by the advisory; an older version is not automatically safe because it is absent from the table.
If your Linux distribution supplies Node.js, check its security notice too. Distributions can apply a fix to their own package without adopting the same upstream version number.
Source: Node.js October security release.
How do I check and update my deployment?
Run this inside the environment that runs your app:
node --version
Running it on your laptop tells you about your laptop. For a container deployment, check inside a running application container. For a server, check the Node installation used by the application service.
Then follow the route that matches your setup:
- You manage the server: install a fixed Node release, restart the application with it, and confirm the serving process uses the updated installation.
- You deploy containers: update the Node base image, rebuild your application image, and deploy it. Existing containers keep their old runtime until replaced.
- Your hosting provider manages Node: check its advisory for your runtime version and any required redeployment. For Vercel, use its Node.js security bulletin.
After deployment, check the version again in the running environment and test your app’s normal requests, uploads and external API calls.
Updating npm packages alone does not update Node.js. The fix is in the runtime that executes your JavaScript.
What did the researchers actually demonstrate?
Imperva reports code execution in its tested applications on an official Node.js 24.22.0 Linux ARM64 image. Version 24.22.1 rejected the same inputs.
The demonstration needed multiple attempts and did not cover every build or application. It shows a working attack under those test conditions; it does not show that every vulnerable deployment has been compromised. See Imperva’s technical analysis for the details.
Before you close the update ticket
Make sure you can answer three questions:
- Which Node version is running in production now?
- Have all the old instances been replaced or restarted with the fixed runtime?
- Did the application pass its normal checks after deployment?
Keep the deployed image or release identifier with those answers. It gives the next developer a way to confirm what changed.
We covered a similar runtime-maintenance problem in our PHP2Shell explainer. The vulnerabilities are separate, but both require checking the software actually running on the server.
Sources checked on 23 October 2026. The exploit findings above are attributed to Imperva; TechWebster has not independently reproduced them.
Top comments (0)