CVE-2026-101913: 
JavaScript vulnerability analysis and mitigation

CVE-2026-101913 is an IPv6 link-local range misclassification vulnerability in the ip-address JavaScript library (npm package by beaugunderson) that enables SSRF and trust-boundary bypass. The Address6.isLinkLocal() method in src/ipv6.ts incorrectly checks only the first 64 bits of an address against the fe80::/64 prefix, rather than applying the correct 10-bit prefix test for the full fe80::/10 link-local unicast range defined by RFC 4291 §2.4. This causes addresses such as fe81::1, febf::1, and fe80:0:0:1::1 to be misclassified as non-link-local, allowing them to bypass SSRF guards built on isLinkLocal(). All versions of the library up to and including 10.5.0 are affected; the fix is available in version 10.5.1. The vulnerability carries a CVSS v4.0 base score of 6.3 (Medium) (Github Advisory, GitHub Security Advisory).

The root cause is an incorrect comparison (CWE-697) in isLinkLocal() within src/ipv6.ts: the method calls getBitsBase2(0, 64) and compares the result against the 64-bit literal '1111111010000000000000000000000000000000000000000000000000000000', which corresponds only to fe80::/64. This accepts just 2⁶⁴ of the 2¹¹⁸ addresses in the fe80::/10 range. The flaw creates an internal inconsistency: for an address like fe81::1, getType() returns 'Link-local unicast', getScope() returns 'Link local', and isHostInSubnet(new Address6('fe80::/10')) returns true, while isLinkLocal() returns false. No other classifier (isPrivate(), isLoopback(), etc.) catches addresses in fe80::/10 outside fe80::/64, so an SSRF guard relying solely on isLinkLocal() will pass these addresses through unchecked (CWE-184, CWE-918). The fix replaces the hardcoded bit-string comparison with this.isHostInSubnet(LINK_LOCAL_SUBNET) where LINK_LOCAL_SUBNET = new Address6('fe80::/10'), consistent with how getType() and Address4.isLinkLocal() already operate (GitHub Security Advisory, Patch Commit).

A successful exploit allows an unauthenticated, remote attacker to bypass an application's SSRF trust-boundary check and coerce the server into making requests to on-link IPv6 hosts (neighboring machines or the on-link router) that should have been blocked. The primary impact is a limited confidentiality breach — the attacker can reach internal link-local destinations on the server's own network segment, potentially exfiltrating data from those hosts or probing internal services. Integrity and availability of the vulnerable system itself are not directly affected; however, the bypass can serve as an enabler for chained attacks against internal infrastructure reachable via the server's link-local segment (Github Advisory, GitHub Security Advisory).

A proof-of-concept (PoC) exploit is publicly available in the GitHub Security Advisory, demonstrating how an SSRF guard built on isLinkLocal() incorrectly allows addresses like fe81::1, febf::1, and fe80:0:0:1::1 through without any encoding or obfuscation. The exploit requires no authentication and no user interaction, but does require the target application to use the vulnerable library version (≤ 10.5.0) as an SSRF guard and to accept user-supplied IPv6 addresses. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is 0.0, and NVD SSVC classifies exploitation status as poc and automatable as no (Github Advisory, GitHub Security Advisory).

1. Identify target application: Locate a web application or API that uses the ip-address npm library (version ≤ 10.5.0) and accepts user-supplied IPv6 addresses as request targets, with Address6.isLinkLocal() used as part of an SSRF guard.
2. Craft a bypass address: Select a valid IPv6 link-local unicast address in fe80::/10 but outside fe80::/64, such as fe81::1, febf::1, or fe80:0:0:1::1. These are legitimate link-local addresses per RFC 4291 §2.4 but are misclassified by the vulnerable method.
3. Submit the crafted address: Supply the address in standard IPv6 notation as the request target (e.g., as a URL parameter, hostname field, or API body field). No special encoding or obfuscation is required.
4. Guard bypass occurs: The application instantiates new Address6(host) and calls isLinkLocal(), which returns false for the crafted address because the 64-bit prefix check does not match. The SSRF guard evaluates to false (not blocked), and the application permits the request.
5. Reach on-link host: The application makes a network request to the supplied IPv6 address, reaching a neighboring machine or on-link router on the server's own link-local segment — a destination the attacker could not otherwise access directly (GitHub Security Advisory).

• Network: Outbound requests from the application server to IPv6 addresses in the fe80::/10 range (excluding fe80::/64), such as fe81::/10 through febf:ffff::/10; unexpected traffic to link-local segment hosts or routers originating from the application process.
• Logs: Application access logs showing user-supplied IPv6 addresses in the fe80::/10 range (e.g., fe81::1, febf::1, fe80:0:0:1::1) passed as request parameters; absence of corresponding block/deny log entries for these addresses in SSRF guard logs.
• Application Behavior: Requests to internal link-local hosts that succeed where they should have been rejected; error responses or data returned from on-link hosts appearing in application responses to external users.

Upgrade the ip-address npm package to version 10.5.1 or later, which replaces the flawed 64-bit prefix comparison with a correct isHostInSubnet test against fe80::/10 (v10.5.1 Release, Patch Commit). If an immediate upgrade is not possible, replace calls to isLinkLocal() in SSRF guards with a direct subnet test:

const LINK_LOCAL = new Address6('fe80::/10');
const linkLocal = new Address6(host).isHostInSubnet(LINK_LOCAL);

Additionally, the advisory notes that isLinkLocal() alone is not a complete SSRF defense — a robust guard must also resolve hostnames, validate resolved IPs against the actual socket destination, and account for DNS rebinding and redirects (Github Advisory).

The vulnerability was reported by researcher euriconicacio and published by the library maintainer (beaugunderson) on August 29, 2026, with the advisory noting that the flaw has existed since Address6.isLinkLocal() was first introduced, meaning all historical releases exposing the method are affected. The advisory explicitly cautions that address classification methods are not a complete SSRF defense and recommends layered controls including hostname resolution validation and DNS rebinding protections (GitHub Security Advisory). Red Hat has tracked the issue via Bugzilla (Red Hat CVE).