CVE-2026-101912: 
Linux Debian 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 issue has existed since these methods were first written. It was disclosed on September 15, 2026, and fixed in version 10.7.1. The CVSS v4.0 base score is 6.3 (Medium) (GitHub Advisory, Red Hat).

The root cause is an incorrect comparison (CWE-697) combined with access of a resource using an incompatible type (CWE-843 / CWE-1024). In src/common.ts, isHostInSubnet() computes this.mask(address.subnetMask) === address.mask() — comparing the leading bits of both addresses as binary strings — without first checking that this and address belong to the same IP family. Because Address4 pads to 32 bits and Address6 pads to 128 bits, any cross-family pair whose leading bits coincide will produce equal masked strings and incorrectly return 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 are identical. The vulnerability is exploitable when an application parses untrusted input as whichever family accepts it and then tests the result against a fixed-family allowlist or denylist. A public proof-of-concept demonstrating the bypass is included in the GitHub security advisory (GitHub Advisory, Fix Commit).

Successful exploitation allows an unauthenticated remote attacker to bypass IP-based access controls — either gaining admission through an allowlist or evading a denylist — by supplying an address from the opposite IP family whose leading bits coincidentally match the configured prefix. The practical impact is limited in scope: an IPv6 allowlist of /32 or shorter admits only the specific IPv4 addresses whose bits match its prefix (e.g., 2001:db8::/32 admits 32.1.13.184), and these are typically public IPv4 addresses rather than private or loopback ranges. Confidentiality is not directly impacted, but integrity is affected through unauthorized access to restricted resources or functionality. The advisory notes this flaw is particularly relevant when the library is used as part of SSRF defenses, where a bypass could enable further exploitation (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub security advisory, demonstrating the bypass with a runnable JavaScript code snippet (GitHub Advisory). The vulnerability is classified as automatable (no user interaction or privileges required), though exploitation requires the specific precondition that an application uses the library for access control decisions against cross-family input. There is no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA KEV catalog (Red Hat).

1. Reconnaissance: Identify applications that use the ip-address npm library (versions ≤ 10.7.0) for IP-based access control, particularly those that parse untrusted user-supplied IP addresses and check them against a fixed-family allowlist or denylist using isInSubnet() or isHostInSubnet().
2. Identify the target allowlist: Determine the IPv6 subnet used in the application's allowlist (e.g., 2001:db8::/32). For IPv6 prefixes of /32 or shorter, calculate the IPv4 address whose 32-bit representation matches the first 32 bits of the IPv6 prefix (e.g., 2001:db8:: in hex is 20 01 0d b8, which as an IPv4 address is 32.1.13.184).
3. Craft the payload: Prepare an IPv4 address literal (e.g., 32.1.13.184) that, when parsed by the vulnerable application's parse() function, is constructed as an Address4 object.
4. Submit the crafted address: Supply the IPv4 address as input to the application's IP validation endpoint. The application calls Address4.isValid('32.1.13.184'), which returns true, so it constructs new Address4('32.1.13.184').
5. Trigger the flawed comparison: The application calls parse(h).isInSubnet(allowed) where allowed is new Address6('2001:db8::/32'). The isInSubnet() method delegates to isHostInSubnet(), which compares Address4('32.1.13.184').mask(32) with Address6('2001:db8::/32').mask() — both evaluate to the same 32-bit binary string, so the comparison returns true.
6. Gain unauthorized access: The application receives true and grants access, admitting the attacker's IPv4 address through an IPv6-only allowlist (GitHub Advisory).

• Logs: Application access logs showing IPv4 addresses being granted access to resources restricted to an IPv6 allowlist (or vice versa); unexpected ALLOW decisions for addresses not belonging to the configured IP family.
• Application Behavior: Access control decisions permitting IPv4 addresses such as 32.1.13.184 when only IPv6 ranges like 2001:db8::/32 are configured as allowed; denylist rules failing to block addresses from the opposite IP family.
• Dependency Audit: Presence of ip-address npm package at version ≤ 10.7.0 in package.json or package-lock.json of deployed applications (npm list ip-address returning a version ≤ 10.7.0).

Upgrade the ip-address npm package to version 10.7.1 or later, which fixes isHostInSubnet() to return false immediately when the two addresses are of different families (GitHub Release, Fix 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(). Additionally, the advisory recommends not relying solely on these methods for SSRF defense — a robust guard must also resolve hostnames and validate resolved IPs at the socket level to account for DNS rebinding (GitHub Advisory).

The vulnerability was reported by researcher waydeshi and published by the library maintainer beaugunderson as a GitHub Security Advisory on September 15, 2026. The advisory explicitly notes that these methods are address classifiers and not a complete SSRF defense, advising users to treat them as one layer of protection. Red Hat tracked the issue via Bugzilla (bug #2542601) and published a CVE advisory, indicating downstream awareness in enterprise Linux distributions (GitHub Advisory, Red Hat).