A regression test for CVE-2026-105483 should prove that an address remains an address throughout destination parsing and certificate validation. Affected Node.js 24.x and 26.x releases could normalize and resolve a fullwidth-digit IPv4 host while tls.checkServerIdentity() compared the peer certificate against DNS names. A certificate with a numeric DNS SAN could therefore authenticate an IP endpoint without a matching IP SAN.
Node.js fixed the behavior in 24.22.1 and 26.12.1. The issue is rated High, with CVSS v3.0 7.4 and CWE-295. Tests need to distinguish the vulnerable runtime from a correct rejection, not simply confirm that a TLS client can connect.
Test the identity decision
Use a private test CA and a local TLS endpoint. The endpoint should resolve to a controlled IPv4 address. Build a certificate whose only matching identity is a DNS SAN containing the canonical address, such as 127.0.0.1. Do not include an IP address SAN for that endpoint.
Connect with a fullwidth-digit host that normalizes and resolves to the same IPv4 address. The expected result on a fixed runtime is a certificate identity failure. The vulnerable runtime could accept the certificate because it treated the destination as DNS. The test should assert rejection and the error class, not merely fail on a timeout.
Add two controls:
A certificate with the correct IP address SAN should be accepted for a canonical IP destination.
A certificate with a DNS SAN for a normal name should be accepted only for that name.
The controls keep the negative test meaningful. If every certificate is rejected because the trust fixture is wrong, the test can pass for the wrong reason.
Test the deployed artifact
A test against the developer workstation's runtime does not prove that a container, packaged executable, or appliance uses the same version. Run the identity test in the artifact that will be deployed. Report the runtime version, image digest, and test result together.
For single executable applications, verify that the embedded runtime is updated as part of the build. For containers, check the final process environment and layer provenance. For managed platforms, use the runtime evidence exposed by the provider and retain the deployment revision.
The affected ranges are Node.js 24.x before 24.22.1 and 26.x before 26.12.1. The 22.x line is not listed as affected by this CVE. A test suite should skip no supported line based on assumption; it should use a fixture matrix that reflects the actual vendor advisory.
Include hostile input forms
The official advisory identifies the fullwidth-digit form. Additional tests should cover mixed-width digits, leading zeroes, alternate IPv4 spellings, and ordinary DNS names. The goal is to verify the application's policy after normalization, not to assert every form has the same parser behavior.
Each test needs an expected result defined by the application. If the policy permits only canonical DNS names and canonical IP literals, ambiguous forms should be rejected before TLS. If the application accepts an IP address, it should require an IP SAN. If it accepts a DNS name, it should require the approved DNS identity.
Keep the certificate fixtures versioned with the test. Do not generate a new CA and certificate on every run unless the test verifies the fixture hashes. A silently changed certificate can remove the condition under test without anyone noticing.
Instrument failures
Log the destination class, canonicalized address or name, certificate SAN types, verification outcome, and runtime version. Do not log private keys, full session secrets, or complete request bodies. The log should let an investigator distinguish a malformed input, a certificate mismatch, and a network failure.
Alert on repeated identity failures tied to one destination source. If a tenant, connector, or configuration object starts producing unexpected address forms, that pattern may require review even if the fixed runtime rejects the connection.
Exposure context
ZoomEye Search app="Node.js" returned 5,539,674 product fingerprints at 04:17 +08:00 on November 2, 2026. The CVE filter returned zero. The selected Exposure is 5,539,674 and describes Node.js matches, not confirmed vulnerable processes. It cannot replace the artifact test, runtime version check, or destination-policy test.
Release gate
A service should not be closed on a green unit test alone. Require the fixed runtime in the deployed artifact, a passing negative certificate test, two positive controls, and runtime evidence attached to the rollout. After deployment, verify the version again and keep the test in the build so a base-image rollback is caught before release.