Vulnerability-Lookup

GHSA-22JQ-VG5J-6VGG

Vulnerability from github – Published: 2026-08-03 19:52 – Updated: 2026-08-03 19:52

Summary

ip-address: misclassification of IPv4-mapped/NAT64 IPv6 addresses can bypass SSRF and trust-boundary checks

Details

Summary

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.

An 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.

Details

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.

The 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.

Affected versions

>= 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.

Impact

The 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:

Address	Reported as	Actually points at
`::ffff:127.0.0.1` / `::ffff:7f00:1`	Global unicast	loopback (`127.0.0.0/8`)
`::ffff:10.0.0.1`	Global unicast	RFC 1918 `10/8`
`::ffff:172.16.5.5`	Global unicast	RFC 1918 `172.16/12`
`::ffff:192.168.1.1`	Global unicast	RFC 1918 `192.168/16`
`::ffff:169.254.169.254` / `::ffff:a9fe:a9fe`	Global unicast	link-local / cloud metadata (IMDS)
`::ffff:100.64.0.1`	Global unicast	CGNAT `100.64/10`
`::ffff:0.0.0.0` / `::ffff:255.255.255.255`	Global unicast	unspecified / broadcast
`64:ff9b::7f00:1` / `64:ff9b::a9fe:a9fe`	NAT64 (well-known)	loopback / IMDS via NAT64

For 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.

Proof of concept

A guard assembled from these checks lets internal hosts through:

const { Address4, Address6 } = require('ip-address');

// true => block as internal, false => allow outbound
function isBlocked(host) {
  try {
    const a = new Address4(host);
    return a.isPrivate() || a.isLoopback() || a.isLinkLocal() || a.isCGNAT()
        || a.isMulticast() || a.isUnspecified() || a.isBroadcast();
  } catch {}
  try {
    const a = new Address6(host);
    return a.isLoopback() || a.isLinkLocal() || a.isULA()
        || a.isMulticast() || a.isUnspecified();
  } catch {}
  return false;
}

for (const h of ['127.0.0.1', '::1', '10.0.0.1', '8.8.8.8',
                 '::ffff:127.0.0.1', '::ffff:10.0.0.1',
                 '::ffff:169.254.169.254', '64:ff9b::7f00:1']) {
  console.log(isBlocked(h) ? 'BLOCK ' : 'ALLOW ', h);
}

On affected versions this prints (note that every ::ffff:… and 64:ff9b::… internal target is allowed):

BLOCK  127.0.0.1
BLOCK  ::1
BLOCK  10.0.0.1
ALLOW  8.8.8.8
ALLOW  ::ffff:127.0.0.1
ALLOW  ::ffff:10.0.0.1
ALLOW  ::ffff:169.254.169.254
ALLOW  64:ff9b::7f00:1

The 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.

Remediation

Upgrade 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.

If 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.

A note on SSRF defense

These 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.

Credit

Reported by @OV-0-VO.

Severity

6.9 (Medium)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.2.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "ip-address"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.1"
            },
            {
              "fixed": "10.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54272"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-03T19:52:33Z",
    "nvd_published_at": "2026-07-27T18:16:56Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`Address6`\u0027s 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 \u2026` 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`\u003e= 10.1.1, \u003c= 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(\u0027ip-address\u0027);\n\n// true =\u003e block as internal, false =\u003e 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 [\u0027127.0.0.1\u0027, \u0027::1\u0027, \u002710.0.0.1\u0027, \u00278.8.8.8\u0027,\n                 \u0027::ffff:127.0.0.1\u0027, \u0027::ffff:10.0.0.1\u0027,\n                 \u0027::ffff:169.254.169.254\u0027, \u002764:ff9b::7f00:1\u0027]) {\n  console.log(isBlocked(h) ? \u0027BLOCK \u0027 : \u0027ALLOW \u0027, h);\n}\n```\n\nOn affected versions this prints (note that every `::ffff:\u2026` and `64:ff9b::\u2026` 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(\u0027::ffff:127.0.0.1\u0027).isLoopback()` returns `true` and `new Address6(\u0027::ffff:10.0.0.1\u0027).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.",
  "id": "GHSA-22jq-vg5j-6vgg",
  "modified": "2026-08-03T19:52:33Z",
  "published": "2026-08-03T19:52:33Z",
  "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ip-address: misclassification of IPv4-mapped/NAT64 IPv6 addresses can bypass SSRF and trust-boundary checks"
}

CVE-2026-54272 (GCVE-0-2026-54272)

Vulnerability from cvelistv5 – Published: 2026-07-27 17:13 – Updated: 2026-07-27 17:42

Title

ip-address: Misclassification of IPv4-mapped/NAT64 IPv6 addresses can bypass SSRF and trust-boundary checks

Summary

ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Versions 10.1.1 through 10.2.0 are vulnerable to SSRF through misclassification of IPv4-mapped/NAT64 IPv6 addresses. 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. The 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. For 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.This issue has been fixed in version 10.2.1.

Severity

6.9 (Medium)


                        
                          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

SSVC

Exploitation: poc Automatable: yes Technical Impact: partial

CISA Coordinator (v2.0.3)

CWE

CWE-20 - Improper Input Validation
CWE-918 - Server-Side Request Forgery (SSRF)

Assigner

GitHub_M

References

1 reference

URL	Tags
https://github.com/beaugunderson/ip-address/secur…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version
beaugunderson	ip-address	Affected: >= 10.1.1, < 10.2.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-54272",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-27T17:41:46.238340Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-27T17:42:10.446Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-22jq-vg5j-6vgg"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "ip-address",
          "vendor": "beaugunderson",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 10.1.1, \u003c 10.2.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Versions 10.1.1 through 10.2.0 are vulnerable to SSRF through misclassification of IPv4-mapped/NAT64 IPv6 addresses. 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 \u2026 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. The 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. For 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.This issue has been fixed in version 10.2.1."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 6.9,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20: Improper Input Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-918",
              "description": "CWE-918: Server-Side Request Forgery (SSRF)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-27T17:13:09.244Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-22jq-vg5j-6vgg",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-22jq-vg5j-6vgg"
        }
      ],
      "source": {
        "advisory": "GHSA-22jq-vg5j-6vgg",
        "discovery": "UNKNOWN"
      },
      "title": "ip-address: Misclassification of IPv4-mapped/NAT64 IPv6 addresses can bypass SSRF and trust-boundary checks"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-54272",
    "datePublished": "2026-07-27T17:13:09.244Z",
    "dateReserved": "2026-06-12T17:13:32.280Z",
    "dateUpdated": "2026-07-27T17:42:10.446Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.

Action not permitted

GHSA-22JQ-VG5J-6VGG

Summary

Details

Affected versions

Impact

Proof of concept

Remediation

A note on SSRF defense

Credit

CVE-2026-54272 (GCVE-0-2026-54272)

Tags

Sightings

Nomenclature