Node.js Brotli CVE-2026-111497: How to Patch Servers, Images and Apps

CVE-2026-111497 is an out-of-bounds write in the Brotli decoder bundled with Node.js, which the Node.js project rates High and says "permits remote code execution." It affects the 22.x, 24.x and 26.x lines, and end-of-life lines such as 20.x get no fix. Upgrade to 22.23.4, 24.22.1 or 26.12.1, then rebuild every image and app that ships Node.

The fix shipped on 21 October 2026 as part of a security release that closed ten CVEs. As of 22 October, neither Node.js nor Vercel reports exploitation in the wild, and Node.js has published no CVSS score or technical write-up. That leaves a short window to find every copy of the runtime you own. The hard part is not the upgrade command. It is that Node hides in base images, serverless runtimes, desktop apps and single binaries that nobody lists as "a Node server."

What happened

The facts from the Node.js advisory

Node's post is short. Here is everything it says about this CVE, plus what the release notes add.

The same release also updated the bundled root certificates to NSS 3.131.1 and carried a CA certificate change that Node's post labels "eMudhra Intermediate CA Compromise." If you were already planning a Node upgrade for that reason, our post on trust store updates in Python, Node, Go and Electron after eMudhra covers the certificate side. One upgrade handles both.

Where sources differ

• Impact detail. Node.js says the flaw permits remote code execution and stops there. Vercel's bulletin goes further, saying researchers "demonstrated process-memory disclosure and command execution" on unpatched versions. That claim is Vercel's, not Node's.
• Scoring. Node.js gave a High rating with no CVSS score. Secondary coverage, including Cyber Kendra, notes the absence of scores for all ten issues. Treat any number you see quoted elsewhere with care until the CVE record is published.
• Exploitation. Neither Node.js nor Vercel reports attacks in the wild. A Japanese roundup by Jinrai, updated 17:00 JST on 22 October, says it found no attack code and no reports of exploitation. Absence of reports is not proof of absence.

Technical details

Every value below comes from the source named next to it. Node.js has not published the vulnerable code path or a proof of concept, and neither do we.

Identifiers and scores

Affected and fixed versions per line

Release times are the published_at values from GitHub's API for the nodejs/node release tags.

The fix, by commit

Node.js applied the same upstream Brotli change to every line. The release notes list it as deps: brotli: cherry-pick 0ed4268a4401abcb44720963 (author shown as Evgenii Kliuchnikov), from the private pull request nodejs-private/node-private#1002, alongside a second commit titled src: expose `BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH` .

The pull request is in Node's private security repository, so there is no public PR page to link.

Affected component and APIs

The advisory names the component, the Brotli decoder, and does not name individual functions. Node's zlib documentation lists these Brotli decompression entry points, all of which use that decoder:

Code that calls none of these directly can still reach the decoder through libraries, or through fetch(), which NVD's record for CVE-2024-22025 says always decodes Brotli responses.

Verified downloads

If you install from nodejs.org tarballs, check them against the signed SHASUMS256.txt for each release. Selected values:

curl -fsSLO https://nodejs.org/dist/v24.22.1/SHASUMS256.txt
sha256sum -c SHASUMS256.txt --ignore-missing

Docker Official Image tags that carry the fix

From the Docker Hub tag listing for library/node (times UTC):

The moving tags lts, lts-alpine, krypton, jod, current and latest were updated at about 02:41 UTC on 22 October. Images built from 24.22.0 or 22.23.3 tags, including ones pushed on 21 October before the fix, are still affected.

Indicators of compromise

Neither Node.js nor Vercel has published indicators of compromise, such as IP addresses, domains, hashes or request signatures. Vercel says requests blocked by its WAF rules appear in each project's Firewall dashboard, which is the only detection signal either source offers. A crash in a process that decodes Brotli from untrusted input is worth investigating, but it is not a published indicator.

How it works, in plain language

Brotli is a compression format, widely used for HTTP responses with Content-Encoding: br. Node.js bundles a copy of Google's Brotli library and exposes it through the zlib module. Decoding Brotli means reading compressed bytes and writing the expanded output into memory buffers.

An out-of-bounds write means that, for some malformed input, the decoder writes past the end of a buffer it owns. In native code that can corrupt memory the process relies on. Depending on what gets overwritten, the result can be a crash, leaked memory, or in the worst case code running with the permissions of the Node process. Node.js classes this one as permitting code execution. It has not published the triggering input, and neither will we.

The important practical question is reachability. Vercel's bulletin makes a point worth repeating: Node.js does not decode Brotli on its own. Your process is exposed when your code, or a library you use, decompresses Brotli data an attacker can influence. Vercel names two routes:

1. Inbound request bodies. Some servers and body parsing middleware decompress a request body when the client sends Content-Encoding: br.
2. Outbound responses. When your app fetches from a server and decodes a Brotli response, the remote server controls the input. Node's built-in fetch() decodes Brotli automatically; NVD's description of an older Node issue, CVE-2024-22025, says plainly that fetch() "always decodes Brotli." Any service that fetches URLs supplied by users (link previews, webhooks, image proxies, scrapers) deserves first attention.

Vercel adds that its WAF can only inspect traffic passing through Vercel, so it does nothing for responses your code fetches from elsewhere. In Vercel's words, only the runtime patch covers that path.

The upstream library matters too

The flaw sits in Brotli itself, and Google released fixed Brotli versions on the same day. Two consequences follow.

• Distribution builds of Node. Some Linux distributions build their nodejs package against the system Brotli library rather than the copy Node bundles. On those systems the fix may arrive through the distro's brotli package as well as, or instead of, a new nodejs package. Follow your distro's advisory rather than assuming.
• Other software. Anything else that embeds the Brotli decoder (other language runtimes, proxies, browsers, native modules) may need its own update. This post covers Node; check your other stacks against the Brotli releases.

Who is affected

The release schedule on the Node.js GitHub lists 22.x in Maintenance LTS and 26.x as Current, due to enter LTS on 28 October 2026. Node's post marks 24.22.1 as the latest LTS.

What to do now

Work from the outside in: find every copy, upgrade the ones exposed to untrusted Brotli first, then rebuild and redeploy everything else.

1. Check servers and developer machines

node -v
node -p "process.versions.node"
which -a node          # more than one result means more than one runtime

Node applied the fix as a cherry-pick, so do not use process.versions.brotli as your test. Check the Node version.

Upgrade according to how Node was installed:

# nvm
nvm install 24.22.1 && nvm alias default 24.22.1

# fnm
fnm install 24.22.1 && fnm default 24.22.1

# Volta
volta install node@24.22.1

# Homebrew (macOS)
brew update && brew upgrade node

# Debian or Ubuntu packages
apt-cache policy nodejs
dpkg -l | grep -i -E 'nodejs|brotli'

# RHEL, Fedora and derivatives
rpm -q nodejs brotli

For distro packages, wait for and apply your vendor's update; package names and version strings differ from upstream. After upgrading, restart every Node process. A running process keeps the old runtime in memory until it exits.

systemctl restart my-node-service
pm2 reload all

For a fleet, run the same check everywhere and collect the output, for example with Ansible:

ansible all -m command -a "node -v"

2. Rebuild Docker images

The official node tags for 22.23.4, 24.22.1 and 26.12.1 are on Docker Hub. Moving tags such as node:24, node:lts and node:24-alpine now point at fixed builds. That only helps if you rebuild.

# Find base images in your repos
grep -rn --include='Dockerfile*' -E '^FROM\s+node' .

# Confirm what a tag contains today
docker run --rm node:24-bookworm-slim node -v

# Check what an image you already built contains
docker run --rm --entrypoint node myapp:current -v

# Rebuild without cached layers, pulling the newest base
docker build --pull --no-cache -t myapp:patched .

Pin the exact fixed version so a stale cache cannot hand you the old one:

FROM node:24.22.1-bookworm-slim

If you pin by digest, update the digest; an old digest will never change. Then check running containers and Kubernetes pods, since an image in the registry and the image in production are often different:

docker ps --format '{{.Names}}\t{{.Image}}'
docker exec my-container node -v

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' | grep -i node
kubectl exec -n my-namespace my-pod -- node -v

Remember images that do not say "node" in the name: a Python or Go image with Node installed for a build step, a frontend image that runs a Node server for server-side rendering, or a CI image.

3. Serverless and managed platforms

What platforms said, as of 22 October:

For Lambda, find your Node functions and check their update mode:

aws lambda list-functions \
  --query "Functions[?starts_with(Runtime, 'nodejs')].[FunctionName,Runtime]" \
  --output table

aws lambda get-runtime-management-config --function-name my-function

Functions in Function update mode only pick up a new runtime version when you deploy them, and Manual mode never does. Container image functions need a rebuild on a fixed base image. To see the Node version a function actually runs, log process.version from inside the handler. If you still run nodejs20.x, move to nodejs22.x or nodejs24.x; a platform cannot patch a runtime that upstream no longer fixes.

For Vercel, set the Node version in project settings or in package.json:

{
  "engines": { "node": "24.x" }
}

For platforms that use the version you specify (Render, Netlify builds, Heroku), set an exact fixed version or a range that resolves to one, then redeploy.

4. CI pipelines

CI runners run Node too, and often fetch from the internet. With GitHub Actions, actions/setup-node can serve a cached older patch release; ask for the newest one:

- uses: actions/setup-node@v4
  with:
    node-version: 24
    check-latest: true

Check .nvmrc, .node-version and .tool-versions files in your repos, and update any that pin an affected patch release.

5. Electron apps

Electron ships its own Node inside every app. Updating Node on your machine does nothing for an Electron app you build or install.

npm ls electron            # which Electron your app depends on
npx electron --version     # the installed Electron version

Electron's release index lists the Node version each release bundles. As of 22 October, the newest stable releases (45.0.0 and 44.9.3, both dated 21 October) list Node 24.22.0, and the 44.9.3 release notes do not mention Brotli or this CVE. Electron sometimes backports fixes without changing the reported Node version, so the number alone does not settle it either way. Watch Electron's releases and security advisories for an entry naming CVE-2026-111497, then:

1. Bump Electron in package.json to the release that carries the fix.
2. Rebuild and re-sign your app.
3. Ship it through your auto-update channel, and track how many users have actually updated.

Electron apps also embed Chromium, which carries its own copy of Brotli for web content. We found no Chromium advisory referencing this CVE as of 22 October; do not assume either way.

6. Single binaries and embedded Node

Single executable applications, packaged CLIs and appliances that bundle a Node binary keep the version they were built with. Rebuild them with a fixed Node and redistribute. The same release fixed a separate issue (CVE-2026-106074) about random number caches saved into startup snapshots and single executable apps, which is another reason to rebuild those now.

7. If you cannot upgrade today

Node.js lists no workaround. As a stopgap, not a fix:

• Find the code paths that decode Brotli from untrusted sources and prioritise those services for patching.
• At your reverse proxy, consider rejecting inbound request bodies with Content-Encoding: br if your app does not need them. This does nothing for responses your app fetches.
• For services that fetch user-supplied URLs, restrict where they can connect while you patch.
• If you are on Vercel, its WAF rules cover traffic through Vercel only, and Vercel says the WAF "reduces exposure but does not replace patching."

What would have helped

Nothing here would have stopped a memory safety bug in a compression library. What decides the impact is how fast you can find and replace the runtime. These practices make that fast.

1. Treat the runtime as a dependency. Most teams track node_modules carefully and the node binary not at all. Record the runtime version in your SBOMs and inventory, for images, hosts and desktop apps. Check that your SBOM tool records the Node runtime itself and not only npm packages.
2. Know which services decode untrusted input. Keep a short list of services that fetch arbitrary URLs or accept compressed uploads. When a decoder bug lands, those go first.
3. Rebuild base images on a schedule and on demand. A pipeline that rebuilds from node:24-slim nightly and redeploys on green tests turns a runtime CVE into a routine change. Automated base image update tools that open pull requests when a new tag appears shorten the gap further.
4. Pin exact versions, update them automatically. Pinning node:24.22.1-bookworm-slim makes builds reproducible; an update bot keeps the pin fresh. Floating tags without rebuilds give you the worst of both.
5. Stay on supported lines. Node 20 users have no fix to install. A policy that moves services off a line before its end of life date avoids being stuck in exactly this position.
6. Know your platform's patch model. On managed runtimes, the platform patches for you only in some modes. Write down, per platform, whether patches arrive automatically, on deploy or never.
7. Plan for desktop and embedded copies. Electron apps and single binaries need a release and an update on every user's machine. Measure update uptake, not just release dates.

We wrote the same pattern up for PHP in finding and patching every PHP runtime after PHP2Shell; the commands differ, the inventory problem is the same.

Where Safeguard fits

Safeguard does not patch your Node runtime, change platform settings for you, or ship Electron updates to your users. Those steps are yours. Here is where it helps.

• Inventory images and repos. safeguard scan --image scans a container image, safeguard scan --dir . scans a repository and safeguard scan --sbom scans an SBOM file, with JSON results under ./output. Scan the images you build on node bases to see their components. Whether this Node advisory is matched depends on the vulnerability data and on the runtime being identified in the image, so still confirm with node -v as shown above.
• Find every project with a component. The platform shows which projects contain a given component and version. That is the query you need after any runtime or library advisory; our post on SBOMs in incident response walks through it.
• Prioritise. Vulnerability matching against vulnerability databases, with reachability analysis, helps separate exposed services from the long tail.
• Gate rebuilds. Policies and gates evaluated in the platform, and safeguard exec in CI, can block a build that still pulls a known vulnerable component.
• Do the change work with approval. The Safeguard CLI's assistant can edit files and run commands with your approval. Ask it to bump FROM lines to the fixed tags, update .nvmrc and engines.node, rebuild and run tests. Use /permissions set to Ask or Strict so each command waits for you. Autonomous remediation can open fix pull requests, and it is off by default.

Zero-Day Discovery and Gold

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. The Node.js runtime and the C Brotli library inside it are outside that scope, and we make no claim that it found this flaw.
• Gold Open Source at gold.safeguard.sh is free with no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API, and a CI gate GitHub Action. As of 22 October the CVE record for this flaw was not yet in NVD, so check the Node.js advisory directly for now.
• Gold Registry at registry.safeguard.sh is the paid tier: hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses.

The habit they support is the one this incident rewards: pull patched, signed base images and components from a curated source, and rebuild and redeploy quickly when an advisory lands.

Common mistakes

• Upgrading Node on the host and forgetting the containers. Containers carry their own Node. Rebuild them.
• Pulling node:24 without --pull or with a warm cache. Your build may reuse the old base layer. Pin the fixed tag or force a fresh pull.
• Rebuilding but not redeploying. A new image in the registry protects nothing until pods and tasks run it. Check running versions.
• Patching without restarting. Long-running processes keep the old binary in memory.
• Assuming serverless is always patched. Lambda functions in Function update or Manual mode, container image functions, and anything on an end-of-life runtime need action from you.
• Trusting the WAF. Edge rules only see traffic that crosses the edge. Fetched responses never do.
• Forgetting Electron and single binaries. Your laptop's Node version has nothing to do with the Node inside an app you ship.
• Using process.versions.brotli as the check. A cherry-picked fix may not change that string. Check process.versions.node.
• Staying on Node 20 because it "still works." It will not receive this fix.

FAQ

Is CVE-2026-111497 being exploited?

As of 22 October 2026, Node.js does not mention exploitation and Vercel describes researcher demonstrations only, with no claim of attacks in the wild. Jinrai's roundup found no public attack code. Treat that as a short window rather than reassurance.

Is this remote code execution or denial of service?

Node.js calls it an out-of-bounds write that "permits remote code execution." It has not published a CVSS score or details. Vercel says researchers demonstrated memory disclosure and command execution; that is Vercel's statement, not Node's.

Is my app exposed if it never calls zlib directly?

Possibly. Libraries and built-in fetch() can decode Brotli for you. Vercel's guidance is that exposure comes from code or libraries that decompress attacker-controlled Brotli, in request bodies or fetched responses. Patch regardless; reachability only tells you what to patch first.

I am on Vercel. Do I need to do anything?

For projects on 22.x or 24.x, Vercel says no version change is needed because it manages patch versions, and its WAF rules are already on. Projects on 20.x must move to 22.x or 24.x and redeploy. Any Node you run outside Vercel's managed runtimes, including self-hosted Next.js, CI and external backends, still needs upgrading.

Does node:lts already include the fix?

Docker Hub shows the lts tag updated early on 22 October (UTC), after the fixed 24.22.1 tags were published. Confirm with docker run --rm node:lts node -v, then rebuild your images; existing images built on the old lts keep the old runtime.

Is Node 20 affected?

Node's post says end-of-life versions are always affected when a security release occurs, and Node 20 reached end of life on 30 April 2026. No 20.x fix is coming. Move to 22.x or 24.x.

Are Electron apps affected?

Electron bundles Node, and the latest stable releases we checked on 22 October list Node 24.22.0. Electron had not published a note naming this CVE when we checked. Watch Electron's releases, then rebuild and ship an update.

Do I need to update the Brotli library separately?

If your Node comes from a distribution package built against the system Brotli library, the distro may fix it through its brotli package. Upstream Node builds bundle their own copy, fixed in the new releases. Other software that embeds Brotli needs its own update.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples; none shows this Node.js incident.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For CVE-2026-111497, the same flow applies to a service repo: ask it to change the FROM node line to 24.22.1, update .nvmrc and engines.node, rebuild the image and run tests, approving each step.

Click through it at your own pace, or open it full screen.

The local runner demo shows setting up the runner on your own machine, approving it with its device code, and scanning from the terminal. After a runtime advisory, that is how you would scan the Node based images you build locally, including private ones, and see what each contains before and after a rebuild.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. For this incident, you would pick an Electron app's folder, ask for the Electron bump once a fixed release is out, and approve the install, build and test commands one by one.

Click through it at your own pace, or open it full screen.

To try it on your own systems, download Safeguard and read the CLI documentation.

Quick check

Sources

• Node.js: Wednesday, October 21, 2026 Security Releases
• Node.js: v24.22.1 release notes
• Node.js: v22.23.4 release notes
• Node.js: v26.12.1 release notes
• Node.js: Security vulnerability posts
• Node.js Release schedule (GitHub)
• Node.js: zlib module documentation
• Node.js: v22.23.4 SHASUMS256.txt
• Node.js: v24.22.1 SHASUMS256.txt
• Node.js: v26.12.1 SHASUMS256.txt
• GitHub: nodejs/node release v22.23.4
• GitHub: nodejs/node release v24.22.1
• GitHub: nodejs/node release v26.12.1
• google/brotli releases
• Vercel: Node.js security advisory: Brotli decoder RCE (CVE-2026-111497)
• AWS Lambda: Understanding how Lambda manages runtime version updates
• Heroku Dev Center changelog
• Docker Hub: node tags (API listing)
• Electron releases index
• Electron v44.9.3 release notes
• NVD API query for CVE-2026-111497
• NVD: CVE-2024-22025
• Jinrai: Node.js vulnerabilities, fixed versions and vendor responses (October 2026)
• Cyber Kendra: Node.js patches Brotli RCE flaw, 9 other vulnerabilities
• Cybersecurity News: Node.js releases security updates

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.