CVE-2026-105482 in Node.js
Summary
by MITRE • 10/23/2026
A flaw in Node.js DNS resolution allows hostnames containing a NUL byte to be silently truncated by the dns.resolve*() functions and dns.reverse(). This is an incomplete fix of CVE-2026-48930, which only covered dns.lookup() and the net/tls host options.
Because the name is passed to c-ares as a C string, resolving attacker.example\0.trusted.example queries attacker.example and returns its records without any error. Applications that validate a hostname, for example against a domain allowlist, and then resolve it with dns.resolve*() can act on records for a different name than the one they validated.
This vulnerability affects Node.js 26.x, 24.x, and 22.x.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The identified security flaw represents an incomplete remediation of CVE-2026-48930 within the Node.js runtime environment, specifically impacting versions 26.x, 24.x, and 22.x. While previous patches addressed hostname validation issues in dns.lookup() and network layer host options such as those used in net/tls connections, they failed to extend these protections to the broader suite of DNS resolution functions including dns.resolve*, dns.reverse(), and related utilities. This gap allows an attacker to exploit the underlying C library implementation, specifically c-ares, which treats hostname strings as null-terminated character arrays. When a maliciously crafted hostname containing a NUL byte is passed to these functions, the string processing logic silently truncates the input at the first occurrence of the zero value. Consequently, any characters following the NUL byte are ignored by the resolution engine without raising an error or warning condition.
This behavior creates a critical bypass mechanism for application-level security controls that rely on hostname validation prior to network operations. In typical secure coding practices, developers implement allowlists or denylists to restrict DNS queries to trusted domains. An attacker can construct a query string such as attacker.example\0.trusted.example where the NUL byte effectively hides the malicious portion of the domain from the application's validation logic while still being processed by the underlying resolver in certain contexts or causing the resolution to target the truncated prefix if the truncation occurs before lookup but after validation. More critically, because the vulnerability allows silent truncation, applications may validate a benign hostname against an allowlist and subsequently resolve it using dns.resolve*(), inadvertently triggering lookups for different records than intended due to internal parsing inconsistencies or misinterpretations of the truncated string by downstream libraries. This discrepancy enables attackers to bypass domain-based access controls and potentially exfiltrate data or perform unauthorized network interactions under the guise of a validated, trusted hostname.
From an industry standard perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to properly sanitize or validate input containing special characters that alter string processing behavior. It also relates to CWE-697 Incorrect Comparison, where the comparison logic used for allowlisting does not account for the full byte sequence of the hostname due to truncation effects. In terms of attack vectors and tactics, this flaw facilitates techniques associated with MITRE ATT&CK T1048 Exfiltration Over Alternative Protocol if DNS is abused for data tunneling, or more broadly contributes to privilege escalation scenarios where domain validation bypasses lead to unauthorized access to internal resources. The silent nature of the truncation makes detection particularly difficult as standard logging mechanisms may record only the truncated portion, masking the true intent of the request from security monitoring tools.
Mitigation strategies must prioritize immediate updates to Node.js versions that include comprehensive fixes for all DNS resolution functions, not just dns.lookup(). Developers should implement defense-in-depth measures by validating hostnames at multiple layers of the application stack rather than relying solely on a single validation point before resolution calls. Input sanitization routines should explicitly reject or escape NUL bytes and other control characters in hostname fields to prevent string truncation attacks. Additionally, integrating runtime security monitoring that detects anomalous DNS query patterns can help identify exploitation attempts where truncated hostnames are used to probe internal infrastructure. Until patches are applied, restricting the use of dns.resolve* functions for untrusted inputs or replacing them with safer alternatives that enforce strict length and character constraints is recommended to reduce the attack surface associated with this incomplete fix.