CVE-2026-101910: 
JavaScript vulnerability analysis and mitigation

CVE-2026-101910 is a trust-boundary bypass and SSRF-enablement vulnerability in the ip-address JavaScript/npm library (by beaugunderson). The Address6 class's isPrivate(), isLoopback(), and isLinkLocal() classifiers fail to recognize the NAT64 local-use range 64:ff9b:1::/48 (RFC 8215) as a private/internal address space, causing applications that rely on these checks for SSRF filtering to incorrectly classify internal IPv4 destinations encoded through this range as external. Affected versions are >= 10.2.0 and <= 10.5.0; the vulnerability was published by the maintainer on August 29, 2026, and disclosed to NVD on September 28, 2026. It carries a CVSS v3.1 score of 5.3 (Medium) and a CVSS v4.0 score of 6.9 (Medium) (GitHub Advisory, RedHat CVE).

The root cause is an incomplete list of disallowed inputs (CWE-184) combined with a Server-Side Request Forgery enablement flaw (CWE-918). The is* classification API introduced in version 10.2.0 handles the NAT64 well-known prefix (64:ff9b::/96) by decoding the trailing 32 bits to extract an embedded IPv4 address, but this approach cannot work for the local-use range (64:ff9b:1::/48) because an operator may deploy a NAT64 prefix of any RFC 6052-allowed length (/48, /56, /64, or /96) within it — meaning the same bits decode to different IPv4 addresses depending on the prefix length chosen. As a result, getType() correctly identifies addresses in this range as 'NAT64 (local-use)' but no classifier (isPrivate(), isLoopback(), isLinkLocal()) returns true for them. An attacker who supplies an address like 64:ff9b:1:7f00:0:100:: (encoding 127.0.0.1 under a /48 prefix) to an application using these checks as an SSRF guard will have the request allowed through to the internal destination (GitHub Advisory, Patch Commit).

Successful exploitation allows an unauthenticated network attacker to bypass IPv6 address classification trust-boundary checks and coerce a vulnerable server into making requests to internal destinations — including loopback services (127.0.0.1), RFC 1918 private hosts (10.x.x.x, 192.168.x.x), link-local addresses (169.254.169.254), and cloud metadata endpoints — that should be blocked by SSRF defenses. The primary impact is confidentiality: sensitive internal data (e.g., cloud instance metadata, internal API responses) may be exposed to the attacker. Integrity and availability of the vulnerable system itself are not directly impacted, but downstream internal systems reached via SSRF may be at risk depending on what services are accessible (GitHub Advisory).

A proof-of-concept is publicly available in the GitHub Security Advisory, demonstrating that on affected versions, addresses such as 64:ff9b:1:7f00:0:100:: and 64:ff9b:1::7f00:1 pass through isBlocked() guards undetected (GitHub Advisory). Exploitation requires the target server's network to operate a NAT64 translator on a prefix within 64:ff9b:1::/48, and the attacker must know or guess the operator-chosen prefix length — conditions that limit but do not eliminate real-world risk. There is no evidence of in-the-wild exploitation at this time, no threat actor attribution, and the CVE is not listed in the CISA KEV catalog. The EPSS score is 0.0 (RedHat CVE).

1. Reconnaissance: Identify applications that use the ip-address npm library (versions 10.2.0–10.5.0) for SSRF filtering, particularly those that call isPrivate(), isLoopback(), or isLinkLocal() on user-supplied IPv6 addresses.
2. Determine NAT64 prefix: Probe or infer whether the target server's network runs a NAT64 translator on a prefix within 64:ff9b:1::/48. Common operator-chosen prefix lengths are /48, /56, /64, or /96.
3. Encode internal target: Construct a NAT64 local-use address encoding the desired internal IPv4 destination. For example, under a /48 prefix: 64:ff9b:1:7f00:0:100:: encodes 127.0.0.1, and 64:ff9b:1:a9fe:a9:fe00:: encodes 169.254.169.254 (cloud metadata endpoint).
4. Submit crafted address: Supply the crafted IPv6 address as a user-controlled input (e.g., a URL, hostname field, or webhook destination) to the vulnerable application.
5. Bypass SSRF filter: The application calls isBlocked() (or equivalent), which returns false for the local-use NAT64 address, allowing the request to proceed.
6. Reach internal destination: The server makes a request to the internal target via the NAT64 translator, and the attacker receives the response — potentially including cloud metadata credentials, internal API data, or other sensitive information (GitHub Advisory).

• Network: Outbound requests from the application server to internal IP ranges (loopback 127.x.x.x, RFC 1918 10.x.x.x/192.168.x.x/172.16-31.x.x, link-local 169.254.x.x) that are unexpected or user-triggered; traffic routed through a NAT64 translator on a 64:ff9b:1::/48 prefix to internal hosts.
• Logs: Application access logs showing user-supplied IPv6 addresses in the 64:ff9b:1::/48 range (e.g., 64:ff9b:1:7f00:0:100::, 64:ff9b:1:a9fe:a9:fe00::) as request parameters or URL inputs; HTTP requests to cloud metadata endpoints (169.254.169.254) originating from the application process.
• Application Behavior: Unexpected responses containing internal service data (e.g., AWS/GCP/Azure instance metadata, internal API payloads) returned to external users.

Primary remediation: Upgrade the ip-address npm package to version 10.5.1 or later, which adds isPrivate() coverage for the entire 64:ff9b:1::/48 range as a whole (GitHub Release, Patch Commit).

Workaround (if immediate upgrade is not possible): Explicitly test for the local-use NAT64 range before allowing requests:

const NAT64_LOCAL_USE = new Address6('64:ff9b:1::/48');
const localUse = new Address6(host).isHostInSubnet(NAT64_LOCAL_USE);

Add this check alongside existing isPrivate(), isLoopback(), and isLinkLocal() calls.

Defense-in-depth: The advisory notes that address classifiers alone are not a complete SSRF defense — applications should also resolve hostnames and validate the resolved IP against the actual socket destination, and account for DNS rebinding and redirects (GitHub Advisory).