The fix for CVE-2026-106069 changes behavior for a narrow class of IP address spellings. That makes regression testing valuable. A team can deploy Node.js 22.23.4, 24.22.1 or 26.12.1 and still have an integration that relies on a permissive parser, a custom resolver or a proxy that rewrites the destination.
The Node.js advisory describes a TLS certificate bypass involving a non-canonical IPv4 literal with a leading zero. Node.js normalizes 0127.0.0.1 to 87.0.0.1 under WHATWG URL rules, while an operating-system resolver on some platforms reads it as 127.0.0.1. The certificate can match the normalized address while the connection reaches a different peer. Node.js rates the issue High, and Red Hat records CVSS 3.1 score 7.4 for CWE-297.
Test the application boundary
Begin with the API or job path that accepts a destination. Send a canonical IP, a canonical hostname and a non-canonical numeric host. Assert that the ambiguous host is rejected or normalized once by the reviewed policy. Then verify the exact value passed to the TLS client.
This step catches a common gap. A test may call a small Node.js script that rejects 0127.0.0.1, while the production application's URL parser accepts it as a decimal address and passes a different value to the client. The test should assert both the application response and the connection attempt's normalized peer.
For tenant-facing integrations, test redirects and nested URLs. A redirect can introduce a new host after the initial check. If the application follows redirects, the test should prove that each new destination passes the same policy. Store the injected address in test data and keep secrets out of the fixture.
Use a controlled TLS peer
A useful regression test needs a local or isolated TLS service whose certificate identifies the normalized address. The test should show that the vulnerable client accepts the mismatched peer condition and the fixed client rejects the ambiguous host. A certificate with an unrelated DNS name does not exercise the advisory's IP SAN condition.
Run the test on each supported operating system and resolver. Node.js asks for network behavior, and a test that passes on one platform may not exercise a differing resolution rule. Container images, macOS laptops and Linux servers can produce different results. Document which platform each result covers.
Do not weaken the production trust store to make the test pass. Use a dedicated test certificate authority and a temporary trust setting that exists only in the test environment. Remove the CA and test key material after the test, and avoid recording private material in logs.
Exercise custom clients
Review code that supplies lookup, agent or checkServerIdentity to Node.js. A custom resolver can turn an ambiguous host into a different address. A custom verification callback can add a trust decision or bypass one. Run the regression suite against the exact options used in production.
Proxy behavior needs its own test. An application-level proxy may receive a hostname and resolve it independently. A forward proxy may connect to the original IP literal. Verify whether the proxy preserves the peer identity expected by the client and whether it rejects non-canonical forms.
Include service-mesh and library callbacks in the same review. A patched process can still be affected by a component that completes the TLS handshake elsewhere. The test should show where the certificate validation occurs and which component supplies the address.
Verify the effective runtime
The fixed thresholds are 22.23.4, 24.22.1 and 26.12.1. Build the test image with the same runtime as production and report the version from inside the process. Check the container command and entrypoint because a bundled executable can ignore a newer file in the image.
After deployment, run the non-canonical test against a canary. Confirm that the new behavior is present and that a canonical connection still succeeds. Watch for a load balancer or proxy that returns a generic error before the application reaches its own test path.
Use Exposure only as a lead
The ZoomEye query app="Node.js" returned 5,539,361 matches on November 1, 2026. The CVE filter returned zero. Exposure uses the larger selected count, but it is a product fingerprint measurement. It can point to Node.js services that need testing, not to systems confirmed vulnerable by this test suite.
Keep test evidence in the service record: runtime version, platform, resolver, proxy path, certificate validation layer and result. A future runtime or network change can invalidate an old pass. Add the leading-zero case to CI and run it whenever those dependencies change.
The regression test should also prove that a failed validation stops the request. A connection that is rejected after data has already been sent is not equivalent to a check before the TLS client opens the socket. Review the order of validation, logging and request construction.