CVE-2026-54272: 
Node.js Analyse et atténuation des vulnérabilités

CVE-2026-54272 is a Server-Side Request Forgery (SSRF) vulnerability in the ip-address npm library caused by misclassification of IPv4-mapped (::ffff:0:0/96) and NAT64 well-known (64:ff9b::/96) IPv6 addresses. Affected versions are 10.1.1 through 10.2.0 (the is* classification API was introduced in 10.1.1 and extended to Address6 in 10.2.0); versions before 10.1.1 are not affected through this vector. The vulnerability was published on July 27, 2026, and fixed in version 10.2.1. It carries a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory).

The root cause (CWE-20: Improper Input Validation; CWE-918: SSRF) lies in Address6.getType(), which classifies addresses by matching against a table of known IPv6 special-use prefixes and falls back to "Global unicast" when no match is found. The IPv4-mapped range (::ffff:0:0/96) was absent from this table, so all mapped addresses were classified as Global unicast; NAT64 addresses matched only their NAT64 label. The boolean checks isLoopback(), isUnspecified(), and isMulticast() compared getType() output against fixed labels and therefore returned false for mapped addresses, while isLinkLocal() and isULA() checked only native IPv6 ranges. Critically, the library's existing isMapped4() and to4() helpers were never consulted inside these checks, so a mapped or NAT64 address was never normalized to its embedded IPv4 address before classification. A proof-of-concept guard function demonstrates that addresses like ::ffff:127.0.0.1, ::ffff:169.254.169.254, and 64:ff9b::7f00:1 all bypass blocking logic on affected versions (GitHub Advisory).

An attacker can supply IPv4-mapped or NAT64 IPv6 address literals to bypass SSRF and trust-boundary filters built on the affected Address6 classification methods, causing the server to make requests to internal destinations — including loopback services (127.0.0.0/8), RFC 1918 private ranges (10/8, 172.16/12, 192.168/16), CGNAT (100.64/10), and cloud instance metadata endpoints (169.254.169.254/IMDS) — that the attacker could not otherwise reach. The primary confidentiality impact is on subsequent systems (rated High), as successful exploitation can expose sensitive internal data such as cloud credentials from metadata services. For IPv4-mapped addresses, the bypass is reachable on any dual-stack host; for NAT64, a NAT64/DNS64 gateway must be present in the deployment network (GitHub Advisory).

1. Identify a target application: Find a Node.js/JavaScript application that uses ip-address versions 10.1.1–10.2.0 to validate or filter user-supplied IP addresses or URLs before making outbound server-side requests (e.g., webhook handlers, URL fetchers, proxy services).
2. Craft a bypass address: Instead of supplying a plainly blocked internal address (e.g., 127.0.0.1 or 10.0.0.1), supply an IPv4-mapped IPv6 equivalent such as ::ffff:127.0.0.1, ::ffff:10.0.0.1, or ::ffff:169.254.169.254 (in dotted or hex notation, case-insensitively).
3. Submit the payload: Send the crafted address to the application's input field or API parameter that accepts a host/IP for server-side fetching. The application's Address6 SSRF guard will classify the address as "Global unicast" and allow the request.
4. Reach internal resources: The host OS routes the IPv4-mapped address to the IPv4 stack, causing the server to connect to the embedded internal IPv4 destination — for example, the cloud metadata endpoint at 169.254.169.254 to retrieve IAM credentials or other sensitive data.
5. Exfiltrate data: Collect the response returned by the server, which may contain internal service data, cloud credentials, or other sensitive information not accessible from the external network (GitHub Advisory).

• Network: Outbound HTTP/HTTPS requests from the application server to 169.254.169.254 (IMDS), 127.x.x.x, 10.x.x.x, 172.16–31.x.x, or 192.168.x.x addresses, particularly when initiated by a web-facing service process.
• Logs: Application access logs showing user-supplied inputs containing ::ffff: prefixed addresses or 64:ff9b:: NAT64 addresses in URL/host parameters; server-side HTTP client logs showing requests to internal IP ranges.
• Network: Unexpected DNS queries for internal hostnames or direct connections to cloud metadata IP 169.254.169.254 from application servers that should only communicate externally.
• Application: Responses to user requests that contain cloud provider metadata (e.g., AWS IAM role credentials, GCP service account tokens) or internal service data not intended for external exposure.

Upgrade the ip-address npm package to version 10.2.1, which fixes the issue by normalizing IPv4-mapped and NAT64 well-known addresses to their embedded IPv4 address (via a new embeddedIPv4() helper) before classification, and adds isPrivate(), isCGNAT(), and isBroadcast() methods to Address6 for parity with Address4 (GitHub Advisory). If immediate upgrade is not possible, manually call isMapped4() on any Address6 instance and, if true, use to4() to extract the embedded IPv4 address and run IPv4 checks against it before allowing a request. Additionally, the advisory notes that these classification methods should be treated as one layer of SSRF defense — a robust guard must also resolve hostnames and validate resolved IPs against the actual socket destination, accounting for DNS rebinding and redirects.

The vulnerability was reported by researcher @OV-0-VO and disclosed via a GitHub Security Advisory by the library maintainer on July 25, 2026. The advisory explicitly cautions that the affected is* methods are address classifiers, not a complete SSRF defense, and recommends layered mitigations including hostname resolution validation and DNS rebinding protections (GitHub Advisory). No significant broader media coverage or notable community commentary beyond the advisory has been identified at this time.