Node.js released fixes on October 21 for a flaw in its Brotli decoder. It is being called Node2Shell, it is tracked as CVE-2026-111497, and on October 27 CISA added it to its catalogue of vulnerabilities known to be exploited. Two things make this one awkward for an ordinary business. You do not have to write a line of Node to be running it, and if a platform hosts your application, the patch version is not yours to pick.
What the flaw is
An out-of-bounds write in the Brotli decoder bundled with Node.js. Node rates it High. Google, which issued the CVE, scores it 9.2 and calls it critical.
The outcome can be a crash, disclosure of memory, or remote code execution, which means an attacker running their own commands inside your application.
It is fixed in Node 22.23.4, 24.22.1 and 26.12.1. Node 20 and anything older is past end of life and will not get a fix at all.
You do not have to use Brotli to be exposed
Brotli is a compression format, the same idea as a zip file, used to make web responses smaller. Almost nobody calls it on purpose.
The problem is that Node calls it for you. When your application fetches something from another server and that server answers with a Brotli-compressed response, Node decompresses it before your code ever sees it. Ordinary outbound requests are enough.
So the useful question is not whether you use compression. It is what your application pulls in from outside: an API you query, a feed you read, a webhook you accept, a link preview you generate. An application that only serves its own pages and fetches nothing from anywhere is in a far better position than one talking to third parties all day.
Being on Node 24 is not the same as being patched
This is where a lot of businesses will get a false answer.
Managed hosting platforms let you choose the major line, 22 or 24, and then manage the patch number underneath it themselves. A settings page that says Node 24 tells you nothing about whether you are on 24.22.1 or on something from six weeks earlier.
The only dependable answer comes from asking the running application which version it is on, rather than reading it off a dashboard. That is a small piece of work for a developer and it converts a guess into a fact.
Several platforms have also shipped an interim mitigation, usually by refusing Brotli-compressed responses on unpatched runtimes. These commonly apply to deployments made after the mitigation went live, so an application that has not been redeployed in a while may not have it. If you are relying on a host's mitigation, confirm it actually covers what you are running.
What to do this week
List everything in your organization that runs Node. Your own applications, yes, but also build pipelines, self-hosted tools, anything bought as an appliance, and developer laptops.
For anything you control, upgrade to 22.23.4, 24.22.1 or 26.12.1 now.
For anything a platform runs for you, find out the real patch version, ask the vendor when they will roll the fix, and redeploy so you pick up whatever interim protection they have in place.
Anything still on Node 20 or earlier needs to move to a supported line. There is no patch coming for it, and this will not be the last advisory it misses.
One point of clarity on the deadline being quoted: CISA's November 10 date binds United States federal agencies. It is not a rule that applies to a Canadian business. Read it as a signal about how quickly this is being exploited, not as your compliance date.
When to call someone
If you cannot say today which Node version your production application is running, that is the thing to fix first, and it is fixable in an afternoon.
The pattern here is worth noticing beyond this one flaw. When you run on someone else's platform, you gain a great deal and you give up the timing of your own patches. That is usually a good trade. It only works if you know which parts you control, which parts you do not, and how to check the difference rather than assume it.
