CVE-2026-106072: inventory and logging gaps around alternate IPv4 forms

CVE-2026-106072 highlights inventory and logging gaps related to alternate IPv4 forms in Node.js. The vulnerability arises when a Node.js client processes non-canonical IPv4 host addresses during TLS configuration. The upstream fix is included in Node.js versions 22.23.4, 24.22.1, and 26.12.1. However, identifying affected code paths demands more than just searching for the product name.

Teams require a runtime inventory to pinpoint where address literals enter TLS configuration and logs that preserve both raw and normalized values. The vulnerable verifier fails to classify alternate IPv4 forms as IP addresses before certificate matching. Instead, it normalizes them and checks DNS Subject Alternative Names (SANs) rather than necessitating an IP Address SAN. Examples given include 0177.0.0.1, 0x7f.0.0.1, 2130706433, and 127.1. These forms can also be accepted by glibc.

The attack hinges on having a trusted certificate with a numeric DNS SAN. Current logging practices, which focus solely on the canonical address, can obscure the input that triggered the vulnerable branch. Conversely, logging only the raw string can complicate correlation and remediation efforts. This logging gap can delay detection and obscure the extent of a trust failure.

If an application normalizes the address before logging, investigators might be unsure whether the client used a standard IP, an alternate form, or a certificate DNS SAN. This uncertainty impacts certificate review and incident reconstruction.

The flaw is fundamentally a TLS hostname-verification issue, not evidence of an actual compromise. The recommended logging strategy aims to make the security decision visible, not to assert an unsupported claim about a breach. Affected Node.js versions include 22.x, 24.x, and 26.x. It's crucial to scan all runtimes that function as TLS clients, including scheduled jobs and tools outside the main web service. Checking container images and local executables for version drift is also advised.

To address the exposure, a ZoomEye search for Node.js applications returned 5,539,569 application fingerprint matches as of November 1, 2026. However, this figure represents Node.js product fingerprints, not confirmed vulnerable installations. The count indicates potential vulnerabilities but does not confirm reachability or risky configuration of affected TLS clients. The ZoomEye search is meant as a starting point for version and code-path checks, not a definitive verdict on vulnerability.

The proposed remediation involves upgrading the runtime and adjusting logging to retain the original host string, parsed host type, canonical address when available, and the certificate SAN type used for decision-making. Secrets should be redacted, and logging should avoid capturing certificate private data. A regression test and configuration check for non-canonical addressing should be implemented.

If the application cannot reject these inputs, they should be converted through a documented parser before TLS and recorded accordingly. Dashboard or alert updates that rely on the old unnormalized field should be recreated to maintain auditability.