I opened advisory page this morning and the first thing I did was count. Ten CVEs, all released on October 21, 2026, and four of them marked High. The patched versions are 26.12.1, 24.22.1 and 22.23.4. If you run Node on any server, check which one you’re on before you read any further, it will only take a minute.
The one that worries me is CVE-2026–111497, a bug in the Brotli decoder that Node carries inside itself. The decoder can write data outside the memory it was given, and the advisory says that can lead to remote code execution. Nobody has reported attacks yet and CISA hasn’t put out an alert. But a public patch works like a map, because anyone can compare the old code with the new code and see what changed, and I wouldn’t count on the calm lasting.
I should say up front that I haven’t tried to exploit any of this, and I haven’t read the C++ diff line by line. What follows comes from the advisory summaries, a few security write-ups and my own reading of what they imply. Where I’m guessing, I’ll say so.
The ten fixes, roughly
Node shipped three releases at the same time, one for each supported line. The project splits the ten issues into four High, three Medium and three Low. Most of them hit every line, but not all, and this is where I got confused. GBHackers has a table that lists the Permission Model bypass through fs.realpathSync as affecting 26.x, 24.x and 22.x. The LinuxCompatible write-up, on the other hand, says all three Low issues are Node 26 only. I couldn't settle it from outside. If you use the permission model, read the official advisory at nodejs.org yourself and don't trust my summary or anyone else's.
The release also updates some bundled dependencies. c-ares and Undici move on every line. The CA certificate bundle changes too, to deal with the compromise of an eMudhra intermediate CA. OpenSSL is bumped on 24.x and 22.x, and SQLite on 22.x only.
The Brotli bug
Brotli is a compression format from Google. Websites use it a lot, and a server tells the client “this response is Brotli compressed” with a header, then the client has to unpack it. Node ships Google’s Brotli decoder so it can do that unpacking itself, both in the zlib module and for HTTP responses. The bug is in how that decoder handles malformed streams. If someone hands it a carefully broken stream, it can do an out-of-bounds write, which means it writes bytes past the end of the buffer it was supposed to stay inside. Best case, the process crashes. Worst case, the attacker controls what gets written and where, and that’s how people get code execution. The advisory rates it High and says RCE is possible. It affects 26.x, 24.x and 22.x. And because the decoder is built into Node itself in the normal builds, updating some Brotli package on your operating system won’t help, you need the new Node binary.
Who is exposed? Vercel’s security team made a point that Node doesn’t decode Brotli data on its own, meaning something in your app has to actually hand it Brotli data. That sentence narrows things a lot. Third-party analysis points to Express 5 servers and Next.js image optimization as exposed paths, and also to anything that scrapes or previews URLs you don’t control. I couldn’t find the exact route for Express 5 in the official text, so treat that part as someone else’s claim.
My own reading, and it’s only a reading, is that the risky direction is any code that decompresses data coming from outside. A server that fetches user-supplied URLs for link previews is one example. An API that accepts compressed uploads is another. If your app only talks to your own backend and a couple of trusted APIs, the risk is lower. Not zero, because a trusted API can get compromised too.
If an attacker does get code running inside your Node process, they get whatever that process has. That means the database passwords sitting in environment variables and any cloud credentials the instance can reach. It also means a foothold on the internal network, and a foothold is usually all an attacker needs to start walking around. Red Tiger Security pointed out that Node also runs in edge gateways and control room servers in industrial setups, where, I’d guess, patching is slow.
As for how it was found, the public record says only that a contributor with the GitHub handle mcollina reported it and another, aduh95, wrote the fix.
That’s all I could find. No fuzzing story, no write-up from the reporter, no proof of concept. Some of that may come later, but today it isn’t there. The report presumably went through the process in Node’s published security policy at github.com/nodejs/node/security/policy, though that’s an assumption on my side.
And the usual excuse, that nobody has a working exploit yet, is weak. The advisory gives no prerequisites, no payload details and no workaround, so you can’t know whether you’re exposed except by patching. I said earlier this can lead to code execution. That’s mostly true, though I’m oversimplifying. The advisory doesn’t promise that every app on an affected version can be hit remotely, and GBHackers made that same point in its own write-up. So the honest summary is “serious, unproven in the wild, and impossible to rule out for your app without looking.”
The TLS and DNS bugs
The other three High issues are all about whether a name or an address is what it claims to be.
When your app opens a TLS connection, it checks two separate things. First, was the certificate signed by an authority it trusts. Second, is the certificate actually for the host it meant to reach. The second check is hostname verification, and it’s what stops someone from handing you a valid certificate for some other site and pretending to be your bank. Two of the High bugs break that second check when the target is an IP address. CVE-2026–105483 involves IP addresses written with fullwidth digits, which are Unicode characters that look like normal numbers but aren’t. It affects 26.x and 24.x. CVE-2026–106069 involves hosts that loosely resolve to IP addresses, and it affects all three lines. The summaries I read don’t explain the exact mechanism and I won’t pretend to know it. The effect is that verification passes when it shouldn’t.
Add the Medium one, CVE-2026–106072, where DNS names in a certificate can authenticate a noncanonical IPv4 endpoint, and there’s a small cluster around the same weak spot. My guess is that this hurts most where services call each other by IP, like internal APIs or devices on a LAN. In practice a man-in-the-middle holding some valid certificate might get your app to trust the wrong machine. That’s the worst case, and it usually needs the attacker to already sit on the network path.
Side note, unrelated to Node itself: GoDaddy revoked 404,607 SSL certificates this week after an issuance error, according to GBHackers. Bad week for certificates in general.
CVE-2026–105482 is the easiest of the four to picture. The dns.resolve function cuts a name short when it contains a NUL character, which is the character C uses to mark where a string ends. A made-up example, only to show the idea: say your app checks that a hostname ends with .mycompany.com before it resolves it. A name like evil.net\0.mycompany.com passes the check, but the lookup stops at the NUL and goes to evil.net. This one affects all three lines. I haven't seen a real-world case of it, so take my example as an illustration and nothing more.
The medium and low ones
CVE-2026–105481 lets a keep-alive socket accept a response that arrives before the request was even sent. It’s an odd one, and I won’t guess at how anyone would use it.
CVE-2026–106074 is the one that changes how you deploy. The crypto.randomUUID() and randomInt() functions keep caches of random values. If a cache gets frozen into a user-land startup snapshot or a single-executable app, every process started from it can hand out the same values. LinuxCompatible says this is the reason the advisory tells you to rebuild and not only upgrade, since the old values are already baked into what you built. GBHackers adds a useful limit, which is that this isn't a failure of all cryptography in Node, only of those cached values. Still, if you used randomUUID() for session IDs inside one of those apps, repeated values are a bad day.
The three Low issues sit in the ZIP reader and in the experimental Permission Model, so most people can skip them.
What to do today
The advisory offers no workaround, so this is an upgrade job. Here is the order I’d go in. Internet-facing services that fetch or decompress outside data come first. Services that connect over TLS by IP address come second. Internal tools are third, and developer laptops last.
First, find every place Node runs. Servers first, then Docker base images, then CI runners, then anything serverless that pins a version. On a machine, node -v is enough. For one image, run it like this:
docker run --rm --entrypoint node your-image:tag -vIf you have a pile of images on a build box, this loop prints the Node version in each of them, and prints “no node” where there isn’t one:
for img in $(docker images --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>'); do
echo -n "$img "
docker run --rm --entrypoint node "$img" -v 2>/dev/null || echo "no node"
doneSecond, upgrade to the fixed version for your line, which is 22.23.4, 24.22.1 or 26.12.1. With nvm that’s nvm install 22.23.4. For Docker, pin the full version in your tag, and check that the tag really contains the new release, since I haven't verified what Docker Hub has today. Put the version in .nvmrc or your CI config so the next person doesn't guess.
Third, rebuild anything made as a single-executable app or from a startup snapshot. This is the CVE-2026–106074 part, and an upgrade alone leaves the old cached values inside.
Fourth, deal with Node 20 and Node 25. Both are end-of-life, so no fixes are coming for them, and the Node project says end-of-life versions are always affected when a security release happens. Move to a supported line. A blogger on lilting.ch wrote up a test of v24.22.1 against v24.22.0 and the EOL v25.3.0 if you want a second source, though I haven’t read it closely.
One more check that people skip. Node bundles Undici, and this release updates the bundled copy. If your project also installs undici from npm, that's a separate copy and upgrading Node won't touch it. Run npm ls undici and see what comes back.
If you really can’t upgrade today, I’d cut off the paths I described above. Stop fetching user-supplied URLs and stop accepting compressed uploads for now. That stopgap is my own idea and not from the advisory, so don’t count it as a fix.
There’s also some background that helps explain the rush. Back on March 24, 2026, Node had another security release, with a High denial of service bug (CVE-2026–21710) where a __proto__ header name could crash an HTTP server. The fixed versions then were 22.22.2 and 24.14.1. So anyone who last upgraded in March is on 22.22.x or 24.14.x and has a few releases to catch up on, not just this one.
What I still can’t tell you
As of October 22, none of the ten had a CVSS score published, so any number your scanner shows this week could be a placeholder. The reporter hasn’t explained how the Brotli bug was found. The advisory doesn’t spell out what an attacker needs for the decoder bug, and I already mentioned the Low issue that two sources list differently. I’d rather leave those open than fill them in with a guess.
One last detail, mostly a curiosity. This release is also the last under Node’s old schedule. According to LinuxCompatible, the project is dropping two major versions a year and moving to one annual release numbered by year, starting with Node 27 in 2027. I haven’t made up my mind on what that means for people who maintain version matrices.
What I do know is simpler. Run node -v on the machine in front of you, and then on the one you forgot about.