On October 21, 2026, the Node.js project released security updates Node.js 26.12.1, 24.22.1 and 22.23.4, which fix 10 vulnerabilities. Four of the fixed vulnerabilities are rated "High" severity, including a flaw in Brotli decoding that could lead to remote code execution. The updates also fix vulnerabilities that affect the safety of external communication, such as an issue that allows TLS certificate verification to be bypassed and a bug related to DNS name resolution.
The update also addresses an issue in which the same random values are generated repeatedly when an application is restored from a startup "snapshot," which saves its initialized state. As a result, administrators need to check not only the standard Node.js runtime but also applications distributed as single executable applications (SEA). In addition to updating to the patched versions, it is important to confirm that TLS connections to external services work correctly and that distributable files rebuilt with the patched Node.js include the fixes.
Three release lines get security updates, with the impact of the 10 vulnerabilities varying by line
In its official security announcement on October 21, the Node.js project released patched versions for three release lines: 26, 24 and 22. The 26 line is Current, while the 24 and 22 lines are Long-Term Support (LTS) releases. All three lines received fixes for High-severity vulnerabilities in this update. However, the affected vulnerabilities differ by line, and not every fix applies to all three.
| Line | Patched version | Release type | TLS verification bypass using full-width digits (CVE-2026-105483) |
|---|---|---|---|
| 26 | 26.12.1 | Current | Affected |
| 24 | 24.22.1 | LTS | Affected |
| 22 | 22.23.4 | LTS | Not affected |
Of the 10 CVEs disclosed, four are rated High, three Medium and three Low. The most serious is CVE-2026-111497, an out-of-bounds write vulnerability in the Brotli decoder. Brotli is a technology used to compress and decompress data, and in this issue the decoding process may write data beyond the allocated memory region. The Node.js project says the bug could lead to remote code execution, and the 26, 24 and 22 lines are all affected. However, the official announcement does not describe the specific communication paths through which an attack could succeed, nor does it say whether exploitation in the wild has been confirmed.
The impact of the three Low-severity vulnerabilities also varies. CVE-2026-106070 is a problem in which part of attacker-controllable data is returned even after ZIP header validation fails. CVE-2026-106071 involves a flaw in how the Node.js permission model searches file paths that use wildcards, which could allow broader file access than intended. These two issues affect only the 26 line. CVE-2026-106073, which allows restrictions in the permission model to be bypassed through fs.realpathSync(), affects all three lines.
The fact that the full-width-digit TLS verification bypass does not occur in the 22 line therefore does not mean that line can skip this update. The Brotli vulnerability, another TLS verification bypass and the DNS issue also exist in the 22 line. Users need to check the fixes for the line they use and apply the corresponding security update.
Multiple vulnerabilities that allow TLS certificate verification to be bypassed are fixed
The other three High-severity vulnerabilities involve DNS name resolution and TLS certificate verification. One of them, CVE-2026-105482, is a vulnerability in which passing a name containing a NUL character to dns.resolve() causes the string to be truncated partway. It affects all of the 26, 24 and 22 lines. The NUL character is a special character used to mark the end of a string, so the name that was entered and the name that is actually resolved may differ. If an application performs access control or similar checks based on the entered name, this mismatch could lead to security problems.
Two vulnerabilities related to how IP addresses are written and interpreted in TLS certificate verification were also fixed. CVE-2026-105483 is a problem in which hostname verification can be bypassed when an IP address is written with full-width digits, and it affects the 26 and 24 lines. CVE-2026-106069, meanwhile, is a problem in which loose parsing of a hostname causes the input to be treated as an IP address, allowing certificate verification to be bypassed. This one affects all of the 26, 24 and 22 lines. In both cases, the problem is that the way the string representing the destination is interpreted can produce inconsistent certificate verification results.
In TLS connections, it is necessary to confirm not only that a certificate was issued by a trusted certificate authority but also that the certificate corresponds to the server actually being connected to. According to the Node.js TLS API documentation, tls.checkServerIdentity() is called after a certificate has passed verification such as confirming it was issued by a trusted authority, and it checks whether the specified hostname or IP address matches the certificate. These vulnerabilities show that if there is a problem in this matching step, the identity of the connection partner may not be properly confirmed even when the communication is encrypted.
CVE-2026-106072, rated Medium, also concerns IP address interpretation and certificate verification. Certificate verification is handled incorrectly for non-standard IPv4 address notation, so the Subject Alternative Name (DNS SAN) of a certificate, which is meant to authenticate DNS names, could be used to authenticate a destination specified by IP address. This issue also affects all three lines. Applications that connect from Node.js to external APIs or other services need to check how destination names and IP addresses are specified, as well as whether they use custom certificate verification logic.
In addition, CVE-2026-105481, rated Medium, is a problem in which a socket reused in an HTTP keep-alive connection processes a response that was written before the request was sent. Keep-alive is a mechanism that reuses existing connections instead of establishing a new one for each HTTP exchange, and all three lines are affected here as well. This security update concerns not only the handling of requests received from outside but also the safety of Node.js when it communicates with external services.
Public-key blocklist introduced in response to the compromise of eMudhra intermediate CA private keys
The update also includes an enhancement to certificate verification that responds to the compromise of private keys of eMudhra intermediate certificate authorities. Unlike the issue discussed above, in which the hostname in a certificate must match the destination, this change concerns how the trustworthiness of a certificate is judged. In TLS certificate verification, the "certificate chain" is normally checked, running from the server's certificate through an intermediate CA to a trusted root CA. But if an intermediate CA's private key is compromised, safety cannot be guaranteed even for a chain that leads to a trusted root CA.
According to the fix pull request merged on Node.js's GitHub, Node.js bundles Mozilla's root certificate store but has neither a revocation mechanism equivalent to the CRLSet or OneCRL used in browsers nor built-in online revocation checking by default. As a result, even an intermediate CA whose private key had been compromised could pass verification as long as its certificate chain led to a trusted root CA. On the other hand, removing the root CA connected to the problematic intermediate CA from the trust set would also affect other legitimate intermediate CAs that use the same root CA.
Node.js therefore added a mechanism to individually identify and reject problematic public keys. Specifically, it hashes the SubjectPublicKeyInfo (SPKI), the public-key information in a certificate, with SHA-256 and compares the value against a built-in blocklist. Initially, the list contains eight intermediate CAs of eMudhra and emSign whose private key compromise was reported in October 2026. If a certificate chain contains a public key that matches the list, it is rejected through the normal certificate verification process and treated as CERT_REVOKED, which indicates revocation.
However, this change does not automatically make every TLS connection safe. Whether a connection is rejected when certificate verification fails also depends on the rejectUnauthorized setting. If an application has disabled certificate verification or implements its own verification logic, updating Node.js itself may not be enough.
The fix PR also notes a constraint on resuming TLS sessions established before the update. When a pre-update session is reused, certificate chain verification is not performed again, and that state may continue until the session expires. For this reason, post-update checks should establish new TLS connections rather than merely reusing existing ones, to confirm that certificate verification works properly. Checking the version of the root certificate store alone is not enough to determine whether the newly added public-key blocking works correctly.
Same random values repeated when startup snapshots are restored
CVE-2026-106074, rated Medium, is a vulnerability that arises from the combination of Node.js's random number generation and startup snapshots. It concerns the random number cache used by crypto.randomUUID() and crypto.randomInt(): if this cache is saved in a startup snapshot or a single executable application (SEA), multiple processes restored from it may repeatedly use the same random values. The issue affects all of the 26, 24 and 22 lines.
A startup snapshot is a mechanism that saves the state of an application after its initialization has completed and restores it on later startups to shorten startup time. According to the Node.js SEA documentation, enabling useSnapshot runs the main script at build time and lets the initialized state at that point be embedded in the executable. In the user's environment, processing resumes from the saved state, so part of the initialization does not need to be repeated.
However, if unused random values generated when the snapshot was created are also saved, processes started from the same snapshot may reuse the same values. Because random values are used for purposes such as generating identifiers, duplicates among values that should be generated independently in different processes are a problem. The published fix commit changes the code so that the random number cache is reinitialized when a snapshot is saved and restored.
The fix clears the cache at two points: after the user-registered serialization callback finishes and before the deserialization callback begins. This is because the random number cache can be refilled by microtasks, shutdown processing and the like even after the save-time callback ends. Clearing the cache at restore time as well prevents saved random values from being reused in other processes. Note that this vulnerability concerns the random number cache saved in startup snapshots; it does not mean that every Node.js process started in the normal way generates the same random values.
Particular attention is needed when distributing an application as a single executable that embeds Node.js. SEA is a distribution format that lets an application run in environments where Node.js is not installed, and it includes the Node.js runtime that was used when it was generated. Updating Node.js on a development computer therefore does not automatically replace executables that have already been distributed with the patched version.
For SEAs that use startup snapshots, the executable needs to be regenerated with the patched version of Node.js, and the application at the distribution destination also needs to be updated. In addition, the Node.js that generates the SEA preparation data and the Node.js of the executable into which it is embedded must be the same version. When updating, it is important to check both the Node.js used for the build and the executable that is ultimately distributed, not just the development environment.
After updating, confirm that fixes are reflected in TLS connections and distributed files
This security update fixes mechanisms that differ from one another: confirming the destination through TLS certificates, blocking compromised intermediate CAs, and the random number cache saved in startup snapshots. Because the target of each fix and the way to verify it differ, it is necessary to verify based on the features the application actually uses and how it is distributed, not just to check the Node.js version number.
Based on the official security announcement, the API documentation and the published fixes, the main items to check after updating can be organized as follows.
| Fix target | What to check after updating | Notes |
|---|---|---|
| TLS hostname verification | Whether TLS connections to external APIs and similar services work and certificate matching functions correctly | Also check custom certificate verification functions and settings |
| Blocking of compromised intermediate CAs | Whether certificate chains are properly verified on new TLS connections | Resumed sessions established before the update are not re-verified |
| Random number cache at startup | Whether snapshots or SEAs have been regenerated with the patched version and the fix is reflected in distributed files | Distinguish between the host's Node.js and the version in distributed executables |
This table organizes operational checks based on the content of these fixes and is not an official verification procedure that applies to every application. Actual safety depends on an application's configuration, custom settings and the features it uses. For TLS connections in particular, it is necessary to check whether standard certificate verification has been disabled and whether communication with external services still works correctly after the fix.
The update also includes updates to bundled dependency libraries, in addition to the vulnerabilities in Node.js itself. According to the official announcement, c-ares and Undici are updated in all three lines, OpenSSL in the 24 and 22 lines, and SQLite in the 22 line. The release notes for Node.js 24.22.1 and 22.23.4 also list the respective library updates. It is not enough to update the npm packages an application uses; users must also confirm that the necessary fixes are reflected in the Node.js runtime itself.
It is also necessary to correctly understand the scope of what the fixes guarantee for the permission model vulnerabilities. The official Node.js documentation on the permission model states that the feature is intended to restrict trusted code from unintentionally accessing resources such as files, and is not a mechanism that guarantees safety against malicious code. Although the fixes resolve specific permission-check bugs, they do not turn the permission model into a sandbox for safely running untrusted code.
The Node.js project urges users to update to the latest supported version, noting that versions that have reached end of support are also affected by security issues. In addition to the Brotli vulnerability linked to remote code execution, this update reaches into internal application processing such as outbound TLS connections and snapshot restoration. To judge that an update is complete, it is necessary to confirm that the fixes are reflected not only in the Node.js installed on administrators' machines but also in running services and in executables at their distribution destinations.