CVE-2026-54272

What it actually does

CVE-2026-54272 affects the JavaScript ip-address library versions 10.1.1 through 10.2.0. The flaw is an input validation and address-classification error in IPv6 handling: IPv4-mapped IPv6 addresses such as ::ffff:127.0.0.1 and NAT64-formatted IPv6 addresses are not normalized to their embedded IPv4 address before security-relevant classification checks. As a result, methods such as getType(), isLoopback(), isUnspecified(), isMulticast(), isLinkLocal(), and isULA() can incorrectly treat addresses that represent restricted IPv4 destinations as globally routable IPv6 addresses. Applications that rely on these methods for SSRF defenses, URL allow/deny decisions, webhook validation, proxy filtering, metadata-service protection, or internal-network access controls may allow requests to destinations they intended to block.

Why it matters to the business

Applications using vulnerable versions of the ip-address package for request filtering may be tricked into connecting to internal, local, cloud metadata, or otherwise restricted network resources. In practical terms, this can expose internal services, credentials, instance metadata, administrative interfaces, or sensitive backend data through server-side request forgery paths. The CVE is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported exploit maturity, but it was published recently and affects a common class of JavaScript dependency risk where exposure depends on how the library is used by downstream applications.

How an attack unfolds

An attacker first finds an application feature that causes the server to fetch or validate attacker-supplied network locations, such as URL preview, webhook registration, file import by URL, image proxying, API callbacks, or integration configuration. If the application uses ip-address 10.1.1 through 10.2.0 to reject loopback, private, link-local, multicast, unspecified, or otherwise non-public destinations, the attacker supplies a destination encoded as an IPv4-mapped IPv6 address or, where NAT64/DNS64 routing is present, a NAT64-formatted IPv6 address. Because the vulnerable library classifies these forms as non-restricted or globally routable rather than evaluating the embedded IPv4 address, the application may pass the validation step. The operating system or network stack then routes the connection to the embedded IPv4 destination, potentially reaching localhost, internal RFC1918 systems, link-local metadata endpoints, or other restricted services. The attacker uses the server’s network position to read responses, trigger internal actions, or pivot toward sensitive internal endpoints, depending on what the vulnerable application returns or performs on behalf of the attacker.

How to fix it

Upgrade the ip-address package to version 10.2.1 or later wherever it is used directly or transitively. If exact dependency versions are pinned, update package manifests and lockfiles, rebuild artifacts, and redeploy affected applications. If immediate upgrade is not possible, add compensating validation that normalizes IPv4-mapped IPv6 and NAT64-derived addresses to their embedded IPv4 address before applying allow/deny logic. SSRF controls should resolve hostnames, canonicalize IPs, evaluate all resolved addresses, block loopback, link-local, multicast, unspecified, private, and cloud metadata ranges, and perform enforcement at connection time rather than only at initial string validation. Network-level egress restrictions should also prevent application workloads from reaching metadata endpoints, localhost-only services, and sensitive internal networks unless explicitly required.

How to confirm the fix worked

Confirm that no deployed package lockfiles or dependency trees contain ip-address versions 10.1.1, 10.1.2, or 10.2.0. For Node.js projects, inspect package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls ip-address, yarn why ip-address, or pnpm why ip-address. After upgrading, run targeted tests against application features that accept URLs or IP addresses using IPv4-mapped IPv6 inputs such as ::ffff:127.0.0.1, ::ffff:169.254.169.254, and ::ffff:10.0.0.1, and verify they are blocked when the embedded IPv4 address is restricted. In NAT64-enabled environments, also test NAT64 representations of restricted IPv4 targets and verify consistent blocking. Validate that runtime egress policy denies access to cloud metadata addresses, loopback, link-local, and internal-only ranges from components that do not require them.

Typical attack path

1. Identify a server-side feature that accepts user-controlled URLs, IP addresses, webhook targets, callback endpoints, or remote resource locations.
2. Determine whether the application performs IP classification or SSRF filtering using the vulnerable ip-address library versions 10.1.1 through 10.2.0.
3. Encode a restricted IPv4 destination as an IPv4-mapped IPv6 address, such as ::ffff:127.0.0.1, or as a NAT64 IPv6 address when the target environment supports NAT64/DNS64.
4. Submit the crafted address through the vulnerable feature so that validation incorrectly treats it as acceptable.
5. Cause the server to initiate a connection to the embedded restricted IPv4 address through the host network stack.
6. Use the resulting server-side access to retrieve internal data, reach metadata services, interact with administrative interfaces, or enumerate otherwise unreachable internal resources.

How to detect it

To determine whether exploitation has already occurred, review application access logs, API gateway logs, WAF logs, reverse proxy logs, and application-specific audit logs for user-supplied URLs or IP address fields containing IPv4-mapped IPv6 notation or NAT64-style addresses. Focus on features that fetch remote content or register callbacks, including webhooks, URL previews, import-by-URL workflows, image or document fetchers, and integration setup endpoints. Correlate suspicious inbound requests with outbound proxy, firewall, DNS, VPC flow, egress gateway, service mesh, and cloud metadata access logs to identify server-initiated connections to loopback, link-local, RFC1918, multicast, unspecified, or metadata-service destinations shortly after the inbound request. In cloud environments, inspect metadata service logs or controls, if available, for unexpected access attempts from application workloads. Because exploitation may leave only normal-looking server-side outbound traffic, detection should combine payload-pattern searches with temporal correlation between attacker-controlled inputs and internal egress activity. There are no public reports of named threat actors or ransomware campaigns exploiting this issue at this time.

• ::ffff:127.0.0.1
• ::ffff:127.1
• ::ffff:0:127.0.0.1
• ::ffff:localhost
• ::ffff:10.
• ::ffff:172.16.
• ::ffff:172.17.
• ::ffff:172.18.
• ::ffff:172.19.
• ::ffff:172.20.
• ::ffff:172.21.
• ::ffff:172.22.
• ::ffff:172.23.
• ::ffff:172.24.
• ::ffff:172.25.
• ::ffff:172.26.
• ::ffff:172.27.
• ::ffff:172.28.
• ::ffff:172.29.
• ::ffff:172.30.
• ::ffff:172.31.
• ::ffff:192.168.
• ::ffff:169.254.
• ::ffff:169.254.169.254
• [::ffff:127.0.0.1]
• [::ffff:169.254.169.254]
• [::ffff:10.
• [::ffff:192.168.
• 64:ff9b::
• 64:ff9b::a9fe:a9fe
• metadata.google.internal
• 169.254.169.254
• latest/meta-data
• latest/user-data
• computeMetadata/v1
• Metadata-Flavor: Google
• X-aws-ec2-metadata-token

What your security team should do

• Inventory applications and services that use the ip-address npm package, including transitive dependency usage in JavaScript/Node.js projects.
• Prioritize systems with URL fetching, webhook, callback, file import, image proxy, link preview, integration, or user-supplied network destination functionality.
• Upgrade ip-address to 10.2.1 or later and redeploy affected applications after refreshing dependency lockfiles and container images.
• Add regression tests for SSRF filtering using IPv4-mapped IPv6 and NAT64 address forms, including loopback, link-local, private, and metadata-service targets.
• Review SSRF defenses to ensure they canonicalize, resolve, and enforce destination restrictions at connection time, not only during input parsing.
• Apply network egress controls to block unnecessary access from application workloads to internal administration networks, localhost-exposed services, and cloud metadata endpoints.
• Search historical logs for suspicious requests containing IPv4-mapped IPv6 notation, NAT64 prefixes, or attempts to access metadata and loopback addresses through URL-capable application features.
• Monitor dependency intelligence for downstream packages that bundle vulnerable ip-address versions, especially where dependency prevalence may expand exposure beyond direct application use.