On 21 October 2026 the Node.js team published security releases for every supported line. Ten vulnerabilities were fixed, four of them rated high. One is an out-of-bounds write in the Brotli decoder that the advisory says allows remote code execution.
The mitigation is simple to state and easy to get wrong in practice: update Node.js to a patched version. This post lists what was fixed, which versions to install, and how to check that your servers, containers and CI are really running them.
The fixed versions
| Release line | Status | Install this version |
|---|---|---|
| Node.js 22 | LTS | 22.23.4 |
| Node.js 24 | LTS | 24.22.1 |
| Node.js 26 | Current | 26.12.1 |
If you run an older line such as Node.js 18 or 20, there is no patch for you. The Node.js team states that end-of-life versions are affected by every security release and will not receive fixes. Your only real option is to move to a supported line.
What was fixed
The official advisory lists ten CVEs. It gives each one a short title and a severity, but it does not publish full write-ups, so this table sticks to what the advisory says.
| CVE | Severity | Affects | Component and issue |
|---|---|---|---|
| CVE-2026-111497 | High | 22, 24, 26 | Brotli decoder: out-of-bounds write that permits remote code execution |
| CVE-2026-105483 | High | 24, 26 | TLS: hostname check bypassed when an IP is written with fullwidth digits |
| CVE-2026-106069 | High | 22, 24, 26 | TLS: hostname check bypassed when a host loosely resolves to an IP address |
| CVE-2026-105482 | High | 22, 24, 26 | dns.resolve: names containing a NUL character are truncated |
| CVE-2026-105481 | Medium | 22, 24, 26 | Keep-alive sockets: a response written before the request was sent gets processed |
| CVE-2026-106072 | Medium | 22, 24, 26 | TLS: non-canonical IPv4 hostnames let DNS names in a certificate authenticate IP endpoints |
| CVE-2026-106074 | Medium | 22, 24, 26 | crypto.randomUUID() and randomInt(): cached entropy saved into startup snapshots and single executable apps, so every process repeats the same values |
| CVE-2026-106073 | Low | 22, 24, 26 | Permission Model: bypass through fs.realpathSync |
| CVE-2026-106070 | Low | 26 | ZipFile: attacker-controlled prefix bytes returned after a failed header check |
| CVE-2026-106071 | Low | 26 | Permission Model: filesystem over-grant through a wildcard lookup |
The release also bumps bundled dependencies: c-ares, undici, OpenSSL (22 and 24) and SQLite (22). It also adds the eMudhra intermediate CA to the blocked list in the built-in certificate store, after that CA was reported compromised.
What each group of bugs means for you
The Brotli bug is the urgent one
Brotli is a common compression format on the web. A decoder bug that writes outside its buffer while handling data from the network is the kind of flaw that attackers can aim at a server that fetches or receives compressed content. Coverage of the release notes that fetch() and Express 5 decompress Brotli automatically, which would make an app reachable without any special code. The advisory itself does not spell out the exploit conditions, so I would not try to judge whether your app is "probably fine". Patch it.
Three TLS and DNS bugs break trust checks
Hostname verification is what stops someone with a valid certificate for one name from impersonating another. Two of the high bugs (CVE-2026-105483 and CVE-2026-106069) are bypasses in that check when the host is an IP address written in an unusual way. The medium bug CVE-2026-106072 is the same family. If your service calls internal APIs by IP, or calls URLs that users can influence, these are the ones that matter. Note that the fullwidth-digits bug does not affect Node.js 22 according to the advisory.
The NUL-character bug in dns.resolve (CVE-2026-105482) is a classic: one layer sees evil.com\0.trusted.com as a trusted name, another layer cuts it at the NUL byte. It matters wherever a hostname from a user or a certificate is checked and then resolved.
Duplicate random values after a snapshot
CVE-2026-106074 only affects you if you build startup snapshots or single executable applications (SEA). In that case entropy cached at build time is baked in, and every process started from that binary can return the same crypto.randomUUID() or crypto.randomInt() values. If you use those for tokens, IDs or anything secret, that is a real problem. Most apps that simply run node server.js are not in this group.
The Permission Model and ZipFile fixes
These are rated low. If you use --permission to sandbox file access, update anyway: a bypass in fs.realpathSync weakens exactly the thing you turned the flag on for.
How to mitigate: update, then prove it
The advisory lists no workaround other than upgrading, so the work is making sure the new version really reaches every place Node.js runs.
1. Check what you run now
node -v
Do this on your servers and inside your containers, not only on your laptop.
2. Update the runtime
# nvm
nvm install 24 && nvm alias default 24
# or install an exact version
nvm install 24.22.1
On Docker, pin the patched version and rebuild the image, because an old cached layer keeps the old Node.js:
FROM node:24.22.1-alpine
docker build --no-cache -t my-app .
3. Update CI and hosting
Search your repository for every place a version is written: .nvmrc, engines in package.json, actions/setup-node in GitHub Actions, the Node.js version setting on Vercel or Netlify, and your Dockerfile. A patched laptop and an unpatched CI pipeline is a common outcome.
4. Replace snapshots and single executable apps
If you ship an SEA or a startup snapshot, rebuild it with the patched Node.js. Updating the runtime on the server does not change the entropy already baked into an old build.
5. Verify after deploy
docker exec <container> node -v
Confirm the output is 22.23.4, 24.22.1, 26.12.1 or newer on your line.
If you cannot update today
The advisory offers nothing here, so treat this as general hardening and not a fix:
- Keep the service off the public internet or behind a reverse proxy while you plan the upgrade.
- Avoid fetching URLs from untrusted input, especially by IP.
- Plan the move off end-of-life lines now. Each release without a patch for them widens the gap.
My take
I run Node.js and NestJS services, and the part of a release like this that costs time is not the nvm install. It is finding the fourth place where an old version number was written. Before you close this tab, do a quick search for your Node.js version in Dockerfile, .nvmrc and your CI files, and write down which of them you actually changed.
I have not reproduced any of these bugs. This post summarizes the official advisory and secondary coverage, and the advisory has the final word on which versions are affected.
Sources
Working on something like this?
I take on backend, payments and deployment projects. I reply within one working day.
