CVE-2026-105483: certificate SAN policy decides the risk
The Node.js bug behind CVE-2026-105483 has a simple defensive lesson: a certificate is valid only for the identity type the client intended to verify. In affected Node.js 24.x and 26.x releases, a fullwidth-digit IPv4 host could be normalized and resolved as an address while tls.checkServerIdentity() evaluated DNS names and the Common Name. The result was a certificate trust decision for the wrong identity class.
Node.js fixed the problem in 24.22.1 and 26.12.1 on October 21, 2026. The vendor rates it High. The advisory score is CVSS v3.0 7.4 with a network vector and high attack complexity. The CWE is 295, improper certificate validation.
DNS SAN and IP SAN are different promises
A DNS SAN says that the subject is identified by a DNS name. An IP address SAN says that the subject is identified by a literal IP address. Browsers and TLS libraries normally enforce that separation because an address and a name are different identities, even when DNS or an operating system resolver maps one to the other.
The affected Node.js path did not recognize the fullwidth-digit destination as an IP address. It normalized the destination to a normal IPv4 address and connected there. Verification then compared the normalized value with DNS names. A certificate carrying DNS:127.0.0.1 or an applicable DNS wildcard could satisfy that comparison.
The missing control was not a missing signature check. The chain could be trusted. The problem was that the signed identity did not describe the type of endpoint the client believed it was contacting.
Why public CAs and private PKI need separate review
High attack complexity reflects the certificate conditions. The attacker needs a chain trusted by the client and a certificate whose DNS identity matches the address representation used in verification. A public CA policy may restrict issuing DNS names that are numeric IP-looking strings, but an organization cannot assume that every CA in its trust store follows the same issuance profile.
Private PKI deserves direct attention. Internal CAs may issue certificates for test services, ephemeral hosts, or address-like names. Those certificates can be legitimate for their original scope while still becoming dangerous if they are accepted for an IP endpoint the client did not intend to contact.
Teams should inventory trust stores, intermediate authorities, and delegated issuance paths used by Node.js clients. That work is broader than this CVE, but the vulnerability provides a concrete reason to ask whether certificates with address-like DNS SANs are still necessary.
Application behavior that raises risk
The Node.js runtime flaw becomes a security incident only when an application reaches the affected verification path. Look for destinations that can be influenced by a tenant, administrator, integration, webhook, import, or configuration API. Also review connectors that accept an arbitrary endpoint and then attach credentials or sensitive data.
An application that always contacts a fixed DNS name has a smaller practical attack surface. An application that accepts a full URL, extracts its host, connects with Node.js TLS, and sends an API token has a much clearer identity dependency. The certificate certificate requirements still apply, but the attacker's ability to choose the destination representation matters.
Do not infer vulnerability from a hostname that happens to contain Unicode. Trace the exact value through URL parsing, validation, DNS resolution, and the TLS call. Record whether the application expects a DNS name, an IP address, or both, and whether the expected identity is checked after normalization.
Affected versions and deployment visibility
The official affected range is Node.js 24.x before 24.22.1 and 26.x before 26.12.1. The 22.x line received other security fixes in the same release cycle but is not listed as affected by this CVE. Check the actual process version and the container image digest. A lockfile, package manifest, or base-image tag is supporting evidence, not proof of what runs.
This matters in long-lived deployment systems. A service can inherit a patched image name while an old layer or sidecar still runs a vulnerable binary. Build attestations and runtime version reporting should agree before a team marks the deployment complete.
Exposure has a limited meaning
ZoomEye Search app="Node.js" returned 5,539,674 matches at 04:17 +08:00 on November 2, 2026. The CVE filter returned zero. Exposure is 5,539,674 because the policy selects the greater verified query count. These are product fingerprints, not vulnerable installations.
Use the figure to frame internet-scale relevance, not to assign incident status. A Node.js fingerprint cannot reveal the exact release, the trust store, the application's destination validation, or whether the vulnerable certificate path is reachable. Those facts belong in internal evidence.
Remediation
Upgrade to 24.22.1, 26.12.1, or a later maintained release. Rebuild and redeploy every artifact that embeds Node.js. Verify the running version after rollout and retain the evidence with the change record.
Review certificate profiles for address-like DNS SANs, especially in internal PKI and test environments. Require applications to canonicalize destinations before policy checks, reject inputs that are neither approved DNS names nor canonical IP addresses, and avoid custom certificate verification that skips the standard hostname check.
Finally, test with certificates that isolate the behavior: one with only a numeric DNS SAN, one with a matching IP SAN, and one with neither. A patched client should accept only the certificate whose identity matches the intended endpoint type. Keep the test local and controlled, and do not use production trust anchors.
