Node.js October 2026 Security Releases

Affects 22.x, 24.x and 26.x. Fix: Node.js commit, google/brotli commit

The bug is in the Brotli library that Node.js bundles, not in Node.js’s own code. A crafted compressed stream that declares a single block type and then switches blocks was not rejected, and Node.js says the result is an out-of-bounds write that permits remote code execution. Node.js applied the upstream fix, which makes the decoder stop with an error on such streams.

Who is exposed: anything that decompresses Brotli data it does not control. zlib.brotliDecompress, its sync form and zlib.createBrotliDecompress all reach the decoder; the fix’s regression test exercises both the one-shot and streaming paths. Typical cases are servers that accept Content-Encoding: br request bodies and clients or proxies that decompress responses from servers they do not trust. Node.js has not said whether the built-in fetch reaches the bug.

Affects 22.x, 24.x and 26.x. Fix: Node.js commit

The DNS resolver hands names to c-ares as C strings, which end at the first NUL character. A name such as example.com\0.trusted.corp passes a JavaScript check like endsWith(".trusted.corp"), but the query actually goes out for example.com. The fix commit uses this example.

Who is exposed: applications that pass user-supplied names to dns.resolve, any resolve* method, dns.reverse or a Resolver instance after checking them as strings, for example to enforce an allowlist. After the fix these calls throw ERR_INVALID_ARG_VALUE for names containing a NUL. The change does not touch dns.lookup.

Affects 22.x, 24.x and 26.x. Fix: Node.js commit

Before checking a server’s certificate, Node.js normalised the hostname. Strings such as 0127.0.0.1, 0x7f.0.0.1 or 127.1 could be checked against the certificate as one address while the operating system’s resolver connected to another. The fix’s test pairs 0127.0.0.1, which the resolver reads as octal and connects to 87.0.0.1, with a certificate check against 127.0.0.1.

Who is exposed: applications that open TLS connections to host strings an attacker can influence, such as webhook senders, URL previewers and proxies. Based on the fix’s tests, the attacker also needs a certificate the client trusts whose DNS name is the IP address written normally. Connections to fixed, ordinary hostnames are not affected. After the fix, tls.checkServerIdentity rejects these hosts with ERR_TLS_CERT_ALTNAME_INVALID.

Affects 24.x and 26.x. Fix: Node.js commit

A related regression in the same hostname check. A host written with fullwidth digits, such as １２７.0.0.1, was normalised into an ordinary IP address and could then match a certificate issued for that address. The fix rejects any host that only becomes an IP address after normalisation. Node.js 22 does not have the regression.

Node.js rates this high, but the fix commit itself describes it as a low-severity bug that is not easy to exploit. We show the rating from the security release post.

Affects 22.x, 24.x and 26.x. Fix: Same commit as CVE-2026-106069

A second report of the same underlying problem, fixed by the same change. A certificate whose DNS name reads 127.0.0.1 could authenticate a connection made to a non-canonical form of the address, such as 0177.0.0.1. Upgrading for CVE-2026-106069 fixes this too.

Affects 22.x, 24.x and 26.x. Fix: Node.js commit

When the HTTP client reuses a kept-alive connection, a server could write a response onto the idle socket before the next request was sent, and Node.js would treat it as the answer to that request. An earlier guard only caught this when the event loop had polled the socket. The fix asks the operating system whether unread data is waiting before reusing a socket, and opens a new connection if it is.

Who is exposed: clients using an http.Agent with keepAlive enabled that talk to a server which is malicious or compromised, or to a plain HTTP server through an attacker on the network path.

Affects 22.x, 24.x and 26.x. Fix: Node.js commit

crypto.randomUUID() and crypto.randomInt() keep a small cache of random values. When an application built a startup snapshot, the unused part of that cache was saved into it, so every process started from the snapshot produced the same first values. The fix clears the caches when a snapshot is written and when it is loaded.

Who is exposed: only applications built as single executable applications with useSnapshot enabled, or that use user-land startup snapshots. Ordinary applications are not. Node.js has not published rotation guidance; our recommendation is to rebuild affected binaries on a fixed version and to treat any UUIDs or random numbers they used as secrets, such as tokens or nonces, as predictable and rotate them.

Affects 26.x. Fix: Node.js commit

zlib.ZipFile is an experimental API added in 26.8.0 for reading ZIP archives. When a ZIP entry failed header validation, a later read of that entry could return bytes from the wrong position in the file. Only 26.x has this API.

Affects 26.x. Fix: Node.js commit

With the Permission Model enabled, a wildcard path in --allow-fs-read or --allow-fs-write could grant access to more paths than it should. Node.js has not described which paths were over-granted.

Affects 22.x, 24.x and 26.x. Fix: Node.js commit

fs.realpathSync() skipped the Permission Model check that its siblings, such as fs.promises.realpath() and fs.existsSync(), already performed, so it could be used on paths the process had not been granted.

On both Permission Model issues: the Node.js documentation describes the Permission Model as a seat belt that stops trusted code from accidentally touching files it was not granted, and states that it does not protect against malicious code. Do not rely on it to contain untrusted code, patched or not.