Listen to this Post
How CVE-2026-54272 Works
The vulnerability resides in the `Address6` class of the `ip-address` npm library, which provides IP address parsing and classification utilities. The library’s `getType()` method classifies an address by matching it against a table of known IPv6 special-use prefixes, defaulting to “Global unicast” when no match is found. However, this table lacks an entry for the IPv4-mapped range (::ffff:0:0/96), causing every mapped address to be misclassified as globally routable. Similarly, NAT64 addresses (64:ff9b::/96) are labeled with their own prefix but are not normalized to their embedded IPv4 address before classification.
The boolean methods isLoopback(), isUnspecified(), and `isMulticast()` compare `getType()` against fixed labels, returning `false` for mapped addresses. Meanwhile, `isLinkLocal()` and `isULA()` only check native IPv6 ranges, completely ignoring the embedded IPv4 payload. Although the library exposes `isMapped4()` and `to4()` methods, these are not invoked internally during classification. As a result, an address like `::ffff:127.0.0.1` — which routes to loopback — is reported as “Global unicast” rather than loopback.
The impact is severe for applications that build network trust-boundary decisions (e.g., SSRF filters) using these checks. An attacker can supply an IPv4-mapped or NAT64-wrapped internal address (e.g., `::ffff:169.254.169.254` for cloud metadata) that bypasses the internal-address checks, allowing the server to make requests to internal destinations that would otherwise be blocked. On dual-stack hosts, the OS routes IPv4-mapped addresses directly to the embedded IPv4 stack, making the bypass reachable without any special network configuration. For NAT64, the bypass is unconditional at the classification layer, though end-to-end reachability also requires a NAT64/DNS64 gateway in the deployment network.
Affected versions are `>= 10.1.1` and <= 10.2.0; the classification API was introduced in `10.1.1` for `Address4` and extended to `Address6` in 10.2.0. The fix, available in version 10.3.1, introduces an `embeddedIPv4()` helper that normalizes mapped and NAT64 addresses before classification, and adds isPrivate(), isCGNAT(), and `isBroadcast()` methods to `Address6` for parity with Address4.
DailyCVE Form:
Platform: ip-address (npm)
Version: 10.1.1 – 10.2.0
Vulnerability: SSRF Bypass
Severity: Moderate
date: 2026-08-03
Prediction: 2026-07-28
What Undercode Say
Analytics: The misclassification affects the entire `::ffff:0:0/96` range (dotted, hex, case-insensitive) and the `64:ff9b::/96` NAT64 prefix. Internal addresses such as loopback (::ffff:127.0.0.1), RFC 1918 (::ffff:10.0.0.1, ::ffff:192.168.1.1), link-local/cloud metadata (::ffff:169.254.169.254), and CGNAT (::ffff:100.64.0.1) are all reported as “Global unicast”. On any dual-stack host, these addresses route to the embedded IPv4 destination, making the bypass reachable without additional infrastructure.
Bash commands and code related to the vulnerability:
Check installed version of ip-address npm list ip-address Vulnerable versions npm install [email protected] vulnerable npm install [email protected] vulnerable
Proof-of-Concept (Node.js):
const { Address4, Address6 } = require('ip-address');
function isBlocked(host) {
try {
const a = new Address4(host);
return a.isPrivate() || a.isLoopback() || a.isLinkLocal() || a.isCGNAT()
|| a.isMulticast() || a.isUnspecified() || a.isBroadcast();
} catch {}
try {
const a = new Address6(host);
return a.isLoopback() || a.isLinkLocal() || a.isULA()
|| a.isMulticast() || a.isUnspecified();
} catch {}
return false;
}
const testHosts = [
'127.0.0.1', '::1', '10.0.0.1', '8.8.8.8',
'::ffff:127.0.0.1', '::ffff:10.0.0.1',
'::ffff:169.254.169.254', '64:ff9b::7f00:1'
];
for (const h of testHosts) {
console.log(isBlocked(h) ? 'BLOCK' : 'ALLOW', h);
}
Output on affected versions (10.1.1 – 10.2.0):
BLOCK 127.0.0.1 BLOCK ::1 BLOCK 10.0.0.1 ALLOW 8.8.8.8 ALLOW ::ffff:127.0.0.1 ALLOW ::ffff:10.0.0.1 ALLOW ::ffff:169.254.169.254 ALLOW 64:ff9b::7f00:1
Native IPv4 and IPv6 loopback/RFC1918 addresses are blocked, but their IPv4-mapped and NAT64-wrapped equivalents are allowed through.
Exploit
An attacker can craft an IPv4-mapped or NAT64-wrapped address pointing to an internal target (e.g., `::ffff:169.254.169.254` for AWS IMDS, or `::ffff:127.0.0.1` for a local service) and supply it to an application that uses `Address6` classification for SSRF filtering. Because the library classifies the address as “Global unicast” rather than private/loopback, the guard permits the request. On dual-stack hosts, the OS routes the IPv4-mapped address to the embedded IPv4 destination, making the attack effective without any special network setup. For NAT64, the attack requires a NAT64/DNS64 gateway in the network, but the classification bypass itself is unconditional. This allows access to internal metadata endpoints, internal databases, or loopback services that should be inaccessible from the outside.
Protection
Immediate mitigation: Upgrade to `ip-address` version `10.3.1` or later, which includes the fix. In the patched version, `Address6` normalizes IPv4-mapped and NAT64 addresses via the new `embeddedIPv4()` helper before running isLoopback, isLinkLocal, isMulticast, and `isUnspecified` checks. `Address6` also gains isPrivate(), isCGNAT(), and `isBroadcast()` methods, and `getType()` now correctly labels `::ffff:0:0/96` as “IPv4-mapped”.
If unable to upgrade immediately: Normalize embedded IPv4 addresses manually before classification. Call `to4()` on any address where `isMapped4()` is true, or check membership in 64:ff9b::/96, then run your IPv4 checks against the result.
Broader SSRF defense: These address classifiers are not a complete SSRF defense. A robust guard must resolve hostnames, validate the resolved IP against the actual socket connection, and account for DNS rebinding and redirects. Use these checks as one layer, not the only one.
Impact
The misclassification allows attackers to bypass network trust-boundary decisions in applications that rely on `Address6` methods for SSRF filtering. Internal destinations — including loopback services (127.0.0.0/8), RFC 1918 private networks (10/8, 172.16/12, 192.168/16), link-local/cloud metadata (169.254.169.254), and CGNAT (100.64/10) — are treated as external and are reachable via IPv4-mapped or NAT64-wrapped addresses. This can lead to unauthorized access to internal APIs, cloud instance metadata, databases, and other sensitive resources that should be protected from external requests. The vulnerability is particularly dangerous in cloud environments where metadata endpoints are commonly used for credential retrieval.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
