Node.js Patched a Brotli Remote Code Execution Flaw on October 21. If Your Server Decompresses Anything, Check Your Version Before Lunch.
On October 21, Node.js shipped security releases for all three supported lines to fix 10 CVEs, and one of them, CVE-2026-111497, is an out-of-bounds write in the bundled Brotli decoder that Node describes as allowing remote code execution. Qualys cites a CVSS 4.0 score of 9.2 for it, while other coverage rates it simply "high." Either way, if you run a Node server that you patch by hand, you have a five-minute job today.
What shipped
The fixed versions are 26.12.1, 24.22.1 and 22.23.4. The release also fixed three other high-severity bugs: two TLS hostname-check bypasses involving oddly written IP addresses, and a dns.resolve bug that truncates a name at a null byte. Medium and low items include a Permission Model bypass and randomUUID() values repeating across processes in snapshot builds.
The Brotli bug is triggered by a malformed compressed stream. The decoder writes past the end of the memory it was given. Node published no workaround, so upgrading is the only complete fix.
Who is actually exposed
You are exposed if your code decompresses Brotli data that someone else controls. Two common routes: node:zlib decompressing a request body or an upload, and fetch(), which decompresses automatically when a response arrives with Brotli compression. That second route matters more than it sounds, because it means a server of yours that calls a third-party API is exposed if that response can be influenced by an attacker.
The honest status as of October 22: The Hacker News reported that a public proof of concept got code execution only on a deliberately weakened test build. On a standard build it produced a crash and a limited read of process memory. No in-the-wild exploitation had been reported. I would not panic, and I would not wait for that to change either, because proofs of concept tend to improve.
The part that bites solo operators
Node 20 reached end of life on April 30, 2026, and gets no fix. Node 25, 23 and 21 are also unpatched, because only supported lines receive security releases. The practical question is not "did I update," it is "which tag is my Dockerfile pinned to, and when did I last look?"
A pinned FROM node:20-slim in a side project from last year is the classic case. Nothing broke, so nothing prompted you to look. The same goes for a VPS where you installed Node once through a version manager and never touched it again.
Vercel added firewall rules on October 21 that block the attack in inbound requests, according to The Hacker News. Those rules do not cover Brotli responses your own code fetches from other servers. A platform rule narrows the exposure, but it does not replace the upgrade.
The five-minute check
Run node -v on every box and inside every container you own. If it prints a version below the three fixed ones in its line, or a line that is not 22, 24 or 26, you have work to do. In Docker, check the base image tag rather than your laptop, since those often differ.
node -v node -p "process.versions.brotli" # Dockerfile: look for the base tag grep -n "^FROM node" Dockerfile
Then pick the upgrade path. If you are on 22 or 24, move to the patched release in that line. If you are on 20 or 25, move to 24, which per one tracker is supported until April 30, 2028. That is the boring choice, and for a one-person shop boring is the point.
If you cannot upgrade today, limit what you decompress. Cap payload size and decompression ratio at your reverse proxy, and avoid accepting Brotli from untrusted sources. Qualys suggests exactly that as an interim measure, and it is a stopgap rather than a fix.
Where this could be wrong
My read on severity is based on secondary sources, because the official post does not yet describe what an attacker needs. If a later write-up shows reliable exploitation on stock builds, this becomes a drop-everything item. If it stays a crash on standard builds, then the urgency is lower than the headline score suggests. I would still patch, because the cost is minutes and the downside is your whole server.
What I'd actually do
Today: check every Node version you run, bump the base image tag, redeploy, and write the new version in a note somewhere. This week: switch your Dockerfiles to a supported major, 24 if you can, and set a calendar reminder for the next security release. Node publishes these on a schedule, and the real fix for this class of problem is having one place where you can see all your versions at a glance.
Author
Lukas
@lukcombinator