Cloudanix VulnDB

CVE-2026-105483

High · 7.4

CVSS

7.4

EPSS

0.3%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A programming error lets attackers trick Node.js programs into trusting the wrong security certificate when connecting to internet addresses written with unusual number characters.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Data Tampering
Component
Library
Class
Authentication Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Bypasses TLS certificate hostname verification for IPv4 endpoints when the target is supplied using non-ASCII characters that normalize to an IP address; checkServerIdentity incorrectly routes the check to DNS name and Common Name fields instead of IP address SANs.

Why it matters to the business

Applications built on affected Node.js versions may accept TLS connections from servers presenting certificates not issued for the actual IP address, raising the risk of interception or impersonation of encrypted services and potential exposure of sensitive data in transit.

How an attack unfolds

An attacker crafts a hostname containing fullwidth or other non-ASCII digits that resolve to a target IPv4 address, presents a certificate containing only DNS names or wildcards, and relies on the flawed normalization logic to have the certificate accepted during the TLS handshake.

How to fix it

Upgrade all Node.js 24.x and 26.x installations to the latest maintenance releases that restore correct IP address handling in tls.checkServerIdentity; rebuild and redeploy dependent applications after the upgrade.

How to confirm the fix worked

Execute connectivity tests using hostnames that contain fullwidth digits representing valid IPv4 addresses against both patched and unpatched runtimes while confirming that only certificates with matching IP address SANs are accepted.

Typical attack path

  1. Identify a Node.js application performing outbound TLS connections to IPv4 addresses
  2. Register or control a certificate containing DNS SANs or CN entries that match a normalized form of the target address
  3. Initiate a TLS handshake supplying the address using non-ASCII characters
  4. Obtain acceptance of the mismatched certificate and proceed with the session

How to detect it

Inspect TLS client logs and network flow records for outbound connections whose host strings contain non-ASCII digit characters; correlate with certificate validation events that succeed despite missing IP address SANs.

What your security team should do

  • Inventory all Node.js 24.x and 26.x deployments and schedule immediate upgrades
  • Add automated dependency scanning that alerts on Node.js versions prior to the security fix
  • Review custom TLS configuration code for direct use of checkServerIdentity and replace with updated runtime behavior
  • Monitor EPSS and exploit maturity signals for any rise in observed attempts

The record

A flaw in Node.js TLS hostname verification allows a certificate without a matching IP address SAN to authenticate a connection to an IPv4 address when the host is written with non-ASCII characters, such as fullwidth digits (`１２７.0.0.1`). `tls.checkServerIdentity()` did not recognize such hosts as IP addresses, even though they normalize and resolve to a regular IPv4 address, and matched them against the certificate DNS names and Common Name instead. A certificate containing `DNS:127.0.0.1` or `DNS:*.0.0.1` could therefore be accepted for an IP endpoint it was not issued for. This is a regression introduced after the fix for CVE-2026-48618. This vulnerability affects Node.js **26.x** and **24.x**.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities