Node.js patches show your runtime is part of your attack surface

What happened

On 21 October 2026, the Node.js Project published a security release covering its three supported lines. The patched versions are v26.12.1, v24.22.1 and v22.23.4. The project says end-of-life versions are also affected, so teams on those need to move to a supported line.

The release fixes ten vulnerabilities. Four are rated high, three medium and three low. It also updates several bundled dependencies, including c-ares, OpenSSL, SQLite and Undici, and a certificate store change for the eMudhra Intermediate CA compromise.

The four high-severity issues are worth reading closely, because they show how ordinary-looking runtime functions can be turned against an application.

• CVE-2026-111497 is an out-of-bounds write in the Brotli decoder in node:zlib. The project says an invalid block switch was treated as a request for more input instead of a format error, so the streaming decoder kept writing into an 8-byte buffer. That can cause a crash, memory disclosure or remote code execution. It is exploitable when an application decompresses attacker-supplied Brotli data.
• CVE-2026-105482 is a hostname truncation flaw. dns.resolve*() and dns.reverse() silently cut a hostname at a NUL byte, so an application that checks a name against an allowlist and then resolves it can end up querying a different name. The project describes it as an incomplete fix of an earlier CVE that covered only dns.lookup().
• CVE-2026-105483 lets tls.checkServerIdentity() mis-handle IP addresses written with non-ASCII digits, so a certificate issued for one name can be accepted for an IP it was not issued for. The project calls it a regression from an earlier fix.
• CVE-2026-106069 is a mismatch in how a leading-zero IPv4 address is read. URL parsing reads one octet as octal while some operating system resolvers read it as decimal, so the certificate is validated against a different IP from the one the client connects to.

The medium and low issues include a stale keep-alive response being accepted, repeated random values across processes started from a snapshot, and three problems in the Node.js permission model and ZIP handling. Several are described as incomplete fixes of earlier CVEs.

Why it matters

Your runtime is part of the application. A team can review every line it writes and still ship a remote code execution path through a decoder it never called directly. If a service accepts compressed uploads or proxies request bodies, the Brotli flaw may be reachable through code nobody on the team has read for years.

Fixes to fixes are a pattern to plan for. Three of the ten issues are described as incomplete fixes or regressions of earlier CVEs. That is not a criticism of the maintainers, who have shipped patches quickly. It does mean that an upgrade you made in the spring may not be the last one for the same component, and that your process should treat repeat patching of the same area as normal.

Fast patching depends on knowing what you run. The release names three version lines and says end-of-life versions are affected. Most mid-sized organisations we speak to can state their policy for supported runtimes more easily than they can list the version each service actually runs. Containers pinned to an old base image, build agents and serverless functions are where the gap tends to sit.

Validation code is a common weak point. Three of the four high-severity issues involve how names and addresses are checked or resolved. Security decisions that depend on string handling at a boundary, such as allowlists and certificate checks, deserve tests with unusual input, not just well-formed input.

What we would do

1. Inventory every Node.js runtime in production. Include container base images, serverless runtimes, build agents and developer tooling. Record the version and the owner of each, and flag anything on an end-of-life line.
2. Upgrade to the patched release for each supported line. Use v26.12.1, v24.22.1 or v22.23.4. Move services on unsupported lines to a supported one as a planned piece of work with a date, not a backlog item.
3. Prioritise by use of the affected features. Search your code and your dependencies for node:zlib on untrusted input, dns.resolve*() after allowlist checks, certificate validation against IP endpoints, the permission model, and snapshots. Patch those services first.
4. Rebuild images rather than patching in place. Cut a new image from a patched base, run your tests and redeploy through the normal pipeline, so the fix is recorded and repeatable.
5. Add hostile-input tests at trust boundaries. Where code validates a hostname or address, test non-ASCII digits, leading zeros, embedded NUL bytes and non-canonical forms. Where it decompresses, test malformed input.
6. Set a runtime patch service level. Agree how many days a high-severity runtime fix may take to reach production, and report against it monthly alongside dependency updates.

Runtime patching is unglamorous and rarely appears in a product roadmap. The teams that handle a release like this calmly are the ones that decided in advance how it would flow from announcement to production.