IT adminsServers & enterprise software

Node.js Fixes DNS and TLS Verification Flaws

Published · Node.js · 3 CVEs · NVD and CISA KEV checked October 30, 2026

Illustration of a server rack and a database with a shield

In short Node.js updates address DNS hostname handling and TLS certificate checks that can cause applications to trust the wrong destination.

What happened

Node.js has addressed security flaws in its Node.js runtime involving how applications resolve hostnames and verify server identities. Think of checking the address on a package, then having the delivery service interpret that address differently: the check can look correct while the package goes somewhere else. Here, differences in how software components interpret a hostname or IP address can undermine an application's security checks.

The vendor advisory covers CVE-2026-105482, CVE-2026-105483 and CVE-2026-106069. The DNS issue can make an application resolve a different hostname from the one it approved. The TLS issues can cause an application to accept a server certificate that does not correctly identify the connected IP address. NVD published the entries on 2026-10-23 and rates each HIGH, with a CVSS score of 7.4. The fixed releases are 22.23.4, 24.22.1 and 26.12.1, with coverage depending on the vulnerability and release line.

Technical details

CVE-2026-105482 is classified as CWE-284, Improper Access Control. DNS, the system that translates hostnames into network addresses, is the boundary involved. The dns.resolve*() functions and dns.reverse() can accept a hostname containing a NUL byte, a character that marks the end of a string in C. When Node.js passes that name to the c-ares resolver library, the library reads only the portion before that character. An application can therefore validate the complete name against an allowlist of permitted domains but receive DNS records for the shorter name instead. Exploiting that mismatch requires attacker-influenced input to reach an affected function through an application workflow that relies on the earlier validation. This extends an earlier fix that covered other hostname-handling interfaces.

CVE-2026-105483 is classified as CWE-295, Improper Certificate Validation. TLS, the protocol used to secure connections and authenticate servers, depends on checking a certificate against the intended destination. Node.js tls.checkServerIdentity() can misclassify an IP address written with non-ASCII characters, such as fullwidth digits, as a DNS hostname. It then checks certificate DNS names or the Common Name instead of requiring a matching IP address entry in the certificate's Subject Alternative Name, or SAN, field. The failure requires a specially written destination address and a certificate whose name fields satisfy the mistaken hostname check. The advisory describes this as a regression after an earlier fix.

CVE-2026-106069 also falls under CWE-295, Improper Certificate Validation. Its root cause is inconsistent interpretation of an unusual IPv4 address containing a leading zero. The certificate-checking code applies URL normalization rules that interpret the affected address component as octal, while the operating system resolver on some platforms can interpret it as decimal. Consequently, the connection and certificate check can refer to different IP addresses. Under those conditions, a server at the connected address can be authenticated using a certificate issued for the other address. Platform behavior matters; the description does not establish that every operating system interprets the address this way.

Each vulnerability has a CVSS 3.0 score of 7.4 and a HIGH severity rating in NVD. CVSS is a standardized measure of technical severity, not a measurement of how frequently a flaw is being exploited or a prediction that every application is exposed. Actual exposure depends on the affected runtime, the application interfaces used, the destination input and, for the leading-zero issue, resolver behavior.

Who is affected

Everyday users

For everyday users, the relevant question is whether an application or service you use runs an affected Node.js version and reaches the vulnerable behavior. These issues concern software interpreting network destinations incorrectly; they do not establish that every application using Node.js will accept an incorrect destination or certificate.

If someone else operates the application, that provider is responsible for updating its runtime. If you maintain an application yourself, check the Node.js version it actually runs. A version check on your personal computer does not establish which version a remote service uses.

Developers

Developers should review code that accepts destination names and then uses dns.resolve*(), dns.reverse() or TLS server identity verification. For the DNS flaw, pay particular attention to workflows that approve a hostname before resolving it. A security decision based on the complete input can become ineffective when the resolver uses only part of it.

For the TLS flaws, review whether externally influenced host values can contain non-ASCII address characters or leading-zero IPv4 notation. The concern is disagreement between address interpretation and certificate verification. Updating the runtime addresses the reported flaws; application review helps identify where those assumptions affect your own security boundaries.

Server and IT admins

Server and IT administrators should inventory the Node.js runtimes used by deployed services and compare each with its corresponding fixed release. For CVE-2026-105482 and CVE-2026-106069, the listed fixes are 22.23.4 and later, 24.22.1 and later, and 26.12.1 and later within their respective release lines. For CVE-2026-105483, the affected-version entries cover the release lines fixed by 24.22.1 and 26.12.1; the advisory does not list the release line fixed by 22.23.4 for that CVE.

Prioritize services whose destination inputs can be influenced by untrusted parties and whose access decisions depend on hostname approval or certificate identity checks. None of these CVEs is listed in CISA's Known Exploited Vulnerabilities catalog, or KEV, as of the catalog check. That catalog status is not a finding about whether exploitation has occurred.

What to do now

  1. Identify the Node.js version used by each application you maintain. Use the allowed version-check command where the relevant runtime is available, and distinguish local installations from deployed service runtimes.
  2. Match each runtime to its release line. For CVE-2026-105482 and CVE-2026-106069, versions earlier than 22.23.4, 24.22.1 or 26.12.1 are affected within the corresponding release line.
  3. Account for the narrower scope of CVE-2026-105483: the advisory lists versions earlier than 24.22.1 and earlier than 26.12.1 within their respective release lines.
  4. Follow the update steps in the vendor's advisory to install 22.23.4 and later, 24.22.1 and later, or 26.12.1 and later as appropriate for the release line you use.
  5. Review application behavior involving hostname allowlists, the affected DNS functions and TLS certificate checks. Identify places where untrusted destination text could reach these security decisions.
  6. Confirm the updated runtime is in use by the deployed application, then check normal DNS resolution and secure connections through the application's usual validation process.

Check the Node.js version · official docs

node -v

How to confirm the fix

  • Check the Node.js version in the environment that actually runs the application and compare it with the corresponding fixed release: 22.23.4, 24.22.1 or 26.12.1.
  • Confirm that deployed services use the updated runtime. Checking a separate local installation does not verify a running service.
  • For applications using the affected DNS functions, verify that security checks and resolution consistently handle the intended hostname, including rejection of embedded NUL characters.
  • For applications handling unusual IP address text, verify that certificate checks identify the connected endpoint correctly and reject certificates that lack the required matching identity.

NVD scores and CISA KEV status

As of October 30, 2026, none of these CVEs is listed in the CISA Known Exploited Vulnerabilities catalog.

CVECVSSSeverityWeakness (CWE)KEV
CVE-2026-1054827.4 (v3.0)HighCWE-284Not listed
CVE-2026-1054837.4 (v3.0)HighCWE-295Not listed
CVE-2026-1060697.4 (v3.0)HighCWE-295Not listed

Affected products and fixed versions 8 rows

ProductAffected versionsFixed version / actionCVE
Node.jsearlier than 22.23.422.23.4 and laterCVE-2026-105482
Node.jsearlier than 24.22.124.22.1 and laterCVE-2026-105482
Node.jsearlier than 26.12.126.12.1 and laterCVE-2026-105482
Node.jsearlier than 24.22.124.22.1 and laterCVE-2026-105483
Node.jsearlier than 26.12.126.12.1 and laterCVE-2026-105483
Node.jsearlier than 22.23.422.23.4 and laterCVE-2026-106069
Node.jsearlier than 24.22.124.22.1 and laterCVE-2026-106069
Node.jsearlier than 26.12.126.12.1 and laterCVE-2026-106069

The vendor's advisory is the authority on affected and fixed versions. If a cell says “See the vendor advisory”, check it there.

Frequently asked questions

Are all the listed release lines affected by every CVE?

No. CVE-2026-105482 and CVE-2026-106069 cover the release lines fixed by 22.23.4, 24.22.1 and 26.12.1. CVE-2026-105483 covers the release lines fixed by 24.22.1 and 26.12.1.

Does a HIGH rating mean my application is definitely vulnerable to an attack?

No. The 7.4 CVSS score describes technical severity. Whether an attacker can reach the flawed behavior depends on your runtime version, application code, destination inputs and relevant platform behavior.

Which sources describe this advisory?

The primary sources are the Node.js vendor advisory and NVD, which published the CVE entries on 2026-10-23. KISA, Korea's Internet & Security Agency, also published an advisory on 2026-10-23.

References

How this page is made: versions and CVE IDs come from the vendor advisory table; CVSS scores and weakness types from NVD; exploitation status only from CISA KEV. The explainer is written with AI from those facts and published only after an automated check matches every version, CVE, score and command against the sources. Commands are limited to ones in official documentation. Always follow the vendor's advisory. Read in Korean.

More security advisories