Vulnerability-Lookup

GHSA-J6R3-76F7-8JCV

Vulnerability from github – Published: 2026-09-29 23:46 – Updated: 2026-09-29 23:46

Summary

ip-address: isInSubnet() and isHostInSubnet() compare addresses of different families as if they shared an address space, allowing an allowlist check to admit an address outside its range

Details

Summary

isInSubnet() and isHostInSubnet() accept an address of either family and compare masked binary strings without checking that both operands are the same family. Address4 pads to 32 bits and Address6 to 128, so whenever the leading bits agree the strings are equal: new Address6('a00::1').isInSubnet(new Address4('10.0.0.0/8')) is true, and new Address4('32.0.0.1').isInSubnet(new Address6('2000::/3')) is true. No IPv4 address is inside an IPv6 network, so both answers are untrue.

An application that parses untrusted input as whichever family accepts it and then tests the result against a fixed-family allowlist can admit an address outside the list.

Details

Both methods are in src/common.ts:

export function isInSubnet(this: Address4 | Address6, address: Address4 | Address6) {
  if (this.subnetMask < address.subnetMask) {
    return false;
  }

  return isHostInSubnet.call(this, address);
}

export function isHostInSubnet(this: Address4 | Address6, address: Address4 | Address6) {
  return this.mask(address.subnetMask) === address.mask();
}

mask(n) returns the first n bits of the address as a string of 0 and 1, taken from a representation padded to the family's width. new Address6('a00::1').mask(8) is '00001010', and so is new Address4('10.0.0.0/8').mask(), so string equality reports containment. The signature admits either family on either side, so TypeScript raises nothing, and the v4 property on Address6 marks IPv4 notation (::ffff:10.0.0.1) rather than family, so it does not discriminate either.

Which cross-family pairs coincide depends on the network's prefix length. mask(n) on an Address4 returns at most 32 bits, so an IPv6 network longer than /32 never matches an IPv4 address, and an IPv6 network of /32 or shorter matches exactly the IPv4 addresses whose leading bits equal its prefix. An IPv4 network is at most 32 bits and matches every IPv6 address whose leading bits equal its prefix.

Affected versions

<= 10.7.0. The comparison has had this shape since the methods were written, so every release is affected.

Impact

Expression	Result	Reason
`new Address6('a00::1').isInSubnet(new Address4('10.0.0.0/8'))`	`true`	both mask to `00001010`
`new Address4('10.0.0.1').isInSubnet(new Address6('a00::/8'))`	`true`	the same bits, reversed
`new Address4('32.0.0.1').isInSubnet(new Address6('2000::/3'))`	`true`	both begin `001`
`new Address4('32.1.13.184').isInSubnet(new Address6('2001:db8::/32'))`	`true`	the `/32` spells an IPv4 address
`new Address6('cb00:7100::1').isInSubnet(new Address4('203.0.113.0/24'))`	`true`	the `/24` spells an IPv6 prefix
`new Address4('10.0.0.1').isInSubnet(new Address6('::ffff:10.0.0.0/104'))`	`false`	`/104` is longer than 32 bits
`new Address4('8.8.8.8').isInSubnet(new Address4('10.0.0.0/8'))`	`false`	same-family control

In the allowlist direction the check admits an address outside the list; in the denylist direction it blocks an address outside the list. What the coincidence can admit is narrow. An IPv6 allowlist of /32 or shorter admits the IPv4 addresses its prefix spells: 2001:db8::/32 admits exactly 32.1.13.184, and 2000::/3 admits 32.0.0.0/3. Those are public IPv4 addresses; the private, loopback, and link-local ranges begin with bit patterns no allocated IPv6 prefix shares. An IPv4 allowlist admits the IPv6 addresses its prefix spells, and those all sit in blocks IANA has not allocated. So a request admitted through this defect reaches an address outside the intended list, not an internal host, and the severity reflects that.

Proof of concept

npm i ip-address@10.7.0, then:

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

// An allowlist of the application's own IPv6 range, tested against whichever
// family the input parses as.
const allowed = new Address6('2001:db8::/32');

function parse(host) {
  return Address4.isValid(host) ? new Address4(host) : new Address6(host);
}

for (const h of ['2001:db8::1', '2001:db9::1', '32.1.13.184', '32.1.13.185']) {
  console.log(parse(h).isInSubnet(allowed) ? 'ALLOW' : 'BLOCK', h);
}

On affected versions:

ALLOW 2001:db8::1
BLOCK 2001:db9::1
ALLOW 32.1.13.184
BLOCK 32.1.13.185

The IPv6 rows are right. The IPv4 address whose 32 bits equal the allowlist's prefix is admitted; the one next to it is not.

Remediation

Upgrade to the patched release. In the fix, isHostInSubnet() returns false when the two addresses are of different families, and isInSubnet() inherits the answer. The methods keep accepting either family so existing call sites compile. A caller that means to compare across families converts first, with Address6.fromAddress4(), to4(), or toAddress4Nat64(): new Address6('::ffff:10.0.0.1').to4().isInSubnet(new Address4('10.0.0.0/8')) is true, as before.

If you cannot upgrade immediately, compare the classes before you compare the addresses:

const contained = host.constructor === network.constructor && host.isInSubnet(network);

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.

Severity

6.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.7.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "ip-address"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-101912"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-697",
      "CWE-843"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T23:46:52Z",
    "nvd_published_at": "2026-09-28T18:17:21Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`isInSubnet()` and `isHostInSubnet()` accept an address of either family and compare masked binary strings without checking that both operands are the same family. `Address4` pads to 32 bits and `Address6` to 128, so whenever the leading bits agree the strings are equal: `new Address6(\u0027a00::1\u0027).isInSubnet(new Address4(\u002710.0.0.0/8\u0027))` is `true`, and `new Address4(\u002732.0.0.1\u0027).isInSubnet(new Address6(\u00272000::/3\u0027))` is `true`. No IPv4 address is inside an IPv6 network, so both answers are untrue.\n\nAn application that parses untrusted input as whichever family accepts it and then tests the result against a fixed-family allowlist can admit an address outside the list.\n\n### Details\n\nBoth methods are in `src/common.ts`:\n\n```ts\nexport function isInSubnet(this: Address4 | Address6, address: Address4 | Address6) {\n  if (this.subnetMask \u003c address.subnetMask) {\n    return false;\n  }\n\n  return isHostInSubnet.call(this, address);\n}\n\nexport function isHostInSubnet(this: Address4 | Address6, address: Address4 | Address6) {\n  return this.mask(address.subnetMask) === address.mask();\n}\n```\n\n`mask(n)` returns the first `n` bits of the address as a string of `0` and `1`, taken from a representation padded to the family\u0027s width. `new Address6(\u0027a00::1\u0027).mask(8)` is `\u002700001010\u0027`, and so is `new Address4(\u002710.0.0.0/8\u0027).mask()`, so string equality reports containment. The signature admits either family on either side, so TypeScript raises nothing, and the `v4` property on `Address6` marks IPv4 notation (`::ffff:10.0.0.1`) rather than family, so it does not discriminate either.\n\nWhich cross-family pairs coincide depends on the network\u0027s prefix length. `mask(n)` on an `Address4` returns at most 32 bits, so an IPv6 network longer than `/32` never matches an IPv4 address, and an IPv6 network of `/32` or shorter matches exactly the IPv4 addresses whose leading bits equal its prefix. An IPv4 network is at most 32 bits and matches every IPv6 address whose leading bits equal its prefix.\n\n### Affected versions\n\n`\u003c= 10.7.0`. The comparison has had this shape since the methods were written, so every release is affected.\n\n### Impact\n\n| Expression | Result | Reason |\n|---|---|---|\n| `new Address6(\u0027a00::1\u0027).isInSubnet(new Address4(\u002710.0.0.0/8\u0027))` | `true` | both mask to `00001010` |\n| `new Address4(\u002710.0.0.1\u0027).isInSubnet(new Address6(\u0027a00::/8\u0027))` | `true` | the same bits, reversed |\n| `new Address4(\u002732.0.0.1\u0027).isInSubnet(new Address6(\u00272000::/3\u0027))` | `true` | both begin `001` |\n| `new Address4(\u002732.1.13.184\u0027).isInSubnet(new Address6(\u00272001:db8::/32\u0027))` | `true` | the `/32` spells an IPv4 address |\n| `new Address6(\u0027cb00:7100::1\u0027).isInSubnet(new Address4(\u0027203.0.113.0/24\u0027))` | `true` | the `/24` spells an IPv6 prefix |\n| `new Address4(\u002710.0.0.1\u0027).isInSubnet(new Address6(\u0027::ffff:10.0.0.0/104\u0027))` | `false` | `/104` is longer than 32 bits |\n| `new Address4(\u00278.8.8.8\u0027).isInSubnet(new Address4(\u002710.0.0.0/8\u0027))` | `false` | same-family control |\n\nIn the allowlist direction the check admits an address outside the list; in the denylist direction it blocks an address outside the list. What the coincidence can admit is narrow. An IPv6 allowlist of `/32` or shorter admits the IPv4 addresses its prefix spells: `2001:db8::/32` admits exactly `32.1.13.184`, and `2000::/3` admits `32.0.0.0/3`. Those are public IPv4 addresses; the private, loopback, and link-local ranges begin with bit patterns no allocated IPv6 prefix shares. An IPv4 allowlist admits the IPv6 addresses its prefix spells, and those all sit in blocks IANA has not allocated. So a request admitted through this defect reaches an address outside the intended list, not an internal host, and the severity reflects that.\n\n### Proof of concept\n\n`npm i ip-address@10.7.0`, then:\n\n```js\nconst { Address4, Address6 } = require(\u0027ip-address\u0027);\n\n// An allowlist of the application\u0027s own IPv6 range, tested against whichever\n// family the input parses as.\nconst allowed = new Address6(\u00272001:db8::/32\u0027);\n\nfunction parse(host) {\n  return Address4.isValid(host) ? new Address4(host) : new Address6(host);\n}\n\nfor (const h of [\u00272001:db8::1\u0027, \u00272001:db9::1\u0027, \u002732.1.13.184\u0027, \u002732.1.13.185\u0027]) {\n  console.log(parse(h).isInSubnet(allowed) ? \u0027ALLOW\u0027 : \u0027BLOCK\u0027, h);\n}\n```\n\nOn affected versions:\n\n```\nALLOW 2001:db8::1\nBLOCK 2001:db9::1\nALLOW 32.1.13.184\nBLOCK 32.1.13.185\n```\n\nThe IPv6 rows are right. The IPv4 address whose 32 bits equal the allowlist\u0027s prefix is admitted; the one next to it is not.\n\n### Remediation\n\nUpgrade to the patched release. In the fix, `isHostInSubnet()` returns `false` when the two addresses are of different families, and `isInSubnet()` inherits the answer. The methods keep accepting either family so existing call sites compile. A caller that means to compare across families converts first, with `Address6.fromAddress4()`, `to4()`, or `toAddress4Nat64()`: `new Address6(\u0027::ffff:10.0.0.1\u0027).to4().isInSubnet(new Address4(\u002710.0.0.0/8\u0027))` is `true`, as before.\n\nIf you cannot upgrade immediately, compare the classes before you compare the addresses:\n\n```js\nconst contained = host.constructor === network.constructor \u0026\u0026 host.isInSubnet(network);\n```\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.",
  "id": "GHSA-j6r3-76f7-8jcv",
  "modified": "2026-09-29T23:46:52Z",
  "published": "2026-09-29T23:46:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-j6r3-76f7-8jcv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101912"
    },
    {
      "type": "WEB",
      "url": "https://github.com/beaugunderson/ip-address/commit/1343629d57fea413644a5c9d41ff1e59619f3f28"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/beaugunderson/ip-address"
    },
    {
      "type": "WEB",
      "url": "https://github.com/beaugunderson/ip-address/releases/tag/v10.7.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ip-address: isInSubnet() and isHostInSubnet() compare addresses of different families as if they shared an address space, allowing an allowlist check to admit an address outside its range"
}

CVE-2026-101912 (GCVE-0-2026-101912)

Vulnerability from cvelistv5 – Published: 2026-09-28 17:48 – Updated: 2026-09-28 19:13

Title

ip-address: isInSubnet() and isHostInSubnet() compare addresses of different families as if they shared an address space, allowing an allowlist check to admit an address outside its range

Summary

ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.7.1, the isInSubnet and isHostInSubnet methods in src/common.ts compare masked binary strings without validating that both operands use the same IP family. A cross-family containment check whose leading address bits match makes the masked strings compare equal even though IPv4 and IPv6 do not share an address space. An allowlist or denylist decision can therefore classify an address outside the intended range as contained. This issue is fixed in version 10.7.1.

Severity

6.3 (Medium)


                        
                          CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

SSVC

Exploitation: poc Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-09-28 19:13 UTC

CWE

CWE-697 - Incorrect Comparison
CWE-843 - Access of Resource Using Incompatible Type ('Type Confusion')

Assigner

GitHub_M mitre root Scorecard

References

3 references

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

Impacted products

1 product

Vendor	Product	Version
beaugunderson	ip-address	Affected: < 10.7.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-101912",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-28T19:13:19.402733Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-28T19:13:25.495Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-j6r3-76f7-8jcv"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "ip-address",
          "vendor": "beaugunderson",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 10.7.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.7.1, the isInSubnet and isHostInSubnet methods in src/common.ts compare masked binary strings without validating that both operands use the same IP family. A cross-family containment check whose leading address bits match makes the masked strings compare equal even though IPv4 and IPv6 do not share an address space. An allowlist or denylist decision can therefore classify an address outside the intended range as contained. This issue is fixed in version 10.7.1."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "LOW"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-697",
              "description": "CWE-697: Incorrect Comparison",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-843",
              "description": "CWE-843: Access of Resource Using Incompatible Type (\u0027Type Confusion\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-28T17:48:06.990Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-j6r3-76f7-8jcv",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-j6r3-76f7-8jcv"
        },
        {
          "name": "https://github.com/beaugunderson/ip-address/commit/1343629d57fea413644a5c9d41ff1e59619f3f28",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/beaugunderson/ip-address/commit/1343629d57fea413644a5c9d41ff1e59619f3f28"
        },
        {
          "name": "https://github.com/beaugunderson/ip-address/releases/tag/v10.7.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/beaugunderson/ip-address/releases/tag/v10.7.1"
        }
      ],
      "source": {
        "advisory": "GHSA-j6r3-76f7-8jcv",
        "discovery": "UNKNOWN"
      },
      "title": "ip-address: isInSubnet() and isHostInSubnet() compare addresses of different families as if they shared an address space, allowing an allowlist check to admit an address outside its range"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-101912",
    "datePublished": "2026-09-28T17:48:06.990Z",
    "dateReserved": "2026-09-28T15:55:37.907Z",
    "dateUpdated": "2026-09-28T19:13:25.495Z",
    "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.

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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-J6R3-76F7-8JCV

Summary

Details

Affected versions

Impact

Proof of concept

Remediation

A note on SSRF defense

CVE-2026-101912 (GCVE-0-2026-101912)

Tags

Sightings

Nomenclature

Related by attack behaviour