Executive summary

The Node.js security release of 21 October 2026 addresses ten vulnerabilities, including a Brotli decoder flaw that can permit remote code execution and errors in Domain Name System (DNS) and Transport Layer Security (TLS) hostname handling. Fixed releases are 22.23.4, 24.22.1 and 26.12.1, with the affected branches differing between individual flaws. Applications using startup snapshots, archive inspection or the Permission Model also need to examine whether the affected features form part of their security boundaries. We assess that checking the executable actually running each workload, alongside its feature use, is likely (B2) to identify exposure missed by checking only a project's dependency manifest.

The release and its scope

Node.js assigns four issues high severity, three medium and three low in its consolidated advisory. The same release also updates dependencies including c-ares, Undici and the certificate store on the supported branches, with OpenSSL and SQLite changes applying to the branches specified by the project. The remediation unit is the Node.js runtime; installing an unrelated application package is not evidence that this runtime has changed.

Release line Security release Official release record
22.x 22.23.4 Node.js 22.23.4
24.x 24.22.1 Node.js 24.22.1
26.x 26.12.1 Node.js 26.12.1

This is a branch-specific patch matrix, not a recommendation to move every application to the newest major version. An organisation can apply the appropriate security release on its existing supported branch and perform its normal compatibility checks. Older installations need a supported upgrade path or a vendor's explicit security-maintenance statement; absence from this three-branch table is not a clean bill of health.

Brotli: untrusted data reaches native memory

For CVE-2026-111497, the Node.js project describes a decoder error that allows malformed Brotli input to corrupt process memory. A decoder condition that should terminate processing was treated as a request for more input. The reported consequences include a crash, disclosure of process memory and remote code execution when an application decompresses attacker-supplied Brotli data with node:zlib. The advisory lists all three supported release lines as affected.

The decisive exposure question is therefore whether untrusted compressed data reaches the decoder. A service does not need to advertise a public decompression endpoint for that question to matter: reviewers should trace where its libraries obtain and decode input, rather than infer safety from the application's business function. This is a review recommendation, not a claim that every Node.js service automatically exposes this particular path.

Google's Brotli 1.2.1 release also names CVE-2026-111497. That upstream record matters when the same estate contains separate Brotli consumers. Updating Node.js establishes the state of that runtime; it does not establish the state of independently packaged libraries or other runtimes.

DNS and certificate validation must agree on identity

The National Vulnerability Database (NVD) record for CVE-2026-105482 describes names containing a null character being truncated by the dns.resolve*() family and dns.reverse(). A program can validate one hostname yet resolve a different one. This issue extends beyond the earlier fix covering dns.lookup() and certain connection options, so an application's use of the previously fixed function is not enough to assess another resolver call.

Three certificate issues concern different interpretations of an Internet Protocol (IP) address. They should not be collapsed into a generic warning that TLS is broken:

CVE Failure described in the public record Affected lines
CVE-2026-105483 Non-ASCII address spellings can be treated as DNS names during certificate matching 24.x, 26.x
CVE-2026-106069 The operating system and Uniform Resource Locator (URL) normalisation can disagree about a non-canonical address 22.x, 24.x, 26.x
CVE-2026-106072 A numeric DNS subject alternative name can be accepted where an IP-address subject alternative name is required 22.x, 24.x, 26.x

The last issue has specific prerequisites, including a suitable certificate from a trusted certification authority and a resolver that accepts the address spelling. These conditions are relevant to prioritisation, but they do not remove the need for the runtime fix.

Our defensive recommendation is to review URL intake, allowlists, DNS resolution and connection establishment as one path. Record which component normalises the name and which checks the certificate. Add ordinary negative tests for rejected hostname forms to the application's test suite. Do not replace certificate verification with permissive custom logic to make a failing connection work.

Connection reuse and repeated random values

CVE-2026-105481 concerns Hypertext Transfer Protocol (HTTP) Agent connection reuse. Under the documented timing conditions, a client can accept a response that arrived before its new request was sent. The issue affects 22.x, 24.x and 26.x and is described as an incomplete earlier fix. For review purposes, identify clients using persistent connections and assess their handling of unexpected responses; a successful request after an update is a functional check, not proof that the previous condition was absent.

CVE-2026-106074 affects entropy caches captured in application startup snapshots and single executable applications built with snapshot support. When certain random-value functions are called during snapshot creation, new processes can initially produce repeated values from the saved cache. The record names crypto.randomUUID(), crypto.randomUUIDv7() and crypto.randomInt(), and describes up to 127 repeated universally unique identifiers (UUIDs) and roughly 1,000 repeated integer values.

This is conditional behaviour, not a claim that ordinary UUID generation in every Node.js process repeats. Build owners should establish whether they create these snapshots and whether the affected functions run during that build. Our recommendation is to regenerate affected deliverables with the fixed runtime and check representative outputs across separate fresh processes. Where identifiers are security-sensitive, review their purpose and exposure separately rather than assuming that a collision necessarily proves token compromise.

Archive scanning and filesystem permissions

Two lower-severity issues apply specifically to Node.js 26.x. CVE-2026-106070 concerns zlib.ZipFile retaining state after a failed header check, potentially returning bytes other than the requested archive entry. A scanner and another archive implementation can consequently evaluate different content. CVE-2026-106071 concerns overly broad filesystem access from a particular wildcard permission-tree arrangement.

CVE-2026-106073 affects all three supported branches. It leaves fs.realpathSync() without required read-permission checks, allowing filesystem information to be obtained outside the configured allowed paths. Its scope differs from the earlier fix for fs.realpathSync.native().

Severity labels help compare the vendor's assessments; they do not describe how an individual organisation uses a feature. An archive gateway or a service relying on filesystem restrictions should give the relevant issue an explicit owner even where the vendor labels it low. Keep application permissions, operating-system permissions and container isolation as separate controls in the review.

A remediation procedure with evidence

The following is our suggested operational sequence, derived from the affected runtime and feature boundaries above:

  1. Identify running copies. Inventory service executables, container images, build tools and packaged application runtimes. Record a service owner and the exact branch for each copy. An interactive shell's node --version answers only for the executable selected by that shell.
  2. Map reachable features. Note Brotli decoding, custom DNS handling, TLS identity checks, persistent HTTP clients, startup snapshots, archive inspection and filesystem permissions. Record a feature as unused only when the application's configuration and call paths support that conclusion.
  3. Install the correct release. Use the project's release record or the distribution's security advisory to establish the fixed package. Preserve enough package and image identity information to reproduce the decision later.
  4. Restart or replace workloads. Confirm the newly running process uses the intended executable. Rebuild packaged deliverables where the old runtime is embedded, rather than assuming a host update changes their contents.
  5. Run targeted functional tests. Exercise representative HTTP, TLS and DNS operations, archive handling and snapshot-built programs as applicable. Check that expected failures remain failures, alongside checking normal service behaviour.
  6. Record closure. Keep the pre-update identity, replacement identity, restart time, verification results and any remaining exceptions. Give exceptions a named owner and review date.

Detection and assessment limits

There is no universal network indicator in these advisories that proves exploitation across all ten vulnerabilities. We recommend correlating unexpected decoder crashes, unusual TLS failures, resolver inconsistencies and application behaviour with deployment and request timelines. A crash alone does not establish remote code execution, and an absence of crashes does not demonstrate that input never reached an affected path.

The sources cited here establish vulnerabilities and fixes. This article does not infer exploitation in an organisation from its installed version alone, identify a responsible threat actor, or claim that every listed weakness has been exploited in the wild. The useful next step is a verified update and a documented exposure assessment, followed by incident investigation where additional evidence warrants it.

Further reading