+61 2 9043 1246

Knowledge base

CVE-2026-111497: the Node.js Brotli decoder flaw, explained for website owners

Published · By , Co-Founder, BLACKBX

CVE-2026-111497, known as Node2Shell, is a flaw in the Brotli decoder that Node.js and other software bundle. It affects Node.js 22, 24 and 26 before the 21 October 2026 releases, and every end-of-life version. CISA lists it as exploited. Update Node.js to 22.23.4, 24.22.1 or 26.12.1 everywhere it runs.

Key fact CVE-2026-111497
What An out-of-bounds memory write in Google’s Brotli decoder (CWE-787, with CWE-252 Unchecked Return Value), bundled inside Node.js and other software.
Affected Node.js 26.x before 26.12.1, 24.x before 24.22.1, 22.x before 22.23.4, and all end-of-life lines (20 and older); Brotli 1.0.3 to 1.2.0; also Bun, Envoy, Istio, .NET and others. Not affected: Node.js builds that use a patched system brotli library, and services that never decompress Brotli data from outside.
Fixed in Node.js 26.12.1, 24.22.1 and 22.23.4, released 21 October 2026; Brotli 1.2.1, 1.1.1 and 1.0.10. The latest Node.js seen was 26.12.1; whether anything newer has come out since about 23 October is not known.
Severity 9.2 critical on CVSS v4.0 from Google, which issued the CVE; 8.1 on CVSS v3.1 from Red Hat and Microsoft; Node.js rates it “high”; NVD has not scored it.
Needs a login? No. An attacker needs no account and no one has to click anything.
Exploited? Yes. CISA added it to its Known Exploited Vulnerabilities catalogue on 27 October 2026; ELLIO recorded the first attempt on 26 October 2026, and sources disagree on whether that attempt worked.
Do now Check every place Node.js runs, including containers, and update to 22.23.4, 24.22.1, 26.12.1 or later.

Facts checked on 29 October 2026 against the Node.js advisory and release notes, a mirror of the CVE record, CISA’s alert, Red Hat, F5, Amazon Linux, Akamai, ELLIO, Imperva and SecurityWeek. Sources are listed at the end.

What is CVE-2026-111497?

CVE-2026-111497 is a flaw in Brotli, a compression format that web servers use alongside gzip. Compression makes data smaller for the trip across the internet. Something has to unpack it at the other end, and that job is done by a piece of code called a decoder.

Google maintains the Brotli decoder. Plenty of other software carries its own copy of that decoder inside it, which is called bundling. Node.js is one of them. Node.js is software that lets a server run programs written in JavaScript, and some websites and web applications are built on it. Its Brotli decoder lives in its built-in zlib module.

The flaw sits in the decoder itself, in the file c/dec/decode.c. It has been given two classes. CWE-787, an out-of-bounds write, means the code can write data outside the patch of memory set aside for it. CWE-252, an unchecked return value, means the code does not properly check whether an earlier step succeeded before carrying on.

In plain terms, a specially made piece of compressed data can make the decoder scribble over parts of the program’s memory it should never touch. Node.js says that can crash the program, leak what is in its memory, or let an attacker run their own code on the server.

The official title of the CVE record is “Out-of-Bounds Write in Google Brotli Decoder”. Node.js calls it “Node.js Brotli decoder out-of-bounds write permits remote code execution”. The industry has given it several nicknames: Node2Shell, Broccoli2Shell, HTTP2Shell and Brotli2Shell. They all mean the same bug.

Node.js credits the report to “OpenAI Codex Security - Khai Tran and Sylvie Mayer”. The fix is credited to Matteo Collina and Antoine du Hamel; some early write-ups wrongly said Collina found the bug. Google issued the CVE, as the organisation responsible for numbering Brotli flaws. When the bug was first reported is not known. The CVE ID was reserved on 16 October 2026, and the fixes were released on 21 October 2026.

Who is affected?

For a Node.js site or application to be at risk, these things must be true:

  1. It runs on Node.js 22.x before 22.23.4, 24.x before 24.22.1 or 26.x before 26.12.1, or on an end-of-life version. End-of-life means the project no longer fixes it: Node.js 20, 18, 16, 14 and 12 get no fix for this flaw.
  2. That Node.js uses its own bundled copy of Brotli, rather than a patched copy supplied by the operating system.
  3. The application, or a library it uses, unpacks Brotli data that an outsider can control. Paths shown to be exposed include Node’s built-in fetch() reading a Brotli-compressed response, and Express 5 or body-parser 2 unpacking a Brotli-compressed request. Express and body-parser are common add-ons that Node.js websites use to handle incoming requests.

What is not affected, or depends on the setup:

  • A bare Node.js web server does not unpack incoming Brotli data on its own.
  • Express 4 uses body-parser 1.x, which handles only gzip and deflate, not Brotli.
  • Some Linux distributions build Node.js to use the system’s Brotli library. Red Hat marks those Node.js packages “Not affected”, but the system brotli package still has to be updated. On Debian, the fix likewise comes from the distribution’s brotli package, not from the Node.js version number.
  • F5 says its NGINX Plus Brotli module is not directly affected, and Amazon Linux lists Firefox as not affected.
  • Node.js 23.x and 25.x are not named in the Node.js advisory. Whether they are specifically affected is not known.

This is not only a Node.js problem. Google’s Brotli library is affected from version 1.0.3 to 1.2.0. Other products named as affected include .NET (8 before 8.0.33, 9 before 9.0.22 and 10 before 10.0.14), PowerShell, the Python brotli and brotlicffi packages, Bun (1.0.21 to before 1.4.4), Envoy and Istio. Red Hat adds Thunderbird, web servers that use “br” compression, and any service that links to the brotli library and processes data from outside.

How many sites does this touch? Akamai says 61% of the networks it sees run affected Node.js versions. That is not a count of exposed websites, since exposure depends on point three above, but it shows how common the affected versions are.

If your site uses Node.js anywhere, including inside a container, and nobody has updated it since 21 October 2026, assume you are in scope until someone checks the version.

What can an attacker do?

At worst, run their own code on your server. That means taking over the application and whatever it can reach. At best, from the attacker’s point of view, it crashes the program or leaks what is in its memory, which can include data the application is handling.

Three things make it worse:

  • No login. The attacker does not need an account. The CVE description says a “remote unauthenticated attacker” can exploit it.
  • No interaction. Nobody on your side has to open an email, click a link or do anything at all.
  • Public reach. The attack arrives over the network, and working proof-of-concept code, a demonstration of the attack, is already public on GitHub.

There is one precondition, and it matters. The target has to unpack Brotli data that the attacker controls. That is why some Node.js services are exposed and others are not, and why someone needs to look at how your application is built, not only at its version number.

The scores differ, and the reason is that precondition. Google, which issued the CVE, scored it 9.2 out of 10, critical, on version 4.0 of the CVSS scoring system. Red Hat scored it 8.1, “Important”, on the older version 3.1. Red Hat rates the attack as harder to pull off because of that same precondition, and Microsoft and Amazon Linux also show 8.1. Node.js rates it “high” without a number. NVD, the US government’s vulnerability database, has not published a score of its own; its status is “Undergoing Analysis”. If you have seen 9.8 quoted for this flaw, we could not find that figure in any published source.

Whichever number you read, the advice from every source is the same: update.

Is it being exploited?

Yes. On 27 October 2026, CISA, the US government’s cybersecurity agency, added CVE-2026-111497 to its Known Exploited Vulnerabilities (KEV) catalogue. KEV is the list of flaws CISA has evidence of being used in real attacks. US federal agencies must fix it by 10 November 2026. Known ransomware use is listed as “Unknown”, and CISA gave no details about the attacks.

CISA’s own assessment moved quickly. On 23 October it listed exploitation as “none”. By 27 October it said “active”, with “total” technical impact.

The evidence so far comes from honeypots, servers set up to attract and record attacks:

  • ELLIO, a threat intelligence firm, saw a scanning tool called “node2shell-check” send 20 Brotli-compressed requests in two bursts, looking for servers that unpack Brotli. Attack traffic followed the next day from a different source. The first attempt was recorded on 26 October 2026 at 15:08 UTC.
  • Sources disagree on whether that attempt worked. ELLIO’s own update says the traffic carried a public exploit it had confirmed gets a shell, meaning control of the server, on vulnerable builds. The Hacker News says it did not work in ELLIO’s tests. SecurityWeek says ELLIO found the exploit was broken, and quotes ELLIO calling it “indicative of the RCE being adopted by an operator focused on mass exploitation”.
  • Previdian recorded one attempt on 27 October from a US-based IP address. It says “confirmed” describes its confidence that this was an attack, not that the attack succeeded.

The working demonstrations have also improved fast. The first public one only ran code on a deliberately weakened build. Imperva then showed code execution on the official Node.js 24.22.0 Linux arm64 image, after several attempts. ELLIO reproduced it on x86-64 against four targets, and Sysdig says OtterSec has reported dozens of reproductions. Red Hat’s undated statement says there is no public, reliable proof-of-concept, which conflicts with these later reports.

EPSS, a model that estimates how likely a flaw is to be exploited, puts this one at 55.5%. Who is behind the attacks, and how many sites have been hit, is not known.

For an Australian site, the CISA deadline does not apply. It is still a useful guide. The scanning ELLIO describes was a search for any server that unpacks Brotli, and an exposed Australian site has no good reason to wait longer than a US agency is allowed to.

What should you do now?

In this order:

  1. Find out the version, everywhere Node.js runs. Whoever manages the server can run node -v. Node.js is often installed in more than one place: the operating system’s own package, extra versions installed with a tool called nvm, and inside each container image (docker exec node -v). Each one counts. On Red Hat or Debian servers, also check the version of the system brotli package. Ask about other software on the server that bundles Brotli, such as .NET, Bun, Envoy, Istio or the Python brotli package.
  2. Update. Move Node.js to 22.23.4, 24.22.1, 26.12.1 or later. If you are on Node.js 20 or older, there is no fix for your version: move to 22.x or 24.x and redeploy. Rebuild container images so the new version is actually in use. On Red Hat or Debian, update the system brotli package too. The Node.js advisory lists no workaround, and removing “br” from the Accept-Encoding header does not help by itself.
  3. Check for signs of compromise. Neither Node.js nor Google has published indicators. ELLIO says the attempt it saw was a single Brotli-compressed request of just over 23 MB. Unusually large compressed requests in your server logs since late October are worth a closer look.
  4. If you think the server was compromised, do not just update and carry on. No vendor or researcher has published clean-up guidance for this flaw. Have whoever manages the server investigate it properly before you trust it again.
  5. Record what you did. Write down each place Node.js was found, the version before and after, and the date of each update. If something turns up later, that record is what anyone investigating will ask for first.
  6. Reduce exposure if you cannot update straight away. Imperva suggested limiting untrusted Brotli traffic on affected paths where practical. F5 published a custom firewall rule that blocks requests marked as Brotli-compressed. Both are stopgaps, not a substitute for the update.

If step one is already beyond what you can find out about your own website, that is the problem this blog exists to talk about. Skip to the bottom.

Why updating is not the whole fix

The fix for this flaw was committed to Google’s public Brotli code on 27 February 2026. There was no release and no advisory until 21 October 2026. For nearly eight months the change sat in public view, and anyone reading it closely could have worked out what it repaired.

Once the advisory was out, the gap closed fast. The fixed releases came out on 21 October. A working demonstration followed within a day or two. The first attack attempt ELLIO recorded came on 26 October, five days after the fix. CISA listed it as exploited the day after that.

The update stops new attacks. It does nothing about what may have happened before it was applied, and it only reaches the copy of Node.js you actually updated. A container image that has not been rebuilt still runs the old version. A server that uses the system brotli library needs that package updated as well. Other software on the same server may carry its own copy of the decoder. And any site still on Node.js 20 or older will never receive a fix: the only answer there is a move to a supported version.

That is the pattern with most serious vulnerabilities in the software underneath a website. The fix arrives quietly, the attacks arrive within days, and the gap between the two is filled by whoever is actually watching the site. For a lot of small businesses, that is no one in particular. The host looks after the server. The agency that built the site has moved on to other projects. The software updates in between, Node.js, its libraries and the containers it runs in, belong to no one.

What this looks like with BLACKBX

BLACKBX scans every site it looks after daily against published security advisories. When a client’s site matches a critical advisory like this one, our developers patch it immediately. Lower-severity items are done at the next service. Every update is dated and recorded in the client’s logbook, so there is always an answer to “what version were we on, and when did it change?”

On the Monitor plan, the finding goes to the client’s own developer with the version numbers and our advice, so they can act on it straight away. On Maintenance and Full service, BLACKBX does the work. All plans are monthly, with no minimum term.

Timeline

Date Event
27 February 2026 Fix committed to Google’s Brotli code, with no release or advisory
14 October 2026 Node.js pre-alert announces upcoming security releases
16 October 2026 CVE-2026-111497 reserved
21 October 2026 Node.js advisory published; fixed releases 26.12.1, 24.22.1 and 22.23.4
21 October 2026 Brotli 1.2.1, 1.1.1 and 1.0.10 released
22 October 2026 CVE published on NVD; no in-the-wild exploitation reported as of this date
22 October 2026 Imperva demonstrates code execution (reported as 22 or 23 October)
23 October 2026 The Hacker News covers the exploit demonstration; CISA’s assessment lists exploitation as “none”
24 October 2026 Amazon Linux 2023 brotli fix released
26 October 2026 ELLIO records the first in-the-wild exploit attempt at 15:08 UTC
27 October 2026 CISA adds CVE-2026-111497 to its Known Exploited Vulnerabilities catalogue; Previdian logs an attempt
10 November 2026 CISA due date for US federal agencies
29 October 2026 This article published

Sources

Common questions

What is Node2Shell (CVE-2026-111497)?

Node2Shell is the nickname for CVE-2026-111497, a memory flaw in Google’s Brotli decoder, the code that unpacks Brotli-compressed data. Node.js bundles that decoder, so Node.js 22, 24 and 26 before the 21 October 2026 releases are affected, along with end-of-life versions and other software such as Bun, Envoy, Istio and .NET. At worst it lets an attacker run their own code on the server without logging in. BLACKBX checks the sites it looks after against advisories like this one every day.

How do I know if my website uses Node.js?

Ask whoever manages your server or built your site whether Node.js runs anywhere in it, including inside containers. If it does, they can run `node -v` in each place to see the version and compare it with the fixed releases for CVE-2026-111497: 22.23.4, 24.22.1 and 26.12.1. If no one can answer the question, BLACKBX can tell you whether the flaw applies to your site and, on Maintenance and Full service, fix it.

Which Node.js versions fix CVE-2026-111497?

Node.js 22.23.4, 24.22.1 and 26.12.1, all released on 21 October 2026, fix CVE-2026-111497. Node.js 20 and older are end-of-life and get no fix, so they need to move to 22.x or 24.x. Container images must be rebuilt, and on Red Hat or Debian the system brotli package also needs updating. BLACKBX records every update like this, with its date, in the client’s logbook.

Is CVE-2026-111497 being exploited?

Yes. CISA added CVE-2026-111497 to its Known Exploited Vulnerabilities catalogue on 27 October 2026. ELLIO recorded the first attempt on 26 October 2026 and Previdian logged another on 27 October; sources disagree on whether the first attempt succeeded, and who is behind the attacks is not known. When a site BLACKBX looks after matches a critical advisory like this, our developers patch it immediately.

Is CVE-2026-111497 rated 9.8 or 9.2?

Google, which issued CVE-2026-111497, scored it 9.2, critical, on CVSS version 4.0. Red Hat and Microsoft scored it 8.1 on version 3.1, because the attack only works where the target unpacks Brotli data an attacker controls. Node.js rates it “high”, and NVD has not scored it. We could not find a 9.8 score in any published source. BLACKBX treats it as critical and patches matching client sites immediately.

I’m still on Node.js 20. Am I affected by CVE-2026-111497?

Assume so. Node.js says end-of-life versions are always affected, and Node.js 20, 18, 16, 14 and 12 will not get a fix for CVE-2026-111497. The only answer is to move to Node.js 22.x or 24.x and redeploy. On the Monitor plan, BLACKBX sends that finding to your own developer with the version numbers and advice; on Maintenance and Full service, BLACKBX does the work.

Is this your site?

Does your website run on an affected version of Node.js?

Tell us your website and we will tell you whether CVE-2026-111497 applies to it. If it does, we will fix it and record exactly what changed.

Ask us if this applies to you Get these alerts by email

Or call +61 2 9043 1246. Monthly plans, no minimum term.