Topic starter
11/11/2026 6:02 pm
TL;DR: Malformed IPv4 literals can bypass Node.js hostname validation, according to Upwind, because non-ASCII digits and leading zeros are parsed inconsistently. TLS clients then trust the wrong endpoint, so certificate checks stop protecting the connection.
Editorial analysis by NHI Mgmt Group, based on content published by Upwind: “Multiple CVEs - Node.js TLS hostname verification and IP normalization flaws enable MITM and certificate bypass”.
Key questions
Q: Why can certificate checks still fail against man-in-the-middle attacks?
A: Certificate checks can still fail when the client accepts a certificate chain without verifying the hostname, trust anchor, expiry, or revocation status.
Q: How should teams handle canonicalisation in service-to-service TLS?
A: Teams should normalise hostnames to a single canonical form before comparison, then verify that form against the certificate's subject alternative name or common name.
Q: How do malformed IP literals affect TLS hostname verification?
A: Malformed IP literals can make hostname verification compare the certificate against the wrong identity if parsing logic treats the address as a different host form.
Practitioner guidance
- Reject non-canonical IP literals at ingress Block leading-zero, mixed-format, and non-ASCII IPv4 representations before they reach application or library-level hostname checks.
- Upgrade affected Node.js runtimes immediately Move to 22.23.4, 24.22.1, or 26.12.1 or later in the supported line before relying on current hostname verification behaviour.
- Audit service-to-service TLS assumptions Review where internal workloads depend on default certificate validation and confirm that host canonicalisation is deterministic end to end.
Bottom line: Malformed IP handling can undermine TLS even when certificates are valid, because the client may verify the wrong endpoint.
Glossary terms: TLS Hostname Verification, CVE-2026-105483, CVE-2026-106069, Certificate Validation Bypass
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:06 pm
Hostname canonicalisation is a security control, not a parsing detail. Upwind's findings show that TLS can fail safely only when the application and the verification library agree on exactly which endpoint is being checked. If the address is ambiguous, certificate validation becomes a policy decision built on unstable input. Practitioners should treat malformed IP handling as part of the trust boundary, not as a cosmetic input issue.
A few things that frame the scale:
- According to the 2023 State of Machine Identity Management report, only 47% of companies have enough staff dedicated to their PKI.
A question worth separating out:
Q: What signs suggest TLS hostname validation is being bypassed?
A: Signs include accepting certificates for a different hostname, logging requests with mixed or reformatted host values, and treating IP literals or encoded addresses as equivalent to a name without normalisation. Unusual IPv4 encodings, such as non-decimal forms, are a common clue that hostname validation or canonicalisation is being bypassed.
👉 Read our full editorial: Node.js TLS hostname flaws let malformed IPv4 literals bypass checks