CISA listed CVE-2026-111497 as exploited on 27 October 2026 (catalog). Treat that as a patch priority, not as a diagnosis that your website has been compromised.

What the Node.js notice says

The Node.js October 2026 security notice states that the flaw affects Node.js 22.x, 24.x and 26.x before the fixed releases below. It applies when an application decompresses attacker-supplied Brotli data with node:zlib. Malformed input can corrupt process memory, which may lead to a crash, memory disclosure or code execution. End-of-life lines count as affected, and no vendor workaround is offered.

Node.js lineFixed security release (21 October 2026)
22.x22.23.4
24.x24.22.1
26.x26.12.1

These are the 21 October fixes, not new patches. Install the current supported patched release in your line, or follow the vendor-supported migration path if your line is end-of-life. Never downgrade a newer patched runtime to match the table.

Who is actually in scope

This checklist covers one path: a Node.js runtime whose application decodes untrusted Brotli data with node:zlib. Both conditions matter. Ask whether your backend, API, background worker or any supporting service runs Node. Then have the developer or provider trace whether that code decompresses Brotli input from outside the system. Brotli compression for outgoing responses at a CDN or edge does not, by itself, establish exposure. Other products can bundle Brotli too. If your site runs on WordPress, PHP or another stack, ask your provider which components may include it, and check those vendors’ own notices. This article does not verify them.

Owner and provider checklist

  1. Record each Node.js process location, exact running version, source image or build, and the named patch owner.
  2. Treat this as a runtime fix. A CMS or npm dependency update does not replace the Node.js release.
  3. On a managed platform, ask who updates the runtime or base image and what evidence you will receive. Scope differs between hosts.
  4. Before an authorized rollout, confirm a current backup, a tested restore and a fallback plan. Our backup rules describe what a usable restore looks like.
  5. Test on staging and run the key flows first.
  6. Rebuild or redeploy images or services as your platform requires, then confirm the version the running process reports on every relevant instance after activation. An installer or lockfile is not proof.
  7. Record the checked version and the deployment date.
  8. Verify important website, API, form and worker functions with synthetic data and no live charges, then watch error rates. Monitoring beyond uptime covers what to watch.

If something looks wrong

Preserve the logs you have and request a qualified review. The update addresses this listed weakness. It does not review or undo access that may have happened earlier, so treat that review as a separate task.

Checked as of 30 October 2026.