CVE-2026-101912: ip-address IsInSubnet() And IsHostInSubnet() Compare Addresses Vulnerability

MODERATE
Advisory Identifier: GHSA-j6r3-76f7-8jcv
CWE-843 CWE-697
Published
Advisory Summary

CVE-2026-101912 is a MODERATE isinsubnet() and ishostinsubnet() compare addresses vulnerability (CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')) affecting ip-address libraries in the npm ecosystem. The issue involves 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. Remediation is available by upgrading affected packages to version 10.7.1.

CVE-2026-101912 at a Glance

CVE Identifier CVE-2026-101912
GHSA Identifier GHSA-j6r3-76f7-8jcv
Severity MODERATE
CVSS v3.1 Base Score N/A
CWE Classification CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Affected Product ip-address
Package Ecosystem npm
Published Date
Last Updated

How to Fix CVE-2026-101912

To remediate this vulnerability, upgrade all affected ip-address dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

ip-address fixed: 10.7.1
npm install ip-address@10.7.1
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls ip-address

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-101912, inspect your project dependencies using npm:

npm ls ip-address

Analyze the terminal output to locate any version of ip-address in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 10.7.1), your application is affected.

Note: The npm ls ip-address command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-843: Access of Resource Using Incompatible Type ('Type Confusion'), where the product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type. In ip-address, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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`: ```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: ```js 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: ```js 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.

CVE-2026-101912 Affected ip-address Versions

1 component(s)
Fixed Versions:
10.7.1
Product / Package Ecosystem Affected Versions Fixed Version
ip-address
npm
< 10.7.1
10.7.1

References

Frequently Asked Questions

What is CVE-2026-101912?
CVE-2026-101912 is a security vulnerability in ip-address involving 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 under CWE-843: Access of Resource Using Incompatible Type ('Type Confusion').
Which ip-address versions are affected?
Affected versions include releases prior to 10.7.1 across affected packages: ip-address.
What version fixes CVE-2026-101912?
Upgrading to 10.7.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is ip-address affected?
Yes, ip-address is affected in releases prior to 10.7.1. Upgrade your dependency to 10.7.1 or later.
What CWE is associated with CVE-2026-101912?
CVE-2026-101912 is classified under CWE-843: Access of Resource Using Incompatible Type ('Type Confusion') (The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.).
How can I check npm dependencies for CVE-2026-101912?
Run the dependency tree command: 'npm ls ip-address'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-j6r3-76f7-8jcv",
  "modified" : "2026-09-29T23:46:52Z",
  "published" : "2026-09-29T23:46:52Z",
  "aliases" : [ "CVE-2026-101912" ],
  "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\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('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.\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 < 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'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.\n\nWhich 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.\n\n### Affected versions\n\n`<= 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('a00::1').isInSubnet(new Address4('10.0.0.0/8'))` | `true` | both mask to `00001010` |\n| `new Address4('10.0.0.1').isInSubnet(new Address6('a00::/8'))` | `true` | the same bits, reversed |\n| `new Address4('32.0.0.1').isInSubnet(new Address6('2000::/3'))` | `true` | both begin `001` |\n| `new Address4('32.1.13.184').isInSubnet(new Address6('2001:db8::/32'))` | `true` | the `/32` spells an IPv4 address |\n| `new Address6('cb00:7100::1').isInSubnet(new Address4('203.0.113.0/24'))` | `true` | the `/24` spells an IPv6 prefix |\n| `new Address4('10.0.0.1').isInSubnet(new Address6('::ffff:10.0.0.0/104'))` | `false` | `/104` is longer than 32 bits |\n| `new Address4('8.8.8.8').isInSubnet(new Address4('10.0.0.0/8'))` | `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('ip-address');\n\n// An allowlist of the application's own IPv6 range, tested against whichever\n// family the input parses as.\nconst allowed = new Address6('2001:db8::/32');\n\nfunction parse(host) {\n  return Address4.isValid(host) ? new Address4(host) : new Address6(host);\n}\n\nfor (const h of ['2001:db8::1', '2001:db9::1', '32.1.13.184', '32.1.13.185']) {\n  console.log(parse(h).isInSubnet(allowed) ? 'ALLOW' : 'BLOCK', 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's 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('::ffff:10.0.0.1').to4().isInSubnet(new Address4('10.0.0.0/8'))` 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 && 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.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "ip-address"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "10.7.1"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 10.7.0"
    }
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-697", "CWE-843" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-29T23:46:52Z",
    "nvd_published_at" : "2026-09-28T18:17:21Z"
  }
}