Certificate validation is often summarized as checking a chain to a trusted root. CVE-2026-105483 shows the missing second half: the certificate must identify the endpoint the client intended to reach. In affected Node.js 24.x and 26.x releases, a fullwidth-digit IPv4 host normalized and resolved as an address while tls.checkServerIdentity() checked DNS names and the Common Name. A trusted DNS certificate could authenticate the wrong IP endpoint.
Node.js fixed the problem in 24.22.1 and 26.12.1. It is rated High, with CVSS v3.0 7.4 and CWE-295. The chain can be cryptographically valid and still be the wrong identity for the connection.
Trust and identity are separate checks
A trust store answers whether a certificate chain reaches an authority the client accepts. Identity verification answers whether the certificate names the peer the client meant to contact. Both checks must pass.
For a DNS destination, a DNS SAN is the normal identity. For an IPv4 destination, an IP address SAN is the corresponding identity. Numeric strings can look like names to one parser and addresses to another. CVE-2026-105483 exploited that gap in classification and normalization.
The certificate's Common Name can add confusion. Modern identity validation should use the applicable subject alternative names, not treat a familiar Common Name as a general-purpose match. Applications that add custom callbacks must preserve the SAN-class rule for the intended destination type.
What an attacker gains
The vulnerability matters when the client sends sensitive material after the handshake. A correctly signed certificate for the wrong identity can let an attacker-controlled endpoint receive API credentials, private data, or administrative requests. The response may also be accepted as authoritative, affecting integrity.
The attacker still needs a trusted chain, a suitable DNS SAN, and influence over the destination or network path. High attack complexity in the CVSS vector reflects those constraints. This is not a reason to dismiss the bug. It means security teams should prioritize systems where the preconditions overlap with valuable traffic.
Where the risk concentrates
Clients that accept destinations from external users or partner systems create the clearest review case. Integrations that import a URL, connector configuration that sends a token, and administrative tools that contact arbitrary endpoints can combine destination influence with high authority.
Private certificate authorities can change the risk picture. A public CA may have issuance controls around address-like DNS names. An internal CA might issue them for test systems, appliances, or legacy naming schemes. Review the actual certificates that Node.js clients trust rather than asking only whether the public Web PKI is affected.
What not to conclude
A public Node.js fingerprint is not a compromised host. ZoomEye Search app="Node.js" returned 5,539,674 matches at 04:17 +08:00 on November 2, 2026, while Filter vul.cve="CVE-2026-105483" returned zero. Exposure is the larger count, 5,539,674 product fingerprints. The query does not show the running version, certificate policy, or whether an attack occurred.
A trusted certificate is not proof of a benign connection. A certificate mismatch is not proof of compromise either. The decision depends on the intended identity, the destination input, the trust path, and evidence from the application and network.
Remediation
Upgrade to Node.js 24.22.1, 26.12.1, or later. Verify the runtime inside the deployed artifact. Review custom certificate verification callbacks and remove any logic that accepts a DNS name for an IP endpoint. Require the standard IP SAN check when the destination is an address.
Narrow input policy to canonical DNS names or canonical IP literals. Reject ambiguous shapes before connection setup. This application control does not replace the patched runtime, but it reduces exposure to future parser inconsistencies.
Test both sides of the identity boundary. A trusted certificate with the wrong SAN class must fail. A certificate with the expected SAN class must still work. The test should use a private CA and local endpoint so it is repeatable and does not depend on public issuance.
Operational questions
Ask which systems can choose a destination, which credentials they attach, and which trust authorities can issue an address-like DNS identity. Ask whether logs distinguish a failed chain from a failed identity and whether operators know which runtime version served the request.
Those questions take the discussion beyond a vulnerability score. CVE-2026-105483 is a concrete example of why trusted and correct are different security properties. The certificate must be valid for the identity the application intended, not merely valid somewhere in the client's trust store.