Quick answer: The Node.js 2026-10-21 security release closed two HIGH and one MEDIUM TLS hostname verification bypass flaws. CVE-2026-105483 abuses an IP address written with fullwidth Unicode digits, CVE-2026-106069 abuses a host value that resolves loosely to an IP address, and CVE-2026-106072 abuses non canonical IPv4 formats. In each case your application can treat a certificate that does not belong to the server it is actually talking to as valid. The fix is not in your configuration but in the runtime, so you must upgrade to v22.23.4, v24.22.1, or v26.12.1.

During a TLS handshake the lock icon answers two separate questions. First, is the certificate signed by a trusted authority. Second, was that certificate really issued for the host you are connecting to right now. The second check is hostname verification, and most people never think about it because the library does it silently. The three flaws in the Node.js October 2026 release target exactly that second check. The certificate is valid, the chain is clean, yet the host comparison can be bypassed. This article focuses only on these three flaws, because on their own they form a distinct class of threat.

What hostname verification is and why it matters

When a client connects to example.com the server presents a certificate. The Subject Alternative Name (SAN) field of that certificate lists which host names or IP addresses are valid for it. The client's job is to compare the target it connected to against that list. When the comparison is done correctly, an attacker cannot slip in a valid certificate issued for a different domain, because the host will not match.

The problem is that host comparison is a text and address parsing task. Whether a value is an IP address or a domain name, how it is normalized, which characters count as digits, all of these create edge cases. If the parser interprets a value one way while the verification layer interprets it another way, an attacker can live in the gap between them. All three CVEs arise from exactly this kind of interpretation difference. The certificate itself is not forged, the identity of the target is matched incorrectly. We cover the broader fundamentals in our TLS SSL configuration and hardening guide.

How the two HIGH flaws work

CVE-2026-105483 abuses the case where an IP address is written with fullwidth Unicode digits. A normal IP address consists of ASCII digits. However Unicode includes fullwidth characters that look like digits visually but carry different code points. As the verification logic normalizes these characters, the layer that reads the address as an IP and the layer that compares it against SAN records can produce different results. As a result a host is treated as matching a certificate it should not match. This flaw affects the 26.x and 24.x lines.

CVE-2026-106069 targets a host value that resolves loosely to an IP address. When the host the client connects to is interpreted as an IP address in a non standard but tolerated form, hostname verification evaluates that value in the wrong category. The distinction between whether a certificate was issued for an IP or a domain name becomes blurred, and verification can be bypassed. This flaw affects all of the 26.x, 24.x, and 22.x lines, so its scope is wider. Both are classified HIGH because the outcome is the same, the channel you trust is not actually secure.

106072 and the non canonical IPv4 problem

The MEDIUM level CVE-2026-106072 concerns non canonical IPv4 hostname formats that are not verified correctly. IPv4 addresses can be written not only in dotted decimal form but also in octal, hexadecimal, or as a single integer. These forms are historically accepted as valid by many parsers. If the verification layer does not reduce these forms to the canonical form, DNS type SAN records can behave as though they validate an IP endpoint, and an unexpected match occurs. Although its severity is lower, it belongs to the same family and is closed by the same upgrade.

Man in the middle risk and honest limits

The practical consequence of these flaws is a man in the middle (MITM) attack. When your application connects to an external service, for example a payment provider or an API, an attacker who can interpose places their own server in the middle and presents a valid certificate issued for a different host. Hostname verification normally rejects this trick. With these flaws it may not reject it, so the attacker reads or modifies the traffic while you still believe you are connected securely.

An honest note is needed. These affect the client side, that is the outbound connections your application establishes. Exploitation requires the attacker to hold a MITM position on the network path, which is not easy in every scenario, but is realistic on corporate networks, shared Wi-Fi, a compromised intermediate node, or through DNS manipulation. At the time of release, claims of widespread active exploitation of these flaws are limited and official confirmation is narrow. Still the risk is not theoretical, because the defect is not in your code but in the runtime verification logic, and the patch is the only real fix. You can see how mutual authentication strengthens this picture in our article on mTLS and two way TLS.

The three TLS flaws at a glance

Identifier Severity Triggering condition Affected lines
CVE-2026-105483 HIGH Hostname verification bypass when an IP address is written with fullwidth Unicode digits 26.x, 24.x
CVE-2026-106069 HIGH Hostname verification bypass when a host resolves loosely to an IP address 26.x, 24.x, 22.x
CVE-2026-106072 MEDIUM Non canonical IPv4 formats not verified, DNS SAN records may validate IP endpoints 26.x, 24.x, 22.x

What to do

The only certain step you need to take is to upgrade. These flaws are not closed by configuration, because the problem is not in your settings but in the runtime host comparison logic. If your node -v output is older than 22.23.4, 24.22.1, or 26.12.1, move to the patched release on the same line. If you use containers, rebuild the base image, because a team update alone does not change the production environment. If you are on an unsupported line such as Node 18 or 20, these flaws affect you too but you will not receive a patch, in which case migration is mandatory, a topic we detail in our article on EOL runtime risk.

After upgrading, review the services that make outbound connections, especially payment, identity, and third party API calls. If you want to address the whole October release as a unit, our Node.js October 2026 security update patch guide covers the other nine fixes as well. To harden your server side TLS termination, our web server hardening guide is a useful complement.

The KAOS and DSET approach

KAOS, DSET's local artificial intelligence engine, follows an evidence based sequence when detecting flaws like these. First it identifies the runtime version on the target, then it maps that version to known CVE records, then it compares exploitability and priority against the KEV list and similar sources. For example when it sees a service running on the 22.x line, it produces a may be affected hypothesis for CVE-2026-106069, because that line is in scope.

Honesty matters here. A version match is a hypothesis, not a definitive confirmation of a vulnerability. A distribution may have backported the patch or a mitigation may be in place. KAOS therefore has an over claim brake, meaning it does not use definitive language without evidence. For flaws like TLS hostname bypass, definitive confirmation requires active verification in a controlled environment, which we perform only with explicit authorization and in a safe manner. The goal is not fear but a risk picture that can be prioritized and verified.

Frequently asked questions

If the certificate is valid, how is a hostname verification bypass possible? Because a certificate being valid and it being issued for the right host are two separate checks. In these flaws the chain validation works fine, and the certificate the attacker presents may be real and signed by a trusted authority. What is bypassed is the second step that checks whether that certificate actually belongs to the host you connected to. Because of interpretation differences, the wrong host is accepted as correct.

Do these flaws target my server directly? No, these are primarily client side flaws. The risk lies in the TLS connections your application establishes outward, for example calls you make to an API or payment provider. For an attacker to exploit this, they must reach a man in the middle position on the network path. Even so the outcome is serious, because data can leak or be modified over a channel you believed to be secure.

Would it be enough to just change the configuration? No. The root of these flaws is in the runtime host comparison logic, not in your TLS settings. Tightening the cipher list or raising the protocol version does not close these specific bypasses. The only reliable fix is to move to a patched Node.js release. Configuration hardening is a separate and valuable defense, but it does not substitute for these patches.

Sources

To assess TLS verification bypass flaws in your organization, map affected connections, and prioritize patching, contact DSET. Our team is located at Ankara Hacettepe Teknokent and provides evidence based security assessment for enterprise infrastructures.