On the same day as the critical PHP fix, October 21, 2026, the Node.js project published a new round of security fixes: 10 vulnerabilities fixed across versions 26, 24 and 22, four of them rated high. The most serious is an out-of-bounds write in the Brotli decoder that, according to the official notice, allows remote code execution.

If your API, your Next.js front end, your workers or your serverless functions run on Node.js, this article shows what changed, what to prioritize and how to update without surprises.

Summary for the busy

  • Update to Node.js 26.12.1, 24.22.1 or 22.23.4, depending on your release line.
  • Node.js 20 or older has reached end of life and gets no fix. It is time to migrate.
  • Beyond the code, rebuild Docker images, update the CI runtime and check the version used by your hosting platform.
  • As of this writing there were no public reports of active exploitation. Even so, one flaw has remote code execution potential: do not leave it for the next sprint.

The 10 fixed flaws

CVESeverityLinesWhat it is
CVE-2026-111497High26, 24, 22Out-of-bounds write in the Brotli decoder, with possible remote code execution
CVE-2026-105483High26, 24TLS certificate hostname check bypassed with an IP written in full-width digits
CVE-2026-106069High26, 24, 22TLS certificate hostname check bypassed when the host loosely resolves to an IP
CVE-2026-105482High26, 24, 22dns.resolve truncates names containing a NUL character
CVE-2026-105481Medium26, 24, 22Keep-alive socket processes a response written before the request was sent
CVE-2026-106072Medium26, 24, 22Non-canonical IPv4 addresses let a domain certificate authenticate an IP
CVE-2026-106074Medium26, 24, 22crypto.randomUUID() and randomInt() repeat values in startup snapshots and single executable applications (SEA)
CVE-2026-106070Low26ZipFile returns attacker-controlled bytes after failed header validation
CVE-2026-106071Low26Permission Model grants more file access than allowed through wildcards
CVE-2026-106073Low26, 24, 22Permission Model bypass with fs.realpathSync

The releases also update internal dependencies: OpenSSL 3.5.9 (lines 24 and 22), undici 7.30.1, c-ares 1.34.9, the NSS root certificates, the blocking of a compromised eMudhra intermediate CA and, on line 22, SQLite.

What to prioritize

1. Brotli: any application that decompresses content

Brotli is the br compression format, widely used on the web. The decoder bundled with Node powers the zlib module (brotliDecompress, createBrotliDecompress) and, in turn, libraries and HTTP clients that decompress responses with Content-Encoding: br.

The official notice does not detail the exploitation conditions, but the risk is highest for anything that processes compressed content coming from outside: proxies and gateways, crawlers and scrapers, services consuming third-party APIs, compressed uploads and webhooks. Those servers should go first.

2. TLS: certificates validated for the wrong destination

Three flaws (CVE-2026-105483, CVE-2026-106069 and CVE-2026-106072) affect the check that confirms a certificate really belongs to the server you called. The common thread is IP addresses written in unusual formats, such as full-width digits (１２７.０.０.１) or non-canonical IPv4. The fix makes Node reject those formats.

The risk shows up when the destination of an HTTPS connection comes from outside: user-supplied URLs, configurable webhooks, integrations where the customer chooses the endpoint. In those cases, an attacker in a position to intercept traffic may present a certificate that should not be accepted.

3. DNS and keep-alive

With CVE-2026-105482, a name containing a NUL character was truncated in dns.resolve: your code validated one name and Node looked up another. That can slip past domain allowlists and SSRF protections. CVE-2026-105481 affects reused HTTP connections (keep-alive), where a response sent too early could be tied to the next request.

4. Repeated random values in snapshots and SEA

If you use startup snapshots or package the app as a Single Executable Application, the randomness cache of crypto.randomUUID() and crypto.randomInt() was saved into the snapshot, and every process generated the same sequence. Tokens, session IDs and codes generated by those processes may have repeated. After updating, rebuild snapshots and executables and assess whether anything generated before needs to be invalidated.

How to update

Find the version in use

node -v

# in production, check the process that is actually running
node -p "process.version"     # inside the container or server
docker run --rm your-image node -v

Development machine and server

# nvm (Linux/macOS) or nvm-windows
nvm install 24.22.1
nvm alias default 24.22.1

# fnm
fnm install 24.22.1 && fnm default 24.22.1

# Debian/Ubuntu with the NodeSource repository
sudo apt update && sudo apt install --only-upgrade nodejs

After updating the binary, restart the processes (PM2, systemd, Supervisor): the old process keeps running the vulnerable version until it is restarted.

pm2 reload all
# or
sudo systemctl restart my-api

Docker

Tags such as node:24-alpine point to the new version, but your image only changes when it is rebuilt without cache. For reproducible builds, pin the patched version:

# Dockerfile
FROM node:24.22.1-alpine

# rebuild without reusing the old layer
docker build --pull --no-cache -t my-api .

CI and project

Update the version in the pipeline and, if you want to stop anyone from running a vulnerable version, declare the minimum in the project:

# .github/workflows/*.yml
- uses: actions/setup-node@v4
  with:
    node-version: 24.22.1

# .nvmrc
24.22.1

// package.json
"engines": { "node": ">=24.22.1" }

Hosting and serverless

On managed platforms (Vercel, Netlify, AWS Lambda, Azure App Service, Google Cloud Run and similar), the provider updates the runtime, usually with nothing more than a new deploy on your side. Check the docs or dashboard for the patch version in use and redeploy to make sure functions start on the new runtime.

Still on Node.js 20 or older?

Node.js 20 reached end of life in April 2026, and unsupported versions are always affected by announced flaws, with no fix. The project itself advises moving to a supported line; for those who cannot migrate now, paid commercial support is available through the OpenJS sustainability program.

Moving from 20 to 22 or 24 is usually smooth for web applications, but you need to test native dependencies (such as bcrypt, sharp and database drivers) and check deprecation warnings.

Checklist

  • List where Node.js runs: servers, containers, serverless functions, CI and the team's machines
  • Update to 26.12.1, 24.22.1 or 22.23.4
  • Restart processes and rebuild Docker images without cache
  • Prioritize services that decompress external content or make HTTPS calls to user-supplied destinations
  • Rebuild startup snapshots and SEA executables and review tokens generated by them
  • Plan the move off Node.js 20 or older

Sources

Need help?

Updating Node.js is simple on one machine and laborious across a fleet of servers, containers and pipelines. If you need help updating without stopping operations or migrating off Node.js 20, talk to us. And if you would rather leave this kind of maintenance to whoever runs the server, see CPW hosting.