CVE-2026-101912: Cross-Family IP Address Subnet Containment Logic Bypass in ip-address Library

The ip-address library is a widely utilized package in the JavaScript and TypeScript ecosystems for parsing, manipulating, and validating IPv4 and IPv6 addresses. Security-sensitive systems frequently use this package to implement IP-based access control lists, firewalls, and server-side request forgery filtering mechanisms. When applications evaluate network boundaries, they rely on containment utilities to verify if a given IP address belongs to a specific range.

CVE-2026-101912 identifies a serious logical flaw within the subnet containment validation functions defined in src/common.ts. These functions, including isInSubnet() and isHostInSubnet(), perform comparisons on binary-masked strings. However, they fail to verify that both the subnet and the host belong to the same IP family before performing the evaluation. This incorrect comparison leads to a false-positive equivalence when checking disjoint network types.

The vulnerability is classified under CWE-697 (Incorrect Comparison) and CWE-843 (Access of Resource Using Incompatible Type, also known as Type Confusion). Because of the dynamic nature of JavaScript type matching, the library allows an Address6 object to be processed within an Address4 containment verification context. If the leading bits of an IPv6 address align with the prefix of an IPv4 subnet, the library incorrectly determines that the host is contained within that subnet.

The underlying security issue resides in the shared utility functions within src/common.ts of the ip-address codebase. The function isHostInSubnet() compares the masked binary representation of a target address against the masked binary representation of the host. Specifically, it retrieves the subnet mask of the network operand and applies that mask length to the binary representation of the host address.

When a mask is applied via the .mask(n) helper, the library computes the leading bits up to the length n and returns them as a zero-padded binary string. For an IPv4 address, the binary length is at most 32 bits, whereas for an IPv6 address, it is 128 bits. If a short subnet mask is applied to both, the library only evaluates the first n bits of each address representation.

Consider the comparison between the IPv4 subnet 10.0.0.0/8 and the IPv6 address a00::1. The first octet of the IPv4 address is 10, which yields the 8-bit binary string 00001010. The first 16-bit block of the IPv6 address a00::1 is 0a00, which converts to the binary sequence 0000101000000000. Masking this IPv6 address to 8 bits extracts the identical binary sequence 00001010. The comparison of these two strings evaluates to true despite the addresses belonging to disjoint network layers.

To understand the exact structural vulnerability, we must examine the implementation of the isHostInSubnet function prior to version 10.7.1. The vulnerable logic did not contain any validation checks to enforce type or bit-width consistency between the two compared entities.

// Vulnerable code in src/common.ts before v10.7.1
export function isHostInSubnet(this: Address4 | Address6, address: Address4 | Address6) {
  // The function directly calls mask on the host and compares it to the address mask
  // No validation is performed on 'this' versus 'address' classes or lengths
  return this.mask(address.subnetMask) === address.mask();
}

The patched version introduces a strict verification check that compares the padded binary string lengths before executing the masking comparison. Because IPv4 addresses pad to 32 characters and IPv6 addresses pad to 128 characters, any type mismatch is caught immediately before the string equivalence comparison.

// Patched code in src/common.ts in v10.7.1
export function isHostInSubnet(this: Address4 | Address6, address: Address4 | Address6) {
  // Confirm that both address classes have matching binary zero-padded lengths
  // This isolates 32-bit IPv4 addresses from 128-bit IPv6 addresses
  if (this.binaryZeroPad().length !== address.binaryZeroPad().length) {
    return false;
  }
 
  return this.mask(address.subnetMask) === address.mask();
}

This remediation ensures that cross-family comparison attempts always return false, neutralizing the logical flaw.

Exploitation of CVE-2026-101912 requires a target application to accept arbitrary IP address inputs and validate them against a restricted subnet using the ip-address library. Common targets include administrative dashboards, forward proxies, or webhooks that employ IP-based access control lists (ACLs) to block internal connections.

An attacker can craft a specific IPv6 address designed to collide with a restricted internal IPv4 range. In a typical Server-Side Request Forgery (SSRF) bypass scenario, the application might block private IP ranges (such as 10.0.0.0/8). By supplying the IPv6 address a00::1, which evaluates to the same leading 8-bit sequence as 10.0.0.0/8, the containment check evaluates to true. If the application logic permits requests based on this containment check, the filter is bypassed.

This diagram displays the process by which different families produce matching binary patterns, resulting in the security bypass.

The security impact of CVE-2026-101912 depends heavily on the context in which the ip-address library is used. In applications utilizing the library to enforce network isolation, this vulnerability can lead to authorization bypasses, access control list evasion, or server-side request forgery. The CVSS v4.0 base score is calculated at 6.3, reflecting medium severity with partial integrity impact.

An attacker exploiting this flaw cannot execute arbitrary code directly through the library itself, but they can subvert routing or proxy constraints to query internal microservices. In cloud environments, this may expose sensitive internal metadata endpoints, such as the Instance Metadata Service (IMDS). Evasion of access controls on administrative interfaces can also lead to unauthorized data disclosure if backend APIs are exposed to external queries.

The Exploit Prediction Scoring System (EPSS) score is 0.0037, indicating a low probability of active exploitation in typical deployments. However, because the logical flaw is deterministic, security researchers can easily replicate the behavior to identify vulnerable ingress points.

The primary remediation strategy is upgrading the ip-address package to version 10.7.1 or later. This version enforces strict length comparisons, preventing type collisions between IPv4 and IPv6 addresses. Development teams must update their package manifests and rebuild their environments to apply the patch.

If upgrading is not immediately possible, applications should implement input sanitization to ensure that only a single IP family is processed within a given validation loop. Explicitly verifying that the input string does not contain colon characters before checking against an IPv4 subnet provides an immediate workaround. Normalizing all incoming IP representations prior to passing them to validation methods reduces the risk of type confusion.

// Temporary mitigation workaround
function safeSubnetCheck(userInput, allowedSubnet) {
  const isUserV6 = userInput.includes(':');
  const isSubnetV6 = allowedSubnet.includes(':');
  
  if (isUserV6 !== isSubnetV6) {
    return false; // Force fail if families mismatch
  }
  // Proceed to standard evaluation safely
}

Additionally, implementing strict firewall rules at the network layer provides defense-in-depth, ensuring that logical bypasses within application code do not translate to successful network connections.