Node.js Brotli vulnerability (CVE-2026-111497): we ran an affected version, patched it and found no sign of exploitation

This morning we wrote that LFW.com wasn't affected by the PHP security issue, because no PHP runs on our servers.

This one applied to us: our server ran an affected version. LFW.com runs on Node.js, and the Node.js project released security fixes today at 6:38 AM Eastern. We updated our server at 1:24 PM the same day.

What Node.js fixed

The release fixes ten vulnerabilities in the 26.x, 24.x and 22.x release lines. Four are rated high. The one that matters most for us:

• CVE-2026-111497, the Brotli decoder. Brotli is a common way to compress web traffic. A flaw in how Node.js unpacks it can write past the end of a block of memory. The Node.js project says it permits remote code execution: running someone else's code on your server.

As of 2 PM Eastern on October 21, neither the Node.js project nor the security press reports attacks in the wild or a public exploit.

Update to 22.23.4, 24.22.1 or 26.12.1. Node.js says end-of-life versions are always affected and get no fix, so move those to a supported version.

How it reached us

Most of LFW.com is made of pages built ahead of time. But the server also does work that means fetching other people's websites:

• the free audit, which loads any site a visitor types in;
• our monitoring, which checks sites on a schedule.

When Node.js fetches a page, it unpacks Brotli automatically. So a hostile site could answer one of those requests with compressed data built to corrupt our server's memory. In the worst case, that lets the attacker run their own commands on our server: read what it stores, plant a backdoor, or use it to attack other sites. The free audit is the riskiest part, because a stranger chooses the address.

What we did, and when

The timeline, in Eastern time:

• 6:38 AM: the Node.js project published the fixed versions.
• 1:24 PM: we updated Node.js on our server to 22.23.4 and restarted the site.
• Right after: we checked the server for signs that anyone had used the bug while it was open.

That left about six and three-quarter hours between public disclosure and our update. We'd rather it had been shorter.

How we checked we weren't exploited

We started with what our server actually fetched during those hours:

• No free audits ran. Nobody asked the server to load an outside site of their choosing.
• No site scans ran.
• Monitoring checked only our own sites.

The traces an attack usually leaves

Then we looked for them on the server:

• No crashes. A failed attempt to corrupt memory usually crashes the program. The web server's logs for the past week show no crashes, memory errors or forced restarts.
• Nothing extra running. The service account runs only the web server and the search engine, with no stray programs started by either.
• Nothing new on disk. No new scripts or programs in the temporary folders, and no changes to scheduled tasks or service settings beyond our own deploy.
• No new ways in. Server logins over the last 30 days came only from our own two keys, and the list of allowed keys hasn't changed since September.

The web traffic itself

Last, we read every request from the release to the update:

• Quieter than the day before, with no server errors at all.
• Every request came through Cloudflare. Our firewall only accepts web traffic from Cloudflare, so nothing reached the server directly.
• About 200 routine probes, the background noise every public site gets. Most were looking for PHP files on a server with no PHP. Every one got a not-found or not-allowed answer.

These checks find the usual signs of an attack. They can't prove a negative, and we won't claim they do. We found nothing.

Where Cloudflare helps, and where it doesn't

Our traffic is proxied through Cloudflare, which filters requests before they reach our server. That's real protection for what comes in.

This bug's main path ran the other way, though: our server reading responses from other sites. Cloudflare doesn't sit in that direction, so the update is what fixed it.

Our own workstations

Our local workstations run Node.js too. They aren't internet facing, so the risk was lower. Out of an abundance of caution, we prioritized updating them to fixed versions as well.

The rest of the release

The other fixes are worth knowing about if you run Node.js:

• Two TLS certificate hostname bypasses (CVE-2026-105483 and CVE-2026-106069), both rated high. Certificate checks are how a program knows it's talking to the right server.
• A DNS name truncation bug (CVE-2026-105482), rated high: names containing a hidden NUL character get cut short.
• Repeated random values in snapshots (CVE-2026-106074), rated medium. Apps packaged as a single executable or startup snapshot could repeat the same "random" IDs in every process.
• Updated root certificates. The release also updates Node.js's bundled certificates after the compromise of an eMudhra intermediate certificate authority.

The full list is in the Node.js advisory.

What to check on your own

If your site or tools run on Node.js:

• Update to 22.23.4, 24.22.1 or 26.12.1. Your build tools count too.
• Start with anything that fetches outside content: link checkers, image proxies, feed readers, webhooks, scrapers. That's what the Brotli bug reaches.
• Rebuild anything packaged as a single executable or snapshot. Updating Node.js on the server doesn't update a copy baked into a program.
• On managed hosting? Check your host's status page. Many update Node.js for you.

If you'd like a hand

We're glad to help you work through any of this, from finding what runs Node.js to checking a server after an update. Write to us.