CVE-2026-54272 Overview
CVE-2026-54272 is a Server-Side Request Forgery (SSRF) vulnerability in the ip-address JavaScript library, which parses and manipulates IPv4 and IPv6 addresses. Versions 10.1.1 through 10.2.0 misclassify IPv4-mapped and NAT64 IPv6 addresses as Global unicast, allowing attackers to bypass address validation checks used to block requests to loopback, private, or link-local ranges. Applications that rely on the library's isLoopback, isUnspecified, isMulticast, isLinkLocal, or isULA boolean checks to prevent SSRF can be tricked into contacting internal resources. The issue is fixed in version 10.2.1.
Critical Impact
Applications using ip-address for SSRF defense on dual-stack hosts can be coerced into sending requests to loopback or internal network destinations via IPv4-mapped IPv6 addresses such as ::ffff:127.0.0.1.
Affected Products
- ip-address npm package version 10.1.1
- ip-address npm package versions up to and including 10.2.0
- Node.js and JavaScript applications depending on ip-address for SSRF validation
Discovery Timeline
- 2026-07-27 - CVE-2026-54272 published to NVD
- 2026-07-27 - Last updated in NVD database
Technical Details for CVE-2026-54272
Vulnerability Analysis
The vulnerability is classified under [CWE-20: Improper Input Validation]. The Address6.getType() method classifies an IPv6 address by matching it against a table of known IPv6 special-use prefixes. When no match is found, the method returns Global unicast. The prefix table lacked an entry for the IPv4-mapped range ::ffff:0:0/96, so every mapped address fell through to Global unicast. NAT64 addresses matched their own NAT64 labels rather than being resolved to their embedded IPv4 destination.
The boolean helpers isLoopback, isUnspecified, and isMulticast compared getType() output against a fixed label. They returned false for mapped or NAT64 addresses that embed loopback, unspecified, or multicast IPv4 addresses. The isLinkLocal and isULA checks only inspected native IPv6 ranges. The library exposed isMapped4() and to4() helpers but never applied them inside these classification checks.
Root Cause
The root cause is missing normalization of IPv4-mapped and NAT64 IPv6 addresses before classification. Addresses such as ::ffff:127.0.0.1 embed an IPv4 address that the host OS routes to the IPv4 stack, but the library evaluated the outer IPv6 representation without extracting the embedded IPv4 address for a second classification pass.
Attack Vector
An attacker submits a URL or hostname containing an IPv4-mapped IPv6 literal such as [::ffff:127.0.0.1] or [::ffff:169.254.169.254] to an application that uses ip-address boolean checks to reject internal destinations. The checks return false, the request proceeds, and on any dual-stack host the OS forwards the request to the embedded IPv4 destination. This exposes loopback services, cloud metadata endpoints, and private-range hosts. NAT64 exploitation is unconditional at the classification layer but requires a NAT64/DNS64 gateway for end-to-end reachability.
No verified public exploit code is available. See the GitHub Security Advisory for technical details.
Detection Methods for CVE-2026-54272
Indicators of Compromise
- Outbound HTTP requests from application servers to IPv4-mapped IPv6 literals such as ::ffff:127.0.0.1 or ::ffff:169.254.169.254.
- Application logs showing user-supplied URLs containing bracketed IPv6 addresses with the ::ffff: prefix.
- Unexpected requests to cloud instance metadata services (IMDS) originating from application workloads.
Detection Strategies
- Perform dependency scanning across package.json and package-lock.json files to identify ip-address versions 10.1.1 through 10.2.0.
- Instrument HTTP client wrappers to log the resolved destination address after DNS resolution, flagging mapped IPv6 or embedded RFC1918 IPv4 targets.
- Review web application firewall logs for request parameters that contain ::ffff: or 64:ff9b:: prefixes in URL fields.
Monitoring Recommendations
- Alert on any application-originated traffic to 127.0.0.0/8, 169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 when the destination was derived from user input.
- Monitor cloud metadata endpoint access from workloads that should not require IMDS calls.
- Track software bill of materials (SBOM) data for the vulnerable ip-address version range across production and CI/CD environments.
How to Mitigate CVE-2026-54272
Immediate Actions Required
- Upgrade ip-address to version 10.2.1 or later in all Node.js and JavaScript projects.
- Audit application code paths that call isLoopback, isUnspecified, isMulticast, isLinkLocal, or isULA for SSRF defense purposes.
- Rebuild and redeploy container images and serverless functions after refreshing the dependency lockfile.
Patch Information
The maintainers fixed the issue in version 10.2.1. The patch adds classification logic for IPv4-mapped and NAT64 ranges and normalizes embedded IPv4 addresses before evaluating boolean helpers. Full details are available in the GitHub Security Advisory GHSA-22jq-vg5j-6vgg.
Workarounds
- Before calling classification helpers, detect mapped addresses with isMapped4() and re-validate the embedded IPv4 address using an IPv4 classifier.
- Reject any user-supplied hostname or URL that contains the literal prefixes ::ffff: or 64:ff9b:: at the input validation layer.
- Enforce egress network controls that block application workloads from reaching loopback, link-local, and RFC1918 destinations regardless of the requested address family.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
