Node.js vulnerability: what to do now

On 21 October the Node.js project released a security update for ten vulnerabilities. The most serious, CVE-2026-111497, is in the part that unpacks data compressed with Brotli. With specially crafted data, an attacker can write outside the memory set aside for it. That can crash a program, leak memory or, in the worst case, run the attacker's code. The flaw is in every supported version of Node.js and in all older ones. Versions 22.23.4, 24.22.1 and 26.12.1 fix it.

Why this reaches further than it seems

Node.js runs underneath many web applications, APIs, customer portals and internal tools, and also underneath a lot of development and AI tooling. You do not have to use Brotli yourself to be affected. Brotli is a common way to make web traffic smaller, and the built-in fetch function of Node.js unpacks such responses automatically. If your application fetches something from an address someone else controls, that can already be enough.

On top of that, Node.js on a server is often not updated automatically. If it was once installed from a separate package source or an install script, it stays on that version until someone deliberately updates it. The operating system's automatic security updates usually do not include it.

What to do now

1. Find out what runs on Node.js in your organisation: your website or web app, a customer portal, integrations between systems and the servers where developers or AI agents work. Not sure? Ask your web developer or IT partner.
2. Update to 22.23.4, 24.22.1 or 26.12.1, depending on the version you use. If you run a version that is no longer supported, no fix is coming: move to a supported version.
3. Then check which version is really running. An updated package does nothing while the old process is still running; the new version only runs after a restart.
4. Check whether any Node.js processes have crashed unexpectedly since early October. A failed attack often leaves a crash behind. If you find one, bring in someone who knows what to look for.
5. Record what you did and when. If your organisation falls under NIS2, or a customer asks for proof of your security, you will have it at hand.

And Stilops itself

Stilops runs on Node.js, and our agents fetch web pages for their work. So we were affected. On the day we saw the flaw, we made sure every deployment first brings Node.js to the patched version, and that the machines our agents work on are rebuilt with that version. Our test environment now always fetches the latest version too.

We then checked for signs of abuse. We found no unexpected Stilops crashes since 8 October, as far back as our logs go, and no crash files left behind. No traces is not proof that nothing happened, but it is what you can measure. We keep watching.