Node.js patches TLS verification flaw CVE-2026-106072 in 22.23.4, 24.22.1 and 26.12.1

What the flaw is

A response guide published on dev.to details CVE-2026-106072, a medium-severity vulnerability in how Node.js verifies TLS server certificates on the client side. The issue affects the 22.x, 24.x and 26.x release lines. Fixes landed in Node.js 22.23.4, 24.22.1 and 26.12.1, which the source connects to the project's security releases dated October 21, 2026.

How the verification gap works

According to the dev.to guide, the vulnerable code processed strings that resemble IPv4 addresses without first classifying them as IP literals. The normalized string was then matched against DNS names in the certificate's subject alternative names instead of the IP-address SANs where IP identities belong.

The practical consequence is that a certificate listing 127.0.0.1 as a DNS name — while carrying no IP-address SAN for it — could still pass verification when the client was connecting to an alternate spelling of the same address, such as 0177.0.0.1, 0x7f.0.0.1, 2130706433 or 127.1.

Exploitation is conditional, the source explains. An attacker needs a certificate from a trusted certificate authority that contains the matching numeric DNS name, and the client's resolver must accept the alternate spelling, with glibc named as an example of a resolver that does. Unit tests for this class of bug, the guide adds, should model both conditions and should fail closed when the resolver or certificate fixture does not fit the intended scenario.

Who needs to patch

Anything built on an affected Node.js runtime that makes outbound TLS connections is in scope: web services, background workers, command-line tools, CI jobs and packaged applications. The guide also flags a subtlety for teams running multiple runtimes — the Node.js version used by a child process can differ from the one serving the main request, so version checks should follow each process rather than the deployment as a whole.

The upstream advisory does not indicate that the flaw has been exploited in the wild, according to the source, so response work can be prioritized around affected client services.

What the exposure numbers actually say

The guide cites a ZoomEye query for Node.js product fingerprints that returned 5,539,569 matches when checked on November 1, 2026, while a separate ZoomEye filter for the CVE itself returned zero results. The author is explicit about the limits of those numbers: the larger figure counts product fingerprints, not confirmed vulnerable installations, and it says nothing about whether an affected TLS client is reachable or configured in a risky way. It is best treated as an inventory aid for ownership and version checks rather than a vulnerability verdict.

Remediation and testing

The recommended response covers the runtime, the application's hostname policy and the evidence retained around certificate decisions:

• Upgrade to a fixed release, then verify which runtime version the built artifact actually runs.
• Add certificate verification tests for four cases — canonical IP, non-canonical IP, DNS SAN and IP-address SAN — and confirm that the expected identity type drives the result.
• Monitor rejection rates and configuration errors while the rollout proceeds.

Beyond the patch, the guide advises canonicalizing host values before certificate verification and rejecting ambiguous IP literals that the application does not need to support. Any temporary conversion rule should be documented and tested rather than applied inconsistently across services. Teams should also keep records of the runtime version, certificate test results and any legacy exceptions they grant.

Why it matters

TLS client verification is the mechanism that lets a Node.js service trust the server on the other end of a connection. When an ambiguous hostname spelling can be matched against the wrong kind of SAN, everything downstream inherits the error: the credentials sent, the tokens exchanged, the commands executed and the authorization decisions made over that connection. The severity rating is medium and exploitation requires an unusual certificate plus a compatible resolver, but the fix is a routine version bump with clear test cases attached. Given how many Node.js deployments make outbound calls — workers, CI jobs, CLIs and packaged apps among them — moving to 22.23.4, 24.22.1 or 26.12.1 and adding the recommended certificate tests closes a subtle trust gap at little cost. For follow-up, the source points readers to the Node.js security release announcements, the three release notes pages and a CERT.LV security notice.