Node.js October 2026 Security Release: 10 CVEs, a Brotli RCE and the Versions to Patch Now

On 21 October 2026 the Node.js project shipped security releases for every supported line, fixing ten vulnerabilities. The highest severity is High, and one of the High issues, CVE-2026-111497, is an out-of-bounds write in the Brotli decoder that the project says "permits remote code execution" (Node.js security release).

If your APIs, web apps, backend services, serverless functions or internal tools run on Node.js, plan to update this week, and sooner for internet-facing services. It landed on the same day as the critical PHP2Shell release, so many teams are patching two runtimes at once. Our PHP2Shell guide covers that one.

The fixed versions

| Release line | Update to | | --- | --- | | Node.js 26.x | v26.12.1 or later | | Node.js 24.x | v24.22.1 or later | | Node.js 22.x | v22.23.4 or later | | End-of-life lines | No fix. Move to a supported line |

The project states that "End-of-Life versions are always affected when a security release occurs." Check what you run with `node -v`, and remember Node.js also runs inside Docker base images, serverless runtimes, CI runners and desktop apps built on it.

What was fixed

All ten issues, as listed by the Node.js project (source):

| CVE | Severity | Area | Issue | | --- | --- | --- | --- | | CVE-2026-111497 | High | Brotli decoder | Out-of-bounds write permitting remote code execution | | CVE-2026-105482 | High | `dns` | `dns.resolve` truncates names containing a NUL character | | CVE-2026-105483 | High | TLS | Certificate hostname bypass when an IP is written with fullwidth digits (26.x, 24.x) | | CVE-2026-106069 | High | TLS | Certificate hostname bypass when the host loosely resolves to an IP address | | CVE-2026-105481 | Medium | Keep-alive sockets | Socket processes a response written before the request was sent | | CVE-2026-106072 | Medium | TLS | Non-canonical IPv4 hostnames let DNS SANs authenticate IP endpoints | | CVE-2026-106074 | Medium | `crypto` | `randomUUID()` and `randomInt()` entropy caches saved into startup snapshots and single executable apps, so processes repeat values | | CVE-2026-106070 | Low | ZipFile | Returns attacker-controlled prefix bytes after failed ZIP header validation (26.x) | | CVE-2026-106071 | Low | Permission Model | Filesystem over-grant via wildcard lookup (26.x) | | CVE-2026-106073 | Low | Permission Model | Bypass via `fs.realpathSync` |

The release also updates bundled dependencies: c-ares, the CA certificate store (removing a compromised eMudhra intermediate CA), Undici, OpenSSL on 24.x and 22.x, and SQLite on 22.x.

Which of these matter most for your business

Every Node.js service should be updated, but the order matters when you have many.

**The Brotli RCE comes first.** Remote code execution is the worst outcome, and Brotli is a common compression format on the web. Prioritise services that decompress Brotli data they do not control, such as HTTP responses from third parties, uploaded files, or proxied traffic.

**The TLS fixes matter for anything that talks to other systems.** Three issues let a certificate pass hostname checks it should fail. Payment integrations, internal service-to-service calls and webhooks to partners all rely on those checks to know they are talking to the right server.

**The crypto fix matters if you build snapshots or single executables.** If you package Node.js apps as single executable applications or use startup snapshots, every process could produce the same "random" UUIDs and integers. Anything using them for tokens, identifiers or one-time values should be reviewed after updating.

**The Permission Model fixes matter only if you use it.** If you rely on `--allow-fs-*` flags to sandbox code, update and re-test those restrictions.

The Node Patch Sweep: five steps

This is the sequence we follow when patching Node.js across a client's estate.

• **List every runtime.** Servers, container images (check the `FROM` line in every Dockerfile), serverless functions, CI pipelines and build agents. Output: a list of services with their Node.js line and version.
• **Rank by exposure.** Internet-facing APIs and anything handling Brotli input or outbound TLS first. Output: a patch order.
• **Update and rebuild.** Bump the version in Dockerfiles, `.nvmrc`, `engines` fields and serverless runtime settings, rebuild images rather than patching running containers, and redeploy. Output: every service reporting a fixed version in production.
• **Test what changed.** Run integration tests against payment gateways, partner APIs and internal TLS endpoints, since stricter hostname checks can expose misconfigured certificates that previously passed. Output: green test runs, plus a list of any certificates that need fixing.
• **Close the gaps.** Move anything on an end-of-life line to Node.js 22, 24 or 26, and regenerate snapshots or single executables that embedded old entropy caches. Output: no end-of-life Node.js in production.

Common problems when updating Node.js

• **Pinned base images.** A Dockerfile pinned to an exact older tag will keep building vulnerable images until someone changes it.
• **Serverless defaults.** Cloud function runtimes may need a configuration change or redeploy to pick up the patched version.
• **Stricter TLS.** A partner endpoint with a sloppy certificate may start failing after the update. That is the fix working; the certificate needs correcting, not the check.
• **End-of-life lines.** Moving from an old line to 22.x or later can surface deprecated APIs and native module rebuilds. Plan it, but contain exposure first.

Questions teams are asking

Is this as urgent as the PHP vulnerabilities?

The PHP flaws are rated critical with reports of early attacks. The Node.js release is rated High overall. Both need patching promptly; the Node.js update is usually easier because it is a minor version bump within your current line.

Will updating break my application?

These are patch releases within each line, so breaking changes are unlikely. The most likely visible change is stricter TLS hostname validation, which is intentional.

We use a managed platform. Do we need to do anything?

Check whether your platform updates Node.js automatically or requires you to select a new runtime version and redeploy. Do not assume it has happened.

We are still on an old Node.js version. What now?

End-of-life versions receive no fixes. Contain exposure where you can, then plan an upgrade to a supported line as a priority project.

Hand your Node.js patching to us

Running a Node.js application that was built years ago and has not been updated since? Unmaintained services on old release lines are the ones these fixes never reach, and bringing them back under regular maintenance is work we do every week.

If your team is stretched, or you are not sure every service and container is covered, Moweb can take the patching work off your plate. Our Node.js engineers will inventory your runtimes, update and rebuild every service in priority order, test your integrations, fix any TLS or compatibility issues the update exposes, and plan upgrades for anything on an end-of-life line. Our processes are certified to ISO 27001 (our security approach).

Get your Node.js services patched. Tell us how many services you run and where they are hosted, and an engineer will get back to you as fast as possible. For ongoing maintenance, see our cloud and DevOps services and web application development.