<Vulnerability name="CVE-2026-101910">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Moderate</ThreatSeverity>
    <PublicDate>2026-09-28T17:45:27</PublicDate>
    <Bugzilla id="2542599" url="https://bugzilla.redhat.com/show_bug.cgi?id=2542599" xml:lang="en:us">
ip-address: ip-address: Security boundary bypass via unclassified NAT64 local-use address range
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>5.3</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N</CVSS3ScoringVector>
    </CVSS3>
    <CWE>CWE-184</CWE>
    <Details xml:lang="en:us" source="Mitre">
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.2.0 until 10.5.1, the Address6 isPrivate classifier in src/ipv6.ts does not recognize the NAT64 local-use range 64:ff9b:1::/48. Applications that combine isPrivate, isLoopback, and isLinkLocal for a trust-boundary decision can treat an internal IPv4 destination encoded through that range as external. Exploitation depends on a server network using an operator-selected NAT64 prefix within the local-use range. A successful bypass can cross the intended network trust boundary. This issue is fixed in version 10.5.1.
    </Details>
    <Details xml:lang="en:us" source="Red Hat">
A flaw was found in ip-address. The address classification mechanism fails to identify the local-use Network Address Translation (NAT64) range as private. A remote attacker can exploit this by submitting an internal address formatted within this IPv6 prefix to an application that relies on the library to enforce network boundaries. Successful exploitation allows an attacker to bypass network access controls, potentially resulting in Server-Side Request Forgery (SSRF) and unauthorized access to restricted internal services.
    </Details>
    <Statement xml:lang="en:us">
A flaw of moderate impact was found in the ip-address JavaScript library, which is bundled in Red Hat Hardened Images (Hummingbird) components grafana12.4, grafana13.1, and grafana13.2. In ip-address versions 10.2.0 through 10.5.0, the Address6 address classifiers do not recognize the NAT64 local-use range 64:ff9b:1::/48 (RFC 8215): isPrivate(), isLoopback(), and isLinkLocal() all return false for addresses in that range, so an internal IPv4 destination encoded through an operator-selected NAT64 prefix within it is treated as an ordinary global address. A remote attacker who can submit such an address to an application that relies on ip-address for network trust-boundary decisions, such as a Server-Side Request Forgery (SSRF) filter, can cause an internal target to be classified as external, bypassing network access controls and enabling SSRF and unauthorized access to restricted internal services such as loopback services or cloud metadata endpoints. Exploitation requires the server's network to run a NAT64 translator on a prefix inside 64:ff9b:1::/48 and requires the attacker to know or guess the deployed prefix. Red Hat Product Security rates this flaw Moderate severity with a CVSS 3.1 base score of 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N); the upstream CVSS 4.0 score of 6.9 is higher mainly because upstream scores the NAT64 deployment precondition as high attack complexity and the trust-boundary crossing as a changed security scope. Within Red Hat, this flaw is tracked against the Red Hat Hardened Images components grafana12.4, grafana13.1, and grafana13.2 with resolution delegated to the image maintainers; the delegated assessment determined the shipped builds not affected because the vulnerable code is not present, and the associated trackers were closed as Not a Bug.
    </Statement>
    <Mitigation xml:lang="en:us">
The upstream project documents an interim workaround for applications that cannot upgrade immediately: explicitly test submitted IPv6 addresses for membership in the NAT64 local-use range 64:ff9b:1::/48 and reject them at the application's trust-boundary check. Using the library itself, this can be done with: const NAT64_LOCAL_USE = new Address6('64:ff9b:1::/48'); const localUse = new Address6(host).isHostInSubnet(NAT64_LOCAL_USE); and blocking the request when the check returns true. This issue is fixed upstream in ip-address 10.5.1 and later, where isPrivate() returns true for every address in 64:ff9b:1::/48, so upgrading to the patched release removes the need for the workaround. Note that these address classifiers are not a complete SSRF defense on their own; a robust guard should also resolve hostnames and validate the resolved IP address at the point of connection, accounting for DNS rebinding and redirects.
    </Mitigation>
    <PackageState cpe="cpe:/a:redhat:hummingbird:1">
        <ProductName>Red Hat Hardened Images</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>grafana12.4</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/a:redhat:hummingbird:1">
        <ProductName>Red Hat Hardened Images</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>grafana13.1</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/a:redhat:hummingbird:1">
        <ProductName>Red Hat Hardened Images</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>grafana13.2</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-101910
https://nvd.nist.gov/vuln/detail/CVE-2026-101910
https://github.com/beaugunderson/ip-address/commit/ab3dc88bcf5374344168a2ba075ca7ac4ff257f8
https://github.com/beaugunderson/ip-address/releases/tag/v10.5.1
https://github.com/beaugunderson/ip-address/security/advisories/GHSA-2vr4-cq9g-pvrc
    </References>
</Vulnerability>