Node.js Security Release Fixes a Brotli RCE Flaw: What Headless Sites, CI and Containers Should Update

The October 2026 node.js security release fixes 10 vulnerabilities, and the most serious is a Brotli decoder bug that Node.js says "permits remote code execution." Per Node.js’s October 21 security advisory, the fixes shipped that day in Node.js 22.23.4, 24.22.1 and 26.12.1. Node.js 20 is end of life and gets no fix.

This piece covers what each CVE in the Node.js security release is, who among headless, build and serverless teams is exposed, and what Vercel, Netlify and Pantheon say about their runtimes. It also covers Docker images and how to check the Node.js version you run. Facts are as of the evening of October 22, 2026.

The short version: upgrade every Node.js you control to 22.23.4, 24.22.1 or 26.12.1. That means front-end servers, build servers, CI runners, containers and laptops. On a managed platform, confirm the platform has rolled the patch, and redeploy if its docs say to. Anything still on Node.js 20 needs a major upgrade.

What the October 2026 Node.js security release fixes

The Node.js security advisory lists ten CVEs: four rated high, three medium and three low. The highest severity in each supported line is high. The advisory gives severity labels only, with no CVSS scores.

The dates come from the nodejs/Release schedule, which notes that dates are subject to change. The advisory says the release also updates bundled dependencies: c-ares and Undici on all three lines, OpenSSL on 22 and 24, and SQLite on 22. It also updates the bundled CA certificates after the eMudhra intermediate CA compromise.

Every CVE in the Node.js security release

Here is the full list from the advisory, which gives one line per issue.

The Permission Model issues matter only if you run Node.js with that sandbox turned on. Most web front ends do not.

The Brotli flaw, CVE-2026-111497

Brotli is a compression format. Browsers and servers use it to shrink web responses. Node.js bundles Google’s Brotli decoder, and the three release posts list the fix as a cherry-pick into that bundled copy.

An out-of-bounds write means the decoder writes outside the memory it was given. Vercel’s Node.js bulletin says malformed Brotli input triggers it, and sets out who is exposed. An app is at risk only if its code, or a library it uses, decompresses attacker-controlled Brotli data. That data can arrive in a request body or in a response fetched from another server. Vercel notes that Node.js does not decode Brotli data on its own. The Hacker News reported that this covers direct use of node:zlib and fetch() calls that receive Brotli-compressed responses.

The Brotli fix in this Node.js security release comes from upstream. The google/brotli releases page lists Brotli 1.2.1, 1.1.1 and 1.0.10, released October 21, each noting CVE-2026-111497. Other software that bundles Brotli may need its own update.

The Node.js advisory credits OpenAI Codex Security, naming Khai Tran and Sylvie Mayer, as the reporter. OpenAI describes Codex Security as an AI application security agent. The PHP2Shell site also credits OpenAI Codex Security for this week’s PHP flaws.

The Node.js advisory says nothing on exploitation. Vercel says researchers demonstrated process-memory disclosure and command execution in the Node.js process on unpatched 22.x, 24.x and 26.x. The Hacker News reported on October 22 that a public proof of concept had appeared. Its author reached code execution only on a deliberately weakened build. On a standard build, the author reported a crash and a limited memory read. The outlet said no exploitation in the wild had been reported as of October 22.

Who is affected among headless, build and serverless teams

Headless and decoupled front ends. A headless CMS setup with a Next.js, Nuxt or Gatsby front end runs Node.js on the server that renders pages. Server-rendered and API routes that accept uploads or proxy other services are the likely exposure points. Vercel’s bulletin says self-hosted Next.js does not block Brotli responses in image optimization, so upgrading Node.js is the fix there.

Build servers and CI. Static builds fetch content and packages over the network. Your own CMS is a trusted source, but third-party feeds and remote images are less so. Build machines often hold deploy keys, which our npm supply chain post covers.

Serverless functions. A function that calls fetch() on outside URLs or unpacks uploaded files fits the exposure pattern Vercel describes. On managed platforms, check the provider’s own notice for whether it patches the runtime or you must redeploy.

The TLS fixes. Going by the advisory’s titles, the three hostname-check flaws affect code that makes HTTPS calls to IP addresses or loosely formed hostnames. Webhooks and internal service calls are good places to check.

Teams that moved some work to Deno or Cloudflare Workers should check those runtimes’ own notices. This advisory covers Node.js only. See our Deno and Cloudflare post.

What Vercel, Netlify and Pantheon say about the Node.js security release

Here is what each platform’s own docs or notices said on the evening of October 22.

Vercel. Its bulletin says it deployed WAF rules on October 21 that block the inbound attack for every project, at no cost. It says it is "rolling the patched Node.js versions across Vercel’s managed runtimes" and will update the page when done. Projects on 22.x or 24.x "do not need to change their version setting." Projects on 20.x must switch to 22.x or 24.x and redeploy. The WAF does not cover responses your functions fetch from other servers. Our Vercel Functions guide explains which runtime your code uses.

Netlify. Its changelog had no entry on this release when we checked. For a January 2026 Node.js flaw, Netlify’s changelog said deployed Functions would be patched "automatically on a rolling basis" and build-time Node.js would not. Netlify’s build docs say a site is pinned to its build image’s default version. A NODE_VERSION variable, .node-version or .nvmrc file set to a major number such as 22 gets the latest 22.x.

Pantheon front-end sites. Pantheon’s Next.js docs say it provides "the latest 3 LTS versions of Node.js" and picks one from the engines field in package.json. The docs do not say whether patch updates apply automatically. Its release notes had no Node.js security entry as of October 22. A June 22, 2026 note says Node.js 20 "is no longer available as a runtime." Ask Pantheon support which patch version your front end runs.

Docker node images and containers

The official node image on Docker Hub already lists tags with the Node.js security release fixes: 26.12.1, 24.22.1 and 22.23.4, in Alpine, Debian bookworm, trixie and slim variants. The lts tag points to 24.22.1, and current and latest point to 26.12.1. No 20.x tag appears in the supported list.

Restarting a running container does not patch it. Vercel’s bulletin says to rebuild container images on a patched base image and redeploy. Use docker build --pull so the new base image is fetched, then run node -v inside the new container. If your Dockerfile pins a full version such as node:22.20.0, change the tag. Our containers explainer covers how images and tags relate.

Node.js 20 is already end of life

Node.js 20 reached end of life on April 30, 2026, per the release schedule. The Node.js previous releases page shows its last update on March 24, 2026. The advisory says "End-of-Life versions are always affected when a security release occurs." This Node.js security release has no upstream fix for 20.x.

Moving from 20 to 22 or 24 is a major upgrade, so test it on a branch first. Node.js 22 itself reaches end of life on April 30, 2027, so 24 gives you more runway. Our Node.js release model post explains how the project is changing the way it picks LTS lines.

How to check which Node.js version you run

The Node.js that serves your site can differ from the one on your laptop.

1. Command line. Run node -v on the server, in the CI job log and inside the container. You want v22.23.4, v24.22.1, v26.12.1 or later.
2. Version files. Look for .nvmrc or .node-version in the repo. A full pinned version will not move on its own.
3. The engines field. Check engines.node in package.json. Vercel and Pantheon read it.
4. CI settings. In GitHub Actions, check node-version or node-version-file in actions/setup-node. Its README says it checks the runner’s local cache first. Set check-latest: true to pull the newest release in your range.
5. Platform settings. Vercel lists the Node.js version in project settings. Netlify uses its dependency management screen or NODE_VERSION.

Frequently Asked Questions