Node.js Security Release October 2026: Brotli RCE, TLS Bypasses, and How to Upgrade

The Node.js October 2026 security release shipped on Wednesday, October 21, 2026, for the 26.x, 24.x, and 22.x release lines. It fixes 10 CVEs: four High, three Medium, and three Low. The release also updates bundled dependencies, including c-ares, OpenSSL, SQLite, Undici, and the root certificate store. The most serious issue, CVE-2026-111497, is an out-of-bounds write in the bundled Brotli decoder that can permit remote code execution when Node.js decompresses hostile data.

This article was created with AI assistance. Facts were checked against the official Node.js security release announcement and release schedule on October 23, 2026. Always confirm details in the official advisory before acting.

TL;DR: which Node.js version to install

The Node.js project notes that end-of-life versions are always affected when a security release occurs. If you are on Node.js 20, these fixes will never reach you; upgrade to a supported line.

All 10 Node.js CVEs fixed in the October 2026 release

Bundled dependency updates in this release: c-ares (all lines), Undici (all lines), the CA certificate store after the eMudhra intermediate CA compromise (all lines), OpenSSL (24.x and 22.x), and SQLite (22.x).

Who is most at risk

Brotli remote code execution (CVE-2026-111497)

Any code path that decompresses untrusted Brotli data can reach the vulnerable decoder. You do not have to call the Brotli API directly:

• Servers that accept compressed request bodies. Body parsers that honor Content-Encoding: br decompress attacker-supplied data before your handler runs. The body-parser 2.x package used by Express 5 supports Brotli request bodies, so check whether your API accepts them.
• Outbound HTTP clients. The built-in fetch() decodes Brotli-encoded responses. Services that fetch URLs supplied by users or third parties are exposed: webhooks, link previews, importers, crawlers, and integrations.
• Direct zlib use. zlib.createBrotliDecompress() or zlib.brotliDecompressSync() on uploaded or downloaded data.
• WebSocket and streaming code that inflates compressed payloads from clients.

Internet-facing APIs and any service that downloads content from untrusted hosts should be first in line.

TLS hostname bypasses (CVE-2026-105483, CVE-2026-106069, CVE-2026-106072)

These weaken certificate hostname checks when Node.js connects over TLS, particularly to IP addresses or hostnames written in unusual forms. They matter most for services that make outbound HTTPS calls to configurable endpoints, use mutual TLS between services, or connect to internal services by IP address. A successful bypass can let an attacker who controls the network path impersonate the server.

DNS NUL truncation (CVE-2026-105482)

When dns.resolve truncates a name at a NUL character, the hostname your SSRF filter approved may differ from the one that is actually resolved. If your application validates user-supplied URLs before fetching them, an attacker may slip past an allow or deny list. This is why SSRF defenses should validate the resolved IP address, not only the hostname string.

Medium and Low issues

• Keep-alive response ordering (CVE-2026-105481) affects HTTP clients reusing sockets and can cause responses to be attributed to the wrong request.
• randomUUID entropy reuse (CVE-2026-106074) affects applications built with startup snapshots or as single executable applications: UUIDs could repeat across instances started from the same snapshot.
• Permission Model and ZipFile issues affect applications using the experimental Permission Model or the new ZIP APIs.

Supported and end-of-life Node.js versions

According to the Node.js release schedule as of October 2026, Node.js 22 and 24 are LTS, Node.js 26 is Current, and Node.js 20 and 25 are end of life. Starting with Node.js 27, the project moves to an annual release cycle in which every major version becomes LTS. For production, choose an LTS line and plan upgrades before end of life rather than during an emergency.

Check which Node.js versions you run

# Runtime version
node -v

# Bundled component versions (OpenSSL, Undici, Brotli, c-ares, etc.)
node -p "process.versions"

# Node versions inside running containers
docker ps --format '{{.Names}}' | xargs -I{} sh -c 'echo "{}: $(docker exec {} node -v 2>/dev/null)"'

# Kubernetes images that bundle Node.js
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u | grep -i node

Also inventory places where Node.js hides: CI runners and build images, serverless functions, Electron or other desktop apps that embed Node.js (these need a vendor update), and developer tooling pinned through .nvmrc, .node-version, Volta, or the engines field.

Interim mitigations if you cannot upgrade today

Upgrading is the fix. If a rollout takes time, reduce exposure in the meantime:

• Reject Brotli request bodies at the edge for APIs that do not need them. In nginx, for example:

  # Temporary: refuse Brotli-encoded request bodies
  if ($http_content_encoding ~* "br") {
      return 415;
  }

  See our nginx security update guide for upgrading the proxy itself.
• Turn off request-body decompression where you do not need it. body-parser supports inflate: false, for example express.json({ inflate: false }), which rejects compressed bodies.
• Restrict outbound fetches. Limit services that fetch untrusted URLs to an egress allow list, and route them through a proxy that can strip or refuse Brotli-encoded responses.
• Harden SSRF validation. Reject hostnames containing control characters and validate the resolved IP address before connecting.
• Prefer hostnames over IP addresses for TLS connections between services until patched, and pin certificates for high-value internal calls.

Node.js upgrade paths by setup

Docker: official Node.js images

Official node images (for example node:24, node:22-alpine, node:24-bookworm-slim) are rebuilt for each release. Rebuild your images so they pick up the new base layer:

docker build --pull --no-cache -t registry.example.com/api:node-sec-2026-10 .
docker run --rm registry.example.com/api:node-sec-2026-10 node -v   # expect v24.22.1, v22.23.4, or v26.12.1

• Update exact tags such as node:22.23.3-alpine or pinned digests.
• Update every stage of multi-stage builds, including build stages.
• Native add-ons rebuild with the image; patch releases within a line keep the same ABI.

Linux servers: NodeSource, distribution packages, and binaries

• NodeSource repositories: run sudo apt-get update && sudo apt-get install --only-upgrade nodejs (or sudo dnf upgrade nodejs) once the new packages are published.
• Distribution packages (Debian, Ubuntu, RHEL AppStream, Alpine) follow their vendor’s security advisories and may backport fixes with different version numbers.
• Official binaries: download the new tarball from nodejs.org, verify the SHASUMS256 signature, unpack it next to the old version, and switch your symlink or service unit.

Version managers and developer machines

nvm install 24 && nvm alias default 24      # nvm
fnm install 24 && fnm default 24             # fnm
volta install node@24                          # Volta
brew upgrade node                              # Homebrew

CI pipelines

actions/setup-node with node-version: 22 or 24 resolves the newest patch on each run. If you pin exact versions in .nvmrc, .node-version, package.json volta, or CI configuration, bump them and clear runner caches that hold old toolchains.

Kubernetes

Roll the rebuilt image with a standard rolling update: readiness probes on a real endpoint, maxUnavailable: 0, a PodDisruptionBudget, and graceful shutdown on SIGTERM. Do not forget CronJobs, queue consumers, and sidecars written in Node.js.

Serverless and PaaS

• AWS Lambda managed runtimes (nodejs22.x, nodejs24.x) receive runtime patches from AWS. If you pinned a runtime version with runtime management controls, update it; container-image functions must be rebuilt and redeployed.
• Other platforms such as Vercel, Netlify, Render, Heroku, or Cloud Run: check the provider’s status page, and redeploy so new builds use the patched runtime.

Dependencies you install from npm

The Node.js release updates the copy of Undici bundled with Node.js. If your project also installs undici from npm, update that package separately and run npm audit (or pnpm audit or yarn npm audit) to catch other advisories. For broader dependency hygiene, see how to mitigate npm supply chain attacks.

Zero-downtime Node.js rollout

• Handle SIGTERM gracefully. Stop accepting connections with server.close(), finish in-flight requests, then exit.
• PM2 cluster mode: after switching the Node.js binary, pm2 reload all restarts workers one at a time. Note that PM2 itself runs on Node.js; run pm2 update so the PM2 daemon also moves to the new version.
• systemd behind a load balancer: drain one instance, restart it, check health, and return it to rotation.
• Canary first. Ship to one instance or a small percentage of pods, watch error rates and latency, then finish the rollout.
• Keep rollback ready: keep the previous image digest or binary until the new version has run cleanly under production traffic.

Verify the Node.js upgrade

1. Confirm node -v reports v26.12.1, v24.22.1, or v22.23.4 (or your vendor’s patched build) on every host, image, and function.
2. Check that no long-running process still uses the old binary: restart workers, schedulers, and PM2 daemons, and compare process start times with your upgrade time.
3. Run your test suite and smoke tests, paying attention to outbound TLS connections and compressed responses.
4. Re-run your container and dependency scanners so your inventory shows the new versions.
5. Remove temporary mitigations only after every instance is patched.

How DAST tools help you catch these issues sooner

No scanner can predict an undisclosed bug in the Node.js runtime, and upgrading is the only fix for these CVEs. But attackers rarely use a runtime bug alone. They look for an application path that feeds it attacker-controlled input: an endpoint that fetches any URL, a parser that accepts any encoding, or a header that reveals your stack. Dynamic application security testing finds those paths from the outside, the way an attacker would.

DastPilot scans your APIs from an OpenAPI spec or Postman collection, as every role you configure. The checks most relevant to this release:

• SSRF probes on parameters that accept URLs, including webhook-style callbacks. These are the features that DNS and TLS bypasses like CVE-2026-105482 make more dangerous.
• Stack fingerprinting: flags headers such as X-Powered-By: Express that tell attackers which runtime and framework to target. Disable them with app.disable('x-powered-by').
• Injection and input handling: command, template, SQL, and NoSQL injection, path traversal, and improper input validation that returns server errors.
• Leaky errors and debug surfaces: verbose stack traces and unauthenticated debug or configuration endpoints.
• Authorization: BOLA, BFLA, and token-handling checks that limit what an attacker can reach after a foothold.
• Regression tracking: each scan is compared with the last, so a weakness that returns after an emergency deploy is flagged as reopened.

Run scans on a schedule or in your CI/CD pipeline so these weaknesses are already closed before the next advisory, and rescan staging after a runtime upgrade to confirm behavior is unchanged. DAST complements patching: pair it with dependency and image scanning to know which versions you run.

Frequently asked questions

What Node.js versions fix the October 2026 vulnerabilities?

The patched versions are Node.js v26.12.1, v24.22.1, and v22.23.4, released on October 21, 2026. Node.js 20 and 25 are end of life and do not receive fixes.

What is CVE-2026-111497?

CVE-2026-111497 is a High-severity out-of-bounds write in the Brotli decoder bundled with Node.js that can permit remote code execution when untrusted Brotli-compressed data is decompressed. It affects the 26.x, 24.x, and 22.x lines before the October 2026 patches.

Is my app affected if I never use Brotli directly?

Possibly. Node.js decompresses Brotli data in places such as fetch() responses with Content-Encoding: br, and body parsers that accept Brotli request bodies. Any path that decompresses untrusted data can reach the decoder, so upgrade even if your code never calls the zlib Brotli APIs.

Does Node.js 20 get the October 2026 security fixes?

No. Node.js 20 reached end of life in March 2026, and the Node.js project states that end-of-life versions are always affected by security releases. Upgrade to Node.js 22 or 24 LTS.

How do I upgrade Node.js without downtime?

Rebuild container images or install the new binary, then roll it out gradually: Kubernetes rolling updates with readiness probes, PM2 reload in cluster mode, or draining instances behind a load balancer. Make sure your server handles SIGTERM gracefully so in-flight requests finish.

Can a DAST scanner detect these Node.js vulnerabilities?

A DAST scanner cannot identify which Node.js CVEs apply to you; use your runtime inventory and dependency scanners for that. DAST tools such as DastPilot find the application weaknesses attackers combine with runtime flaws, such as SSRF-prone URL parameters, stack fingerprint headers, injection, and authorization gaps.