10 Node.js CVEs: how to decide when to update

On 21 October 2026, Node.js released fixes for 10 vulnerabilities: four high, three medium and three low severity. Severity describes the potential impact of a flaw, but deciding when to update also requires understanding how it affects the application.

A high-severity vulnerability may require immediate action or allow a staged rollout, depending on the running version, affected features and inputs an attacker can control. That assessment helps choose between accelerating the patch, testing it in staging before rolling it out in phases, or using a low-traffic maintenance window with a defined deadline.

Exposure and active exploitation are different situations. Versions, configuration and input paths help establish exposure; claiming active exploitation requires additional evidence. Seeing no attacks in the logs does not prove the application is protected.

Which conditions determine exposure?

• TLS validation — CVE-2026-105483, CVE-2026-106069 and CVE-2026-106072. These concern certificate verification with unusual or non-canonical IP address representations. They can matter for proxies, HTTP clients and services connecting to destinations controlled by third parties. They do not, by themselves, describe a generic attack on every HTTPS API.
• DNS resolution — CVE-2026-105482. dns.resolve() can truncate names containing a NUL byte. The risk arises when an application accepts those names and uses the result for security decisions, rather than merely resolving domains.
• Reused HTTP connections — CVE-2026-105481. Under certain conditions, a keep-alive socket can process a response sent before the request. This matters particularly when a malicious destination server can influence reused connections.
• Snapshots and executables — CVE-2026-106074. The entropy caches for crypto.randomUUID() and randomInt() can survive in startup snapshots and SEA executables, repeating values across processes. This is particularly relevant when that architecture is used and those values protect sensitive operations.
• Permission Model — CVE-2026-106071 and CVE-2026-106073. These affect filesystem access restrictions. The first affects Node.js 26; the second affects release lines 22, 24 and 26. Exposure requires the application to use Node.js's Permission Model and let an attacker reach the affected operations.
• ZIP processing — CVE-2026-106070. This concerns invalid ZIP header handling in Node.js 26. Exposure depends on using that functionality with untrusted archives.

Priority depends on whether those conditions hold in the actual environment. A TLS flaw may demand urgent action in a proxy connecting to untrusted destinations, while an application that uses neither snapshots nor SEA may have room to schedule the randomness fix. The severity rating stays the same; each deployment's exposure differs.

Brotli: a common input surface

CVE-2026-111497 is an out-of-bounds write in the Brotli decoder included in Node.js. If an attacker can make the process decompress malicious Brotli data, memory corruption can potentially cause data exposure, service crashes or code execution.

The decoder can be reached without a direct call from application code:

• In Express 5, body parsers support Content-Encoding: br. An externally supplied compressed request can reach the decoder when the middleware processes it.
• When fetch() accesses third-party URLs or services, a Brotli response can be decompressed automatically.

These create more common input paths than some other issues in this release. That does not establish code execution against every Express API or every use of fetch(): reaching the decoder and achieving reliable exploitation are separate questions. It does justify prioritising the patch.

Update the runtime and assess exposure

The fixed releases are Node.js 22.23.4, 24.22.1 and 26.12.1. Check the version actually running with node -v. For containers, rebuild and redeploy the image. npm audit does not replace reviewing the runtime.

Then ask three questions:

1. Which input does the attacker control? An HTTP body, an external URL, a DNS name or a ZIP archive?
2. Which code processes it? A parser, fetch(), TLS, a snapshot or the Permission Model?
3. What could a failure allow? An incorrect response, unauthorised access, a crash or code execution?

Choose the update schedule

• Reachable attack path or evidence of exploitation: prioritise the patch and, where possible, temporarily reduce exposure while validating it. A staged rollout should move fast enough to avoid unnecessarily extending the risk.
• Exposure ruled out through concrete checks: schedule the update with a defined deadline. With multiple environments or replicas, validate in staging first and roll out in phases; a low-traffic window can reduce operational impact.
• Exposure still unknown: investigate promptly rather than treating missing data as a reason to defer. If the potential impact is high and the risk cannot be bounded quickly, take a conservative approach to timing.

The goal is to update deliberately: understand what affects each environment so urgency and rollout match the risk, without treating every advisory as an identical emergency or postponing patches indefinitely.

Sources

• Node.js — Official security announcement, 21 October 2026
• Node.js — Release 22.23.4
• Node.js — Release 24.22.1
• Node.js — Release 26.12.1
• Express — Brotli support in Express 5 body parsers