CVE-2026-101913: Link-Local Address Validation Bypass in ip-address Library Enables SSRF

The ip-address npm package is a widely utilized utility library in JavaScript and TypeScript environments for parsing, validating, and manipulating IPv4 and IPv6 network addresses. Applications frequently employ this library within input validation pipelines and security boundary checks to prevent Server-Side Request Forgery (SSRF) and to restrict outbound connections to designated safe ranges.

This vulnerability, tracked as CVE-2026-101913, stems from an incorrect classification logic in the library's link-local check. It is categorized under CWE-697 (Incorrect Comparison) and can lead directly to CWE-918 (Server-Side Request Forgery).

The attack surface exists anywhere user-controlled input is parsed by Address6 and filtered using the isLinkLocal() method before initiating outbound server requests. Because the library fails to identify certain valid link-local addresses, security filters are bypassed, exposing local physical or virtual networks to unauthorized access.

According to RFC 4291 §2.4, the prefix fe80::/10 is reserved globally for IPv6 link-local unicast communications. This allocation spans a broad range of addresses from fe80:: to febf::, requiring only the first 10 bits of the address structure to match the binary sequence 1111 1110 10. Operating systems, network cards, and routing frameworks natively recognize the entire /10 subnet as link-local.

In versions of the ip-address library prior to version 10.5.1, the validation logic in Address6.isLinkLocal() was restricted to a static, hardcoded comparison against a 64-bit binary literal string. This comparison enforced that bits 10 through 63 must be strictly set to zero, matching only the fe80::/64 prefix commonly utilized by Stateless Address Autoconfiguration (SLAAC).

This narrow evaluation introduced a logical discrepancy between the library's validation and the system's underlying routing engine. When an input address like fe81::1 or fe80:0:0:1::1 was parsed, isLinkLocal() returned false. However, the host operating system's networking stack resolved and routed the subsequent outbound packets to adjacent hosts on the local link, creating a complete security boundary bypass.

To understand the exact programmatic mistake, let us analyze the code transition in src/ipv6.ts that occurred in version 10.5.1. The old code utilized a strict string check that was highly brittle and did not scale to proper subnet masking.

Here is the comparison between the vulnerable and patched code paths:

// VULNERABLE CODE - ip-address <= 10.5.0
isLinkLocal(): boolean {
  if (this.is4()) {
    const embedded = this.embeddedIPv4();
    if (embedded) {
      return embedded.isLinkLocal();
    }
  }
 
  // Zeroes are required, i.e. we can't check isHostInSubnet with 'fe80::/10'
  if (
    this.getBitsBase2(0, 64) ===
    '1111111010000000000000000000000000000000000000000000000000000000'
  ) {
    return true;
  }
 
  return false;
}

// PATCHED CODE - ip-address >= 10.5.1
isLinkLocal(): boolean {
  if (this.is4()) {
    const embedded = this.embeddedIPv4();
    if (embedded) {
      return embedded.isLinkLocal();
    }
  }
 
  // Delegation to the proper subnet validation engine using the correct /10 definition
  return this.isHostInSubnet(LINK_LOCAL_SUBNET);
}

In the patched version, the developer registered LINK_LOCAL_SUBNET as a static Address6 instance containing 'fe80::/10'. By delegating the evaluation to the existing isHostInSubnet() mechanism, the library correctly evaluates the first 10 bits and ignores any variations in the subsequent bits, resolving the logical error.

Exploiting this validation flaw requires minimal effort and is highly reliable since the vulnerability depends solely on logical comparison differences between the application and the network layer. The prerequisites are an unauthenticated input interface that executes HTTP requests or TCP connections and validates the destination using ip-address.

The exploit flow starts with the attacker generating a target address that resides within the fe80::/10 range but outside the fe80::/64 boundary. An example of such an address is fe80:0:0:1::1 or fe81::1. The attacker supplies this IP inside a payload to the vulnerable endpoint (e.g., http://[fe81::1]/status).

When the endpoint parses the input, the validation wrapper invokes isLinkLocal(), which returns false due to the logical limitation. The security check is bypassed, and the HTTP client executes the request. The underlying system socket routes the packet to the local interface, establishing a connection with adjacent administrative interfaces or services on the local link.

Here is a visual representation of the attack execution path:

The primary risk associated with this vulnerability is unauthenticated Server-Side Request Forgery (SSRF). Attackers can leverage the bypass to reach adjacent internal systems, local administrative interfaces, and local hypervisor metadata endpoints that are typically restricted from external network access.

While the scope of the attack is constrained to link-local adjacent assets, the information leakage can be severe if local systems trust adjacent nodes without authentication. This vulnerability allows port scanning of the local link, interaction with adjacent system services, and potential extraction of configuration data.

The vulnerability is assessed with a CVSS v4.0 base score of 6.3 (Medium). The score reflects a Network-based, Low complexity attack vector that requires no privileges or user interaction, but results in Low confidentiality impact on both the vulnerable system and subsequent systems (VC:L, SC:L).

The recommended remediation is to upgrade the ip-address dependency to version 10.5.1 or higher. This update replaces the flawed comparison logic with robust subnet-mask evaluations for the complete fe80::/10 range.

npm install ip-address@10.5.1

If immediate package upgrade is impossible, developers can mitigate the flaw by implementing a manual prefix check. The application should reject any IPv6 address where the first 10 bits in binary translate to 1111111010 (corresponding to the fe80::/10 space).

Additionally, applications should adopt defensive-in-depth principles. This includes pinning the IP address resolved from DNS immediately, enforcing zero-trust egress rules at the network layer, and restricting local link-local routing rules for application host systems.