The fastest accurate response to CVE-2026-105483 starts with the runtime version and ends with evidence that the deployed client rejects the wrong certificate identity. The bug affects Node.js 24.x before 24.22.1 and 26.x before 26.12.1. During TLS verification, a fullwidth-digit IPv4 destination could be normalized and resolved as an address while DNS names were checked against the certificate. A trusted certificate with a matching DNS SAN could authenticate an IP endpoint without an IP SAN.
Node.js fixed the issue on October 21, 2026. It is rated High, with CVSS v3.0 7.4 and CWE-295. The checklist below separates the mandatory runtime fix from application hardening and assurance work.
1. Identify the running runtime
List every Node.js process that performs TLS or embeds a runtime. Record the exact version, artifact digest, environment, owner, and deployment time. Check containers, packaged executables, desktop tools, CI utilities, and appliances in addition to web services.
Do not close the inventory on a lockfile alone. Verify the process or the signed package that actually runs. A base-image name and an application dependency can both disagree with the executable serving traffic.
2. Upgrade the affected range
Move 24.x systems to 24.22.1 or later and 26.x systems to 26.12.1 or later. Rebuild images and redistributed packages. For single executable applications, verify the embedded runtime version in the new build.
Replace old workers, sidecars, and long-lived processes. Confirm the fixed runtime is active after rollout and retain the runtime evidence with the release record.
3. Find security-sensitive destinations
Review clients that accept a destination from tenants, users, integrations, configuration APIs, queues, or imported records. Prioritize clients that send credentials, administrative commands, private data, or signed requests.
For each client, record whether the intended destination is a DNS name, an IP address, or both. Then trace normalization and validation to the exact TLS call. A policy that checks one string while the client connects with another is not a complete control.
4. Narrow destination input
Allow approved ASCII DNS names or canonical IP literals. Reject ambiguous fullwidth-digit forms, mixed representations, and unapproved redirects before invoking the TLS client. Require a DNS SAN for a DNS identity and an IP address SAN for an IP endpoint.
Avoid custom checkServerIdentity callbacks that accept a certificate based on a display label, a Common Name, or a substring. If a callback is necessary, preserve the correct SAN class and all standard certificate validation.
This input policy is supporting mitigation. The patched runtime remains mandatory.
5. Review trust anchors
Identify which CAs can issue certificates to the affected clients. Include internal roots, test roots, delegated intermediates, and service-mesh trust bundles. Ask whether any of those authorities can issue an address-like DNS SAN that ships inside a trusted chain.
Limit client trust to the authorities required for its destinations. A broad trust store increases the practical conditions for the vulnerability and complicates incident analysis.
6. Test the identity boundary
Use a private test CA and a local endpoint. Create a certificate with a numeric DNS SAN and no matching IP SAN. Connect with a fullwidth-digit host that resolves to the test address. The fixed runtime should reject the certificate because the endpoint is an IP address.
Add positive controls:
A matching IP SAN should succeed for the IP endpoint.
A normal DNS SAN should succeed for an approved DNS name.
An unapproved destination should fail application policy before TLS.
Run the test in the actual deployable artifact. Keep the fixtures versioned so a certificate change cannot weaken the test silently.
7. Record exposure correctly
At 04:17 +08:00 on November 2, 2026, ZoomEye Search app="Node.js" returned 5,539,674 matches. Filter vul.cve="CVE-2026-105483" returned zero. Exposure is 5,539,674 Node.js product fingerprints, not confirmed vulnerable assets.
Use the external count for population context. Use runtime, destination policy, certificate trust, and business authority for prioritization. Do not describe a fingerprint as a victim.
8. Monitor after the change
Log certificate identity failures, destination policy rejections, runtime versions, and changes to destination configuration. Distinguish a DNS failure, a chain failure, and a SAN mismatch. Alert on the introduction of previously unapproved destination forms or trust anchors.
If evidence indicates that a client reached an unintended endpoint, preserve the configuration and connection records, determine what data crossed the session, and follow the credential-rotation and incident process. The advisory does not state that exploitation has occurred; the organization must reach its own conclusion from its evidence.
9. Close with proof
An affected service is ready when the running artifact reports a fixed Node.js version, the test proves the correct SAN class is enforced, the destination input policy is deployed, and the old process is no longer serving traffic. Save those artifacts with the change record so a later reviewer can distinguish a patched runtime from a clean-looking package manifest.