Node.js and Brotli vulnerability (Node2Shell): how to check your website
The Node2Shell vulnerability (CVE-2026-111497) in Node.js and Brotli: who is affected, how to check your website without a developer, patched versions and what to ask your host.
As of 1 November 2026. On 21 October the Node.js project released security patches, including a fix for the vulnerability CVE-2026-111497, nicknamed Node2Shell. The flaw is in Brotli, a library for decompressing compressed data that Node.js has built in. On 27 October the US agency CISA added this vulnerability to its catalog of vulnerabilities exploited in attacks.
Don’t panic: most small-business websites run on WordPress or as plain HTML files and have no Node.js on the server. But if your website, store or customer panel runs on Next.js, Nuxt or Express, check it today. In this guide I show how to find out in a few minutes whether the vulnerability affects you, which versions have the fix and what to write to your host or website contractor.
What happened
Brotli is a method of compressing data, a bit like packing files into a ZIP, developed by Google and used all over the internet. The Brotli library in versions 1.0.3 through 1.2.0 has a flaw: specially crafted compressed data can, when decompressed, write outside the place in memory that the program set aside for it. The result can be an application crash, a leak of data from the server’s memory and, in the worst case, running someone else’s code with the permissions of your application.
The key dates:
- 21 October 2026: Node.js and Google released fixes (Brotli 1.0.10, 1.1.1 and 1.2.1).
- 23–26 October 2026: Debian (DSA-6582-1) and Ubuntu (USN-8956-1) released patched packages of the library, and on 25 October Microsoft released out-of-band fixes for .NET.
- 27 October 2026: CISA added the vulnerability to the Known Exploited Vulnerabilities catalog, meaning vulnerabilities exploited in practice.
Sources differ on when the attacks began. According to reports from 22 October, no attacks were known yet. Companies that monitor network traffic describe scanning and the first attempts between 25 and 27 October, and CISA did not give details. Some of the observed attempts failed, but even a failed attempt can take an application down. So treat this update as urgent.
Who the Node.js vulnerability affects
The vulnerability affects programs that decompress Brotli data received from a third party. In practice this means:
- websites, stores and applications running on a server with Node.js: Next.js, Nuxt, Express and others. Node.js has Brotli built in, so what counts is the version of Node.js itself, not npm packages;
- applications that accept compressed requests: for example, Express 5 (via body-parser 2.x) decompresses Brotli-compressed request bodies by default;
- applications that fetch data from other servers: the built-in
fetch(), integrations, downloading images from other addresses. Vercel points here, for example, to image optimization in self-hosted Next.js; - other programs with the Brotli library: .NET 8, 9 and 10 (Microsoft notes that Brotli decompression is not enabled there by default), Bun, Envoy and the system libbrotli packages in Linux.
Who the vulnerability does not directly affect:
- static websites, meaning ready-made HTML files, for example from the builder or from Next.js exported to files. Node.js then runs only on the computer where the website is built, not on the server;
- WordPress and other PHP websites, because they don’t run on Node.js. The server may still have a system Brotli library, so a system update is needed anyway. That is the host’s job.
One clarification, because it is a common question: the Brotli compression with which the server packs pages sent to browsers is not this vulnerability. The flaw concerns decompressing data from strangers. Don’t turn compression off, because the website will slow down and it won’t solve the problem.
Which Node.js versions have the fix
As of 1 November 2026, according to the Node.js announcement of 21 October and the Node.js release list:
| Node.js line | Support | What to do |
|---|---|---|
| 26.x | yes (LTS) | update to 26.12.1 or newer |
| 24.x | yes (LTS) | update to 24.22.1 or newer |
| 22.x | yes (LTS) | update to 22.23.4 or newer |
| 25.x, 23.x, 20.x and older | no | there will be no fix: move to 22.x, 24.x or 26.x |
Unsupported lines are vulnerable and will not get a fix. Node.js says outright that versions past end of support are always affected by vulnerabilities from subsequent security releases. After 21 October further releases have already come out: 24.22.2 (27 October) and 26.13.0 (28 October, from which version the 26.x line has LTS status). They contain the same fix, and before updating you should check the latest version on nodejs.org anyway.
The same release also fixes nine other flaws, among them one in TLS certificate checking. One update takes care of all of them.
How to check whether your website is exposed
Without a developer: 5 minutes
- Page source. Open your website in a browser, press Ctrl+U (view source), then Ctrl+F and type
_next. If there are results, the website is built with Next.js. For Nuxt, look for_nuxt. That doesn’t yet settle whether Node.js runs on the server, but it says it’s worth asking further. - Headers. Press F12, go to the Network tab, refresh the page and click the first row. In the response headers look for
x-powered-by. A value ofNext.jsorExpressmeans Node.js on the server. The absence of this header proves nothing, because many contractors hide it. - Hosting panel. If the website is on Vercel, you can see the Node.js version in the project settings. In hosting panels that support Node.js applications, the version is usually shown next to the application.
- Ask your contractor. That is the fastest and most reliable. You will find a ready message below.
For the person who deploys
Check the version everywhere the code runs: on the server, in every container, in the test environment and in CI.
# Node.js version
node -v
# Node.js version in a Docker image
docker run --rm <image> node -v
# Debian and Ubuntu: version of the system Brotli library
dpkg -l | grep -i brotli
Three traps:
- Docker images built before 21 October have the old version until you rebuild them from the new base image.
- Node.js from system packages may use the system libbrotli library. Compare its version with the Debian tracker or the Ubuntu notice USN-8956-1.
- A running process uses the old version until you restart it.
What to do today
- Find out whether you have Node.js on the server (previous section). If not, go to point 6.
- Make a backup of the code, database and configuration. I describe how to do it properly in the guide on website backups and the 3-2-1 rule.
- Update Node.js to the version from the table, within the same line. Such an update usually requires no code changes.
- Restart the application or deploy it afresh, and rebuild Docker images. On Vercel, for projects on 22.x and 24.x a redeploy is enough.
- On Node.js 20.x or another unsupported line, don’t wait for a fix, because there won’t be one. Move to 22.x, 24.x or 26.x: first on a test copy, then on the live website, within the next few days.
- Ask your host about updating the system Brotli packages, also if you have WordPress.
If the update has to wait a few days, security firms (among them Aikido and ELLIO) advise temporarily rejecting incoming Brotli-compressed requests (the Content-Encoding: br header) on a proxy server, a firewall or in the application itself. This is a safeguard for a short time only: it does not protect against data fetched from other servers and does not replace updating. On 21 October Vercel enabled firewall rules against this vulnerability for all projects, but it notes itself that they do not replace updating Node.js.
After the update, ask for the logs since 21 October to be reviewed: whether the application restarted unusually often and whether unknown files, processes or accounts have appeared. If anything raises doubts, report the incident to CERT Polska (Poland’s national computer security incident response team).
What to ask your host or website contractor
Who updates Node.js depends on where the website runs:
| Where the website runs | Who updates Node.js | Your role |
|---|---|---|
| Vercel and similar platforms | the provider, on its own schedule | check the provider’s notice, make sure the project is on 22.x or newer and redeployed |
| Hosting with a panel and a Node.js application | usually the contractor, who picks the version in the panel | ask the contractor |
| VPS or your own server | the administrator or the contractor | make sure someone has this in their duties |
A ready message to copy:
Hello, On 21 October Node.js released security fixes, including a fix for the vulnerability CVE-2026-111497 (Node2Shell, Brotli). Please let me know:
- Does our website or application run on a server with Node.js, and if so, in which version?
- Has Node.js been updated to version 22.23.4, 24.22.1, 26.12.1 or newer, and has the application been restarted?
- Have the system Brotli packages been updated on the server?
- Is there anything worrying in the logs since 21 October? Thank you, and please reply within 2 business days.
If the contractor doesn’t reply, or the website has nobody looking after updates, that is a sign that it needs to be sorted out. I can take over the care of the website, and if you prefer it to run on a server that I manage myself, I can also provide domain and hosting (from PLN 390 net a year, server in Poland or the EU).
Unsupported versions: a lesson for the future
Node.js 20.x didn’t get a fix because its support has already ended. It is the same mechanism as with PHP: I recently wrote about the end of support for PHP 8.2, which falls on 31 December 2026. An unsupported version works normally right up to the day a vulnerability appears. Then, instead of a simple update, you face a move to a newer version under time pressure.
That is why, once a quarter, check three things:
- which version of Node.js or PHP your website runs on and until when that version is supported,
- who has the duty to update in the contract and how quickly they respond to urgent vulnerabilities,
- whether the backup can really be restored.
In the coming days, in the “Vulnerabilities” series, I will describe, among other things, the October fixes in Next.js and React, and who is responsible for updates: the host, the contractor or the business owner.
Summary
Node2Shell is a serious vulnerability, but for most businesses the fix is simple: update Node.js to version 22.23.4, 24.22.1, 26.12.1 or newer and restart the application. Websites on Node.js 20.x and other unsupported lines have the most work, because they have to move to a newer line. If you don’t know what your website runs on, send your contractor the message from this guide today.
If nobody looks after updates on your website, write to me. As part of technical maintenance I monitor your website, make backups and install security updates. There are three plans to choose from: Watch from PLN 149 net a month (urgent updates within 2 days), Standard from PLN 349 net a month (response within 1 business day) and Pro from PLN 749 net a month (response within 4 hours). A security audit (from PLN 990 net) will show what else needs fixing. I reply within 24 hours, and new clients get a 20% discount on their first order.
Frequently asked questions
The Node.js patch doesn’t concern your website, because WordPress runs on PHP. The server may still have a system Brotli library, which Debian and Ubuntu patched in late October. Ask your host whether they have installed those updates.
No. The vulnerability concerns decompressing data received from strangers, not compressing the pages the server sends to browsers. Turning off compression will slow your website down and is no substitute for updating.
On 21 October Vercel enabled firewall rules against this vulnerability, and since 28 October all new deployments on Vercel use the patched version of Node.js. Projects on Node.js 20.x must be switched to 22.x or 24.x and redeployed, while for 22.x and 24.x a redeploy is enough. Your own servers and containers outside Vercel have to be updated separately.
Without access to the server logs you can’t tell. Ask your contractor to check whether, since 21 October, the application has restarted unusually often and whether there are unknown files, processes or accounts on the server. If anything raises doubts, report an incident to CERT Polska (Poland’s national computer security incident response team).
On platforms that update Node.js on their own, a redeploy is often enough. On your own server, an update within the same line is usually a short job, while moving off an unsupported line, for example 20.x, requires testing on a copy of the website. Ongoing updates and backups are covered by my technical maintenance in three plans: Watch from PLN 149 a month, Standard from PLN 349 a month and Pro from PLN 749 a month, all net.
Related services
Have a similar project?
Describe what you need and I’ll send a quote within 24 hours. New clients get 20% off their first project.


