Node.js TLS hostname bypass: four CVEs, one release

The Brotli bug took the headlines, but the October Node.js release also fixed four certificate and DNS flaws, three of them rated High. Each is a variation on the same failure: a Node.js TLS hostname bypass in which the certificate chain validates correctly and the hostname check then accepts a name or address it should have rejected. The result is that TLS still encrypts, and stops proving who you are talking to.

As with every CVE in this release, the advisory gives no CVSS score, no affected version ranges and no workaround — only a title, a severity label and the release lines. So the triage work is yours.

The four bugs, as Node.js titles them

Straight from the security release notes:

CVE	Title	Severity	Lines
CVE-2026-106069	TLS certificate hostname bypass when the host loosely resolves to an IP address	High	26.x, 24.x, 22.x
CVE-2026-105482	dns.resolve truncates names containing NUL char	High	26.x, 24.x, 22.x
CVE-2026-105483	TLS certificate hostname bypass when the IP is written fullwidth digits	High	26.x, 24.x
CVE-2026-106072	Improper certificate validation for non-canonical IPv4 hostnames allows DNS SANs to authenticate IP endpoints	Medium	26.x, 24.x, 22.x

Note that CVE-2026-105483 is the only one of the four that does not affect 22.x. If you run a mixed fleet, that single row is the reason a blanket "we are on 22, we are fine" answer is wrong in both directions.

A Node.js TLS hostname bypass starts with string comparison

The common thread is string comparison standing in for address comparison. TLS hostname verification matches what you asked for against the certificate's subjectAltName entries, and an IP address has to match an iPAddress entry rather than a DNS entry. The bugs are in deciding which of those you are even looking at.

An IPv4 address has many textual forms. Decimal with leading zeros, a 32-bit integer, mixed hex — all of these resolve to the same host while looking nothing like the canonical dotted quad. CVE-2026-105483 describes the same idea taken further, using fullwidth Unicode digits: characters that are not ASCII digits at all, so a parser checking "does this look like an IP?" says no and hands the string to the DNS-name path, where a certificate's DNS SAN can match it. CVE-2026-106072 names that outcome in its own title — DNS SANs authenticating IP endpoints.

The NUL-byte bug is a different mechanism with the same shape. If dns.resolve truncates a name at a NUL character, then example.com\0.attacker.test is resolved as one thing and may be validated, logged or allowlisted as another. Any code that makes a trust decision on a hostname string before resolution is in scope.

Where this actually bites

Not usually on the browser-facing edge, where certificates come from a public CA and hostnames are ordinary. The exposure concentrates in three places engineers rarely revisit.

• Service-to-service TLS, especially mutual TLS. If mTLS is an access control rather than just transport security, a hostname bypass turns it into a formality. Internal services are also where certificates are most often issued to IP addresses.
• SSRF defences built on hostname allowlists. This is the dangerous combination. A URL validator that parses a hostname, decides it is not an internal address, and then lets the request proceed is exactly the pattern these bugs break — the string the validator inspected and the host that was actually reached can differ.
• Webhook delivery and outbound integrations. Anywhere a customer supplies a URL you will connect to, the attacker controls the input to the parser.

If you build API integrations where a tenant supplies the endpoint, that third case deserves the first look. The test is not whether you use HTTPS; it is whether any security decision is made on a hostname string rather than on the resolved address and the verified certificate.

The severity label and the fix commit disagree

Worth knowing before you escalate. Reporting on the release notes that the fix commit for CVE-2026-105483, the fullwidth-digits bypass, describes it as low-severity and hard to exploit — while the advisory rates it High.

We have not reviewed the commit ourselves and are not going to pretend to adjudicate it. But the gap is a useful reminder that a severity label is an opinion formed at disclosure, and that "High" across four superficially similar CVEs flattens real differences in how reachable each one is. The one to care about most is CVE-2026-106069: it affects all three lines, and "the host loosely resolves to an IP address" describes the most ordinary configuration of the four.

What to do

Upgrade to 22.23.4, 24.22.1 or 26.12.1. There is no workaround published for any of these, and unlike the Brotli bug there is not even a proxy rule to buy a window with — hostname verification happens inside your process, after the connection.

Then audit for the pattern rather than the version. Grep for hostname comparisons that happen before a request: allowlist checks, new URL(...).hostname tests against internal ranges, any custom checkServerIdentity. Where you find one, make the decision on the resolved address and let TLS verification do its own job rather than reimplementing it.

One more thing to check while you are in there: certificates issued to IP addresses in internal estates, and whether they carry iPAddress SANs or only DNS ones. Internal PKI is where this gets sloppy, and certificate hygiene has a habit of being discovered during an incident rather than before one — the same lesson as certificate lifetimes disagreeing across issuers. If your TLS termination sits in a gateway, sequence that upgrade carefully too; Envoy Gateway 1.9.1 came with its own TLS note for much the same reason.

These four will be forgotten in a fortnight because nothing was named after them. That is roughly the right amount of alarm and the wrong amount of auditing.