Node.js flaw CVE-2026-111497 scored 9.2 out of 10: how I secured my web apps and my clients’ in 4 steps

On October 21, 2026, Node.js shipped a security update for a flaw in its Brotli decompressor, CVE-2026-111497. It carries a CVSS score of 9.2 out of 10, rated critical, and in the worst case it lets an attacker run code on the server hosting your web app. The fixed versions are 22.23.4, 24.22.1 and 26.12.1. My web apps and my clients’ web apps run on Node, so I went through every project in four steps.

What does the Node.js flaw do with compressed data?

CVE-2026-111497 exploits the way Node.js decompresses Brotli data travelling over the internet. According to the official Node.js advisory, malformed Brotli input causes an out-of-bounds write to an internal buffer. The impact ranges from a process crash to memory disclosure, up to remote code execution.

A Node.js application is exposed when its code, or a library it uses, decompresses attacker-controlled Brotli data with node:zlib. That can happen in the body of an incoming request or in a response fetched from an external server.

The 9.2 score is the one Google assigned in the CVE record (CVSS 4.0), because the bug lives in the Brotli library. Node.js rates it "High" in its advisory. The patch covers all three supported lines: 22.x, 24.x and 26.x. Compared with the PHP flaw from a few days earlier, the Node.js vulnerability is harder to exploit, but it is still serious.

How did I check every Node.js project?

These are the four steps I took on my projects and my clients’ projects.

1. Inventory with Claude Code. With Claude Code I listed, for each project, the frontend, the backend and the serverless functions, and which Node.js version each one runs.
2. Who updates what. I separated what the provider updates on its own from what I have to update myself.
3. Exposure of each backend. I analysed how exposed each backend was to the flaw.
4. Update everywhere. I updated Node.js on every project, my Mac included, and checked that the update didn’t introduce regressions.

Who updates Node.js: the provider or you?

On frontends with managed hosting, like Vercel, the platform had already done everything. Vercel’s security bulletin confirms that firewall rules blocking known exploit patterns went live the same day, and that projects on Node.js 22.x and 24.x get the fixed versions without changing any settings.

Backends are a different story. I pick the Node.js version of a backend, and nobody can change it for me. Vercel says so itself: anyone running Node.js outside its managed runtimes has to upgrade anyway, firewall or not. That covers external backends, containers, CI runners and local development environments.

This distinction is the step that matters most. Knowing who is responsible for each piece tells you where to act right away and where a quick check is enough. I went through the same reasoning for PHP, and I wrote it up in the article on which PHP version to update to and who has to do it.

How exposed was each backend?

Backends that need updating carry different levels of risk. That’s why I analysed the backends one by one, looking at whether and where they receive compressed data from outside.

In one of them the flaw could be exploited from the internet without logging in. That’s the worst possible case: anyone could send the malicious request. I fixed it immediately, before all the others.

That’s what prioritising each project is for. When you have many projects, starting with the publicly exposed one cuts the risk in the first few hours.

What do I take away from this vulnerability?

More and more vulnerabilities are coming. We’re in a period where flaws in libraries and frameworks come out one after another: PHP the day before yesterday, Node.js yesterday. It pays to stay on top of it and set up a process to update as soon as a fix ships for a vulnerable library or framework. That holds whether you do vibe coding or run a company with a product or a larger piece of software.

Claude Code helps a lot here: taking an inventory of versions and dependencies across many projects is exactly the kind of task an agent does well. If someone else looks after your company’s software, ask them what process they have for these cases: it’s part of good custom software development, after launch too.

End-of-life versions should be updated right away. An end-of-life version no longer gets patches: if a flaw comes out tomorrow, no fix will arrive for it. That’s exactly the case of Node.js 20, which according to Vercel is end-of-life and won’t receive the fix for CVE-2026-111497. A project that "has worked for years" can be the most exposed one.

If you run a web app on Node.js, today is the day to check it: its version, who updates it, and how exposed it is.