A runtime patch closes CVE-2026-105483, but an audit can still reveal applications whose architecture makes the same identity mistake easy to repeat. The bug affected Node.js 24.x and 26.x before 24.22.1 and 26.12.1. A fullwidth-digit IPv4 host normalized and resolved as an address while tls.checkServerIdentity() evaluated it as a DNS name. A trusted certificate with a matching DNS SAN could authenticate the wrong IP endpoint.
Node.js rates the issue High. The GitHub advisory lists CVSS v3.0 7.4 and CWE-295. The audit should establish where destination identity becomes security-sensitive, then confirm that those paths run on a fixed runtime and use the intended identity type.
Start with the trust decision
Search the codebase for direct use of tls.checkServerIdentity(), custom checkServerIdentity callbacks, and TLS clients that accept destination values from outside the service. Include HTTP clients built on top of the standard TLS stack and integrations that create connections from user or administrator configuration.
The direct search is only a starting point. Many applications never name checkServerIdentity; they rely on a standard client to call it. Review the path that supplies the host value. Does it come from a fixed allowlist, a generated service name, a tenant configuration object, a callback URL, or a command-line argument? Each source has a different threat model.
For each sensitive path, write down four facts:
The expected destination type: DNS name, IPv4 address, or both.
The normalization performed before the connection.
The validation performed after normalization.
The trust store and certificate profile required by the server.
If the application expects an IP address but only validates a textual DNS-like value, the identity policy is incomplete even after the runtime update.
Review normalization at the boundary
Unicode presentation can change while the underlying destination meaning stays the same. Official Node.js guidance confirms that fullwidth-digit hosts normalized and resolved as IPv4 in the vulnerable path. Code reviews should therefore avoid comparing a raw host string with a canonical host and assuming both checks describe the same value.
Prefer a small, explicit destination policy. Accept approved ASCII DNS names through an allowlist, or accept a canonical IPv4 literal after parsing and validation. Reject ambiguous mixed representations instead of trying to normalize them into a broader destination language. The application's policy should be narrower than the parser's full input grammar.
This is a mitigation, not a replacement for 24.22.1 or 26.12.1. A patched runtime is the authoritative fix. The application restriction prevents new ambiguous inputs from reaching sensitive clients and makes future regressions easier to test.
Review custom verification callbacks
A custom callback can intentionally support private names, internal addresses, or application-specific identity metadata. It can also silently remove the standard checks. Inspect whether the callback:
Uses the parsed destination rather than the original unnormalized string.
Requires an IP SAN when the intention is to contact an IP address.
Accepts a DNS certificate only when the destination is an approved DNS name.
Rejects a mismatch instead of logging it and returning success.
Preserves all required certificate validation steps.
Any callback that returns success based only on an application label, a hostname substring, or a certificate Common Name is a candidate for redesign. This review should not rely on a text search alone because wrappers and helper libraries can obscure the TLS call.
Prioritize credential-bearing clients
The advisory assigns high confidentiality and integrity impact, but the operational severity depends on what crosses the connection. A metadata request can disclose service behavior. A signed API request can expose credentials or modify state. A management client can carry broader authority than its destination suggests.
Rank clients by the secrecy of the request, the authority of the response, and the attacker's ability to influence the destination. A low-volume internal integration that carries an administrative token may deserve more attention than a high-volume public read-only client.
Verify deployed artifacts
The affected versions are precise enough to make inventory feasible. Node.js 24.x before 24.22.1 and 26.x before 26.12.1 need to move to a fixed release. Check runtime output, container image layers, SEA packaging, and any embedded Node.js distribution. A source repository can be clean while a release artifact remains affected.
Record the runtime version before and after rollout. If the service exposes that information internally, compare it with the deployed image digest. If it does not, use the packaging and process inspection available to the operator instead of inferring the version from a package name.
Exposure and code evidence
At 04:17 +08:00 on November 2, 2026, ZoomEye Search app="Node.js" returned 5,539,674 product matches and the CVE filter returned zero. The selected Exposure is 5,539,674 Node.js fingerprints, not confirmed vulnerable processes. Use the number to understand the technology population and internal code evidence to decide which services can reach the vulnerable path.
Completion criteria
Consider the audit complete when every sensitive TLS client has a documented expected identity type, an explicit normalization and allowlist policy, and a test that rejects a certificate with the wrong SAN class. Confirm the running runtime is 24.22.1, 26.12.1, or later, and retain the rollout evidence. A clean scan is useful only when the scanned artifact and the deployed process are the same one.