CVE-2026-101912: 
JavaScript vulnerability analysis and mitigation

CVE-2026-101912 is a cross-family IP address comparison flaw in the ip-address JavaScript library (npm package by beaugunderson) that allows attackers to bypass IP-based allowlist or denylist access controls. The vulnerability exists in the isInSubnet() and isHostInSubnet() methods in src/common.ts, which compare masked binary strings without validating that both operands belong to the same IP address family (IPv4 vs. IPv6). All versions up to and including 10.7.0 are affected; the flaw has existed since the methods were first written. It was published by the repository maintainer on September 15, 2026, and received a CVSS v4.0 base score of 6.3 (Medium) (Github Advisory, GitHub Security Advisory).

The root cause is an incorrect comparison (CWE-697) and type confusion (CWE-843 / CWE-1024): isHostInSubnet() computes this.mask(address.subnetMask) === address.mask() without first verifying that this and address are the same IP family. Because Address4 pads its binary representation to 32 bits and Address6 to 128 bits, whenever the leading bits of an IPv4 and an IPv6 address coincide within the subnet prefix length, the masked strings are identical and the comparison incorrectly returns true. For example, new Address4('32.1.13.184').isInSubnet(new Address6('2001:db8::/32')) returns true because the 32-bit IPv4 address and the first 32 bits of the IPv6 prefix share the same bit pattern. The TypeScript signature accepts Address4 | Address6 on both sides, so the compiler raises no warning, and the v4 property on Address6 objects marks IPv4-mapped notation rather than address family, providing no discrimination (GitHub Security Advisory). A public proof-of-concept demonstrating the bypass is included in the advisory (Github Advisory).

Successful exploitation allows an unauthenticated remote attacker to bypass IP-based allowlist or denylist decisions enforced by the ip-address library, causing an address outside the intended range to be classified as contained. In the allowlist direction, an attacker can gain access to resources or functionality restricted to a specific IP range; in the denylist direction, a blocked address may evade the restriction. The advisory notes that the addresses admitted through this flaw are public IPv4 or unallocated IPv6 addresses — not private, loopback, or link-local ranges — so direct lateral movement to internal hosts is not a primary risk, but the bypass can serve as an initial access step enabling further exploitation such as SSRF when combined with other vulnerabilities (GitHub Security Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, demonstrating the bypass with a short JavaScript snippet requiring no authentication or user interaction (GitHub Security Advisory). The EPSS score is approximately 0.37% (29th percentile), indicating a low but non-negligible probability of exploitation in the near term (Github Advisory). There is no evidence of active in-the-wild exploitation at this time, no known threat actor attribution, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The NVD SSVC assessment classifies exploitation status as "poc" and the vulnerability as automatable (Feedly).

1. Reconnaissance: Identify applications that use the ip-address npm package (versions ≤ 10.7.0) for IP-based access control — particularly those that parse untrusted user-supplied host strings and test them against a fixed-family allowlist or denylist using isInSubnet() or isHostInSubnet().
2. Determine the target allowlist prefix: Identify the IPv6 subnet prefix used by the application's allowlist (e.g., 2001:db8::/32). For a /32 IPv6 prefix, the first 32 bits of the prefix directly correspond to an IPv4 address.
3. Craft the bypass address: Convert the first 32 bits of the IPv6 prefix to its IPv4 equivalent. For 2001:db8::/32, the 32-bit prefix 0x20010db8 corresponds to the IPv4 address 32.1.13.184.
4. Submit the crafted IPv4 address: Supply the crafted IPv4 address as input to the application. If the application parses input as IPv4 when valid (e.g., Address4.isValid(host) ? new Address4(host) : new Address6(host)), it constructs an Address4 object.
5. Trigger the flawed comparison: The application calls parse(host).isInSubnet(allowed) where allowed is an Address6 object. isInSubnet() delegates to isHostInSubnet(), which compares Address4('32.1.13.184').mask(32) with Address6('2001:db8::/32').mask() — both yield the same 32-bit binary string, so the comparison returns true.
6. Gain unauthorized access: The application receives true and grants the attacker access to the allowlisted resource, even though 32.1.13.184 is not within the IPv6 range 2001:db8::/32 (GitHub Security Advisory).

• Logs: Application access logs showing requests from IPv4 addresses that should not match an IPv6-only allowlist (e.g., 32.1.13.184 appearing in logs for a service restricted to 2001:db8::/32); unexpected access grants to IP addresses outside the configured allowed ranges.
• Network: Inbound requests from public IPv4 addresses to endpoints or resources that are configured to accept only IPv6 subnets, or vice versa; unusual access patterns from IP addresses not belonging to the expected address family of the allowlist.
• Application Behavior: Access control decisions returning true for cross-family address comparisons in application debug or audit logs; SSRF-related outbound requests originating from the application server following an unexpected allowlist match.

Upgrade the ip-address npm package to version 10.7.1 or later, which fixes isHostInSubnet() to return false when the two addresses are of different families (GitHub Release, Patch Commit). If an immediate upgrade is not possible, apply the following workaround before calling isInSubnet(): const contained = host.constructor === network.constructor && host.isInSubnet(network);. For intentional cross-family comparisons, convert addresses first using Address6.fromAddress4(), to4(), or toAddress4Nat64() before comparing. Additionally, the advisory recommends treating IP subnet checks as one layer of SSRF defense only — a robust guard must also resolve hostnames and validate resolved IPs at the socket level, accounting for DNS rebinding and redirects (GitHub Security Advisory).