CVE-2026-54272: ip-address Misclassification Of IPv4-mapped/NAT64 IPv6 Addresses Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-22jq-vg5j-6vgg",
  "modified" : "2026-08-03T19:52:33Z",
  "published" : "2026-08-03T19:52:33Z",
  "aliases" : [ "CVE-2026-54272" ],
  "summary" : "ip-address: misclassification of IPv4-mapped/NAT64 IPv6 addresses can bypass SSRF and trust-boundary checks",
  "details" : "### Summary\n\n`Address6`'s special-property checks misclassify IPv4-mapped (`::ffff:0:0/96`) and NAT64 well-known (`64:ff9b::/96`) IPv6 addresses. These checks classify an address by its IPv6 wrapper rather than by the IPv4 address it embeds, so `isLoopback()`, `isLinkLocal()`, `isMulticast()`, and `isUnspecified()` all return `false` for literals such as `::ffff:127.0.0.1` or `::ffff:169.254.169.254` that actually route to loopback, RFC 1918, or link-local (cloud-metadata) destinations. `Address6` also had no `isPrivate()` method, so a mapped RFC 1918 address could not be detected at all.\n\nAn application that builds a network trust-boundary decision on these checks (for example, a filter intended to block Server-Side Request Forgery, or SSRF) may therefore treat an internal target as external and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata endpoint.\n\n### Details\n\n`Address6.getType()` classifies an address by matching it against a table of known IPv6 special-use prefixes, returning `Global unicast` when nothing matches. That table had no 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. The boolean checks `isLoopback`, `isUnspecified`, and `isMulticast` compared `getType()` against a fixed label and so returned `false`, while `isLinkLocal` and `isULA` checked only the native IPv6 ranges.\n\nThe library already exposed `isMapped4()` and `to4()`, but did not apply them inside these checks, so a mapped or NAT64 address was never normalized to its embedded IPv4 address before classification. The underlying CIDR matching is correct; the defect is that the special-use table omitted the IPv4-mapped range and the checks performed no embedded-IPv4 normalization.\n\n### Affected versions\n\n`>= 10.1.1, <= 10.2.0`. The `is*` classification API was introduced for `Address4` in 10.1.1 and extended to `Address6` in 10.2.0. Releases before 10.1.1 do not expose this API and are not affected through this vector.\n\n### Impact\n\nThe misclassification covers the entire `::ffff:0:0/96` range, in both dotted and hex notation and case-insensitively, plus the `64:ff9b::/96` NAT64 well-known prefix:\n\n| Address | Reported as | Actually points at |\n|---|---|---|\n| `::ffff:127.0.0.1` / `::ffff:7f00:1` | Global unicast | loopback (`127.0.0.0/8`) |\n| `::ffff:10.0.0.1` | Global unicast | RFC 1918 `10/8` |\n| `::ffff:172.16.5.5` | Global unicast | RFC 1918 `172.16/12` |\n| `::ffff:192.168.1.1` | Global unicast | RFC 1918 `192.168/16` |\n| `::ffff:169.254.169.254` / `::ffff:a9fe:a9fe` | Global unicast | link-local / cloud metadata (IMDS) |\n| `::ffff:100.64.0.1` | Global unicast | CGNAT `100.64/10` |\n| `::ffff:0.0.0.0` / `::ffff:255.255.255.255` | Global unicast | unspecified / broadcast |\n| `64:ff9b::7f00:1` / `64:ff9b::a9fe:a9fe` | NAT64 (well-known) | loopback / IMDS via NAT64 |\n\nFor IPv4-mapped addresses the host OS routes to the IPv4 stack, so the misclassification is reachable on any dual-stack host. For NAT64, the classification bypass is unconditional but end-to-end reachability additionally requires a NAT64/DNS64 gateway in the deployment network.\n\n### Proof of concept\n\nA guard assembled from these checks lets internal hosts through:\n\n```js\nconst { Address4, Address6 } = require('ip-address');\n\n// true => block as internal, false => allow outbound\nfunction isBlocked(host) {\n  try {\n    const a = new Address4(host);\n    return a.isPrivate() || a.isLoopback() || a.isLinkLocal() || a.isCGNAT()\n        || a.isMulticast() || a.isUnspecified() || a.isBroadcast();\n  } catch {}\n  try {\n    const a = new Address6(host);\n    return a.isLoopback() || a.isLinkLocal() || a.isULA()\n        || a.isMulticast() || a.isUnspecified();\n  } catch {}\n  return false;\n}\n\nfor (const h of ['127.0.0.1', '::1', '10.0.0.1', '8.8.8.8',\n                 '::ffff:127.0.0.1', '::ffff:10.0.0.1',\n                 '::ffff:169.254.169.254', '64:ff9b::7f00:1']) {\n  console.log(isBlocked(h) ? 'BLOCK ' : 'ALLOW ', h);\n}\n```\n\nOn affected versions this prints (note that every `::ffff:…` and `64:ff9b::…` internal target is allowed):\n\n```\nBLOCK  127.0.0.1\nBLOCK  ::1\nBLOCK  10.0.0.1\nALLOW  8.8.8.8\nALLOW  ::ffff:127.0.0.1\nALLOW  ::ffff:10.0.0.1\nALLOW  ::ffff:169.254.169.254\nALLOW  64:ff9b::7f00:1\n```\n\nThe first three lines (native loopback, native IPv6 loopback, and a literal RFC 1918 address) are blocked as expected; the IPv4-mapped and NAT64 forms of the same internal destinations are allowed through.\n\n### Remediation\n\nUpgrade to the patched release. In the fix, `Address6` normalizes IPv4-mapped and NAT64 well-known addresses to their embedded IPv4 address before classifying, via a new `embeddedIPv4()` helper that `isLoopback`, `isLinkLocal`, `isMulticast`, and `isUnspecified` consult first. `Address6` also gains `isPrivate()`, `isCGNAT()`, and `isBroadcast()` for parity with `Address4`, and `getType()` now labels the `::ffff:0:0/96` range as `IPv4-mapped`. After upgrading, `new Address6('::ffff:127.0.0.1').isLoopback()` returns `true` and `new Address6('::ffff:10.0.0.1').isPrivate()` returns `true`.\n\nIf you cannot upgrade immediately, normalize embedded IPv4 addresses yourself before classifying: call `to4()` on any address where `isMapped4()` (or membership in `64:ff9b::/96`) is true, and run your IPv4 checks against the result.\n\n### A note on SSRF defense\n\nThese methods are address classifiers, not a complete SSRF defense. Regardless of this fix, a robust SSRF guard must resolve the hostname and validate the *resolved* IP against the socket it connects to, and account for DNS rebinding and redirects. Treat these checks as one layer, not the only one.\n\n### Credit\n\nReported by @OV-0-VO.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "ip-address"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "10.1.1"
      }, {
        "fixed" : "10.2.1"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 10.2.0"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-22jq-vg5j-6vgg"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-54272"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/beaugunderson/ip-address/commit/4a1f613f4c1bec915677dea923c10aaa09361ef9"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/beaugunderson/ip-address"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/beaugunderson/ip-address/releases/tag/v10.2.1"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-20", "CWE-918" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-03T19:52:33Z",
    "nvd_published_at" : "2026-07-27T18:16:56Z"
  }
}