Node2Shell: Closing the Node.js Vulnerability and Proving It in Your Audit

Key takeaways

• Node2Shell (CVE-2026-111497) is an out-of-bounds write in the Node.js Brotli decoder, reachable through the node:zlib module. Without logging in, a remote attacker can crash the process, read memory contents, or execute code. Node.js rates the flaw "High"; a CVSS score of 9.2 has also been reported.
• Node2Shell has been fixed since October 21, 2026, in Node.js 26.12.1, 24.22.1, and 22.23.4. Node.js 25, 23, 20, and older versions get no fix because these release lines are end of life.
• The root cause sits in Google's Brotli library, fixed in versions 1.2.1, 1.1.1, and 1.0.10. That is why Bun, .NET, Envoy, Istio, Python HTTP clients, FFmpeg, Apache Arrow, and ClickHouse are affected too.
• Exploit code is public on GitHub, ELLIO reported attack attempts on October 26, 2026, and the US agency CISA has listed the flaw as actively exploited since the end of October. US federal agencies must patch by November 10, 2026.
• The vulnerability alone is not a reportable incident under NIS2. In an ISMS under ISO 27001, your response falls under control A.8.8; at your next audit you should be able to show the inventory, the decision, the patch date, and the evidence.

‍

On October 21, 2026, the Node.js project released security updates for a flaw that has become known as Node2Shell. This Node.js vulnerability does not sit in an npm package but in the Brotli decoder that every Node.js installation ships with. That puts web applications and APIs at risk, and also build servers, CI runners, and container images that run Node.js.

After PHP2Shell, Node2Shell is the second flaw of this kind in a few weeks to hit a widely used runtime directly. Unlike PHP2Shell, this one reaches well beyond a single project, because the defect lives in a library that many other products use as well.

This article is for ISMS owners, IT leads, and compliance teams, not developers. It explains what the flaw is, how to find out whether you are affected directly or through your suppliers, and what Node2Shell means for companies that are ISO 27001 certified or fall under NIS2.

What is Node2Shell?

Node2Shell is a vulnerability in the Node.js Brotli decoder. Brotli is a compression format that web servers and browsers use to send data in smaller packages. When an application processes manipulated Brotli data through the built-in node:zlib module, the decoder writes past the end of an internal buffer. This is called an out-of-bounds write.

The consequences range from a process crash to the disclosure of memory contents to the execution of malicious code, known as remote code execution. Attackers need neither credentials nor access to your internal network. Node.js rates the flaw as "High" severity. Reports, for example by GCN, also cite a CVSS score of 9.2, without saying who assigned it.

Why does the flaw reach beyond Node.js?

The root cause is not in Node.js itself but in Brotli, an open-source library from Google. Node.js bundles this library, and so do many other products. Trade media therefore also call the flaw Brotli2Shell. According to Help Net Security, the affected products include Bun, .NET, Envoy, Istio, Python HTTP clients, FFmpeg, Apache Arrow, and ClickHouse alongside Node.js.

The backstory stands out. The fix to the Brotli library was committed on February 27, 2026, but without a new release and without a security advisory. The change was publicly readable for eight months before the fixed Brotli versions 1.2.1, 1.1.1, and 1.0.10 came out. Anyone who only updates dependencies on official releases had no way of picking up the fix during that time.

How has the situation developed?

On October 21, 2026, Node.js disclosed the flaw and shipped fixed versions the same day. Shortly afterward, proof-of-concept code appeared on GitHub. On October 26, the threat intelligence company ELLIO reported attack attempts that its sensors had recorded on the internet.

At the end of October, the US cybersecurity agency CISA added Node2Shell to its catalog of known exploited vulnerabilities. US federal agencies must close the flaw by November 10, 2026. That deadline does not bind European companies. It does work as an outer limit, though: anything still unpatched after that date is hard to justify to an auditor.

Which Node.js versions are affected?

Affected are the Node.js 22, 24, and 26 release lines before the security releases of October 21, 2026, as well as every release line that is end of life. For all other products with a Brotli decoder, the version of the bundled library decides.

The versions in the table are minimums. Node.js has announced further security releases for November 11, 2026. So install the latest patch release of your release line, not just the version listed above. Full details are in the Node.js project's security advisory.

A common misconception goes: "We don't run Node.js, so this doesn't affect us." The Brotli flaw also sits in products where nobody thinks of Node.js. One example is the Windows builds of PHP, which bundle Brotli and were therefore rebuilt on October 26. What this means for PHP servers is covered in our article on PHP2Shell. Linux distributions also ship Brotli as a separate package, which you update through your regular system updates.

What should companies do now?

The most important task is a complete overview of where Node.js and other software with a Brotli decoder runs in your company. Node.js often sits in places that never show up in a server inventory: build pipelines, container images, and tools that development teams run themselves.

1. Build the inventory (day 1, IT operations and engineering). Record every Node.js runtime with its version: servers, container images, CI runners and build servers, internal tools, and staging environments. Also check the other products from the table, such as Envoy or Istio in your service mesh.
2. Patch (days 1 to 2, engineering). Update to at least 22.23.4, 24.22.1, or 26.12.1, ideally to the latest patch release. For Bun, the minimum is 1.4.4.
3. Rebuild images and restart processes (day 2, DevOps). An update only takes effect once the running process uses the new version. Containers that point to a fixed image tag with an old Node.js version stay vulnerable until you rebuild and roll out the image.
4. Retire end-of-life versions (week 1, IT leadership). Anything still on Node.js 20, 23, or 25 will not get a fix. Plan the move to version 22, 24, or 26 and record when it will happen.
5. Reject Brotli requests in the meantime (now, network or operations). Until you have patched, you can reject requests with the "Content-Encoding: br" header at your reverse proxy or load balancer. This only protects against incoming requests. It does not cover Brotli-compressed responses that your application fetches from other servers itself.
6. Ask your suppliers (week 1, information security officer and procurement). Ask SaaS providers, hosting providers, and agencies in writing whether their systems were affected and by when they patched. This also applies to managed cloud services where the provider updates the runtime.
7. Document and escalate on suspicion (ongoing, information security officer or CISO). Record when you learned about the flaw, which systems were affected, and when you patched. If there are signs of compromise, such as unexplained crashes of Node.js processes since October 21, your incident response process kicks in.

The most common mistake after a patch day goes: "The package is updated, so we're done." The server then has the new Node.js version on disk, but the old process keeps running until it restarts. Likewise, Kubernetes often still runs a pod with the old image while the new one has long been in the registry. So don't stop at "Did we patch?" Ask "Which version is running right now?"

What does NIS2 require for a flaw like Node2Shell?

Under NIS2, vulnerability handling is an explicit obligation. Article 21(2) of the directive requires measures for supply chain security (point d) and for security in the acquisition, development, and maintenance of systems, including vulnerability handling (point e). In Germany, both duties sit in section 30 of the BSI Act, which the NIS2 implementation act revised with effect from December 6, 2025.

When does the reporting duty apply?

A vulnerability alone is not a security incident. The fact that your systems ran a vulnerable Node.js version does not trigger a report to your authority. The reporting duty only applies to a significant incident, for example if attackers used Node2Shell to steal data or take a service down.

If that happens, the deadlines in Article 23 NIS2 apply: an early warning within 24 hours of becoming aware of the significant incident, an incident notification within 72 hours, and a final report no later than one month after that notification. In Germany, the reports go to the joint reporting office of BSI and BBK.

What applies to suppliers and customers in the supply chain?

Node2Shell is a textbook supply chain case. Many companies run hardly any Node.js themselves, but use SaaS products, agency-built websites, and hosting services that run on it. You can't patch those services yourself; you have to ask for their status and document the answer.

The same applies the other way around. If your customers fall under NIS2, their procurement and security teams will ask in the coming weeks how you responded to Node2Shell. If you can then show versions, patch dates, and the status of your own suppliers, you answer the questionnaire in one go. Which questions and contract clauses to expect, even if your company is not in scope itself, is covered in our article on NIS2 in the supply chain.

How do you handle Node2Shell in an ISMS under ISO 27001?

In an ISMS under ISO 27001:2022, Node2Shell is a test case for several Annex A controls. At its center is A.8.8, management of technical vulnerabilities: you have to obtain information about vulnerabilities in time, evaluate your exposure, and take appropriate measures.

Other controls come into play as well. A.5.9 requires an inventory of assets, without which you don't know everywhere Node.js runs. A.8.9 covers configuration management, which includes the question of which image version runs in production. A.5.19 to A.5.22 cover supplier relationships, from contract terms to monitoring your service providers. A.5.24 to A.5.26 govern incident management from planning through assessment to response. How these ISO 27001 controls work together is explained in a separate article.

What do auditors want to see?

At your next surveillance audit, the question will come up how your company responded to Node2Shell. An auditor expects four things: an inventory of affected systems, a documented assessment decision, the patch date per system, and evidence that the new version is actually running. For systems you could not patch right away, a justified exception with a deadline belongs on that list.

An example: a SaaS company with 40 employees runs three services on Node.js 22 in nine container images. The CI runners are still on Node.js 20, and an agency looks after the marketing website. The team rebuilds the images on the day of the disclosure and moves the CI runners to Node.js 24 the following week, because version 20 gets no fix. The agency confirms by email that its hosting provider has patched. With timestamped tickets and the agency's confirmation attached to the vulnerability process, the auditor's question is answered quickly.

End-of-life versions are where audits often get stuck. A release line without support is not a one-off issue of this flaw but a lasting risk that belongs in your risk register. How to deal with a fixed end of support is shown in our article on PHP 8.2 end of life, using another runtime as the example.

What applies under the GDPR if personal data is affected?

The GDPR applies regardless of NIS2. If attackers used Node2Shell to access customer data, credentials, or other personal data, that is a personal data breach. Under Article 33 GDPR, you must notify the competent supervisory authority within 72 hours, unless the breach is unlikely to result in a risk to the people concerned.

Because the flaw also allows memory contents to be read, bring in your data protection officer early, not only after the technical analysis is finished. When notification is mandatory and what should happen in the first hour is covered in our article on personal data breach notification.

How can you prove the fix automatically?

After a flaw like Node2Shell, you don't just have to fix it; you also have to prove it in your audit. According to Aikido Security, its platform flags the affected Node.js versions in repositories and container images, and its dashboard shows which services still run a vulnerable runtime. That covers the first step, the inventory, for your own code.

Through the Aikido and Kertos integration, Kertos reads these findings and the remediation deadlines you have set for them every day. If no deadline has been missed, the check passes and Kertos stores the result as evidence for the matching requirements in ISO 27001, NIS2, and SOC 2. The connection is read-only and changes nothing in Aikido.

For your audit, this means the evidence of when a vulnerability was found and when it was fixed is created where the work happens. Kertos's certified experts help you set up your vulnerability, supplier, and incident processes so they hold up against the next critical flaw as well. If you'd like to see what this looks like in your environment, book a demo.

Frequently asked questions

What is Node2Shell?

Node2Shell is the name for CVE-2026-111497, an out-of-bounds write in the Node.js Brotli decoder. Without logging in, a remote attacker can use it to crash the process, read memory contents, or execute code. Node.js released fixed versions on October 21, 2026.

Am I affected by CVE-2026-111497?

You are affected if you run Node.js 22, 24, or 26 before versions 22.23.4, 24.22.1, and 26.12.1, or any release line that is end of life. Because the root cause sits in Google's Brotli library, Bun, .NET, Envoy, Istio, Python HTTP clients, FFmpeg, Apache Arrow, and ClickHouse can be affected too. Also check whether your SaaS providers and hosting providers have patched.

Which Node.js version is safe?

Node.js 26.12.1, 24.22.1, and 22.23.4 are the minimum versions that fix Node2Shell. Node.js has announced further security releases for November 11, 2026, so run the latest patch release of your release line. For Bun, the minimum is version 1.4.4.

What should we do if we still run Node.js 20?

Node.js 20 is end of life and gets no fix for Node2Shell, and neither do versions 23 and 25. Move to Node.js 22, 24, or 26, and until then block requests with "Content-Encoding: br" at your proxy. Anything you can't switch over right away should be documented in your risk register as an exception with a deadline.

Do I have to report Node2Shell under NIS2 or the GDPR?

Not just because your systems had the vulnerability. Under NIS2, only a significant incident is reportable: an early warning within 24 hours, an incident notification within 72 hours, and a final report no later than one month after that. If personal data is affected, the 72-hour deadline in Article 33 GDPR applies as well.