CVE-2026-101910 in ip-address
Summary
by MITRE • 09/28/2026
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.2.0 until 10.5.1, the Address6 isPrivate classifier in src/ipv6.ts does not recognize the NAT64 local-use range 64:ff9b:1::/48. Applications that combine isPrivate, isLoopback, and isLinkLocal for a trust-boundary decision can treat an internal IPv4 destination encoded through that range as external. Exploitation depends on a server network using an operator-selected NAT64 prefix within the local-use range. A successful bypass can cross the intended network trust boundary. This issue is fixed in version 10.5.1.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/28/2026
The ip-address library serves as a fundamental utility for parsing and manipulating IPv4 and IPv6 addresses within JavaScript environments, providing developers with methods to classify IP addresses based on their scope and type. A critical security flaw was identified in the Address6 isPrivate classifier between versions 10.2.0 and 10.5.1, specifically located in the src/ipv6.ts module. This vulnerability stems from an incomplete implementation of IPv6 address classification logic, where the library fails to recognize the NAT64 local-use range defined as 64:ff9b:1::/48. The NAT64 prefix is a standardized mechanism used by network operators to translate between IPv6 and IPv4 protocols, allowing devices that only support one protocol stack to communicate with hosts using the other. By omitting this specific range from its list of private or internal addresses, the library incorrectly categorizes these translated addresses as public or external entities rather than recognizing them as part of an internal network infrastructure.
The operational impact of this misclassification is significant for applications that rely on IP address classification to enforce security policies and trust boundaries. Many web frameworks and server-side applications utilize a combination of checks such as isPrivate, isLoopback, and isLinkLocal to determine whether incoming requests originate from trusted internal networks or untrusted external sources. When an application uses the ip-address library to evaluate these conditions, it may incorrectly treat an IPv4 destination address that has been encoded into the NAT64 range as coming from outside the network perimeter. This logic error creates a potential for trust boundary bypass, where malicious actors could exploit this discrepancy to access resources or perform actions that should be restricted to internal users only. The severity of this issue is contingent upon the specific network configuration; exploitation requires that the target server's network utilizes an operator-selected NAT64 prefix within the 64:ff9b:1::/48 range, which is a common but not universal deployment pattern for IPv6 transition technologies.
From a vulnerability classification perspective, this issue aligns with CWE-20 Improper Input Validation and CWE-755 Incorrect Choice or Default Value, as the library makes an incorrect choice in its internal logic regarding what constitutes a private address space. In terms of attack vectors, this flaw facilitates network-level attacks that could lead to unauthorized access, potentially mapping to MITRE ATT&CK techniques related to lateral movement or privilege escalation if combined with other vulnerabilities within the application layer. The failure to correctly identify NAT64 translated addresses undermines the integrity of security controls that depend on accurate source IP identification, thereby exposing systems to risks associated with spoofed or misidentified internal traffic.
To mitigate this vulnerability, organizations using affected versions of the ip-address library must upgrade immediately to version 10.5.1 or later, where the NAT64 local-use range has been correctly incorporated into the isPrivate classification logic. For environments that cannot update promptly due to dependency constraints, developers should implement additional validation layers at the application level to explicitly check for the 64:ff9b:1::/48 prefix when making trust-boundary decisions. It is also advisable to review network configurations and security policies to ensure they account for NAT64 translations, recognizing that addresses within this range represent internal IPv4 traffic rather than external threats. Regular auditing of third-party dependencies and their version histories remains essential to maintaining a robust defense-in-depth strategy against such classification-based bypasses.