Skip to content

GHSA-j6r3-76f7-8jcv CVE-2026-101912

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

Medium npm
Severity
6.3 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.37%
Chance of exploitation in the next 30 days. Higher than 31.00% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-697 Incorrect Comparison
CWE-843 Access of Resource Using Incompatible Type ('Type Confusion')
Fix
10.7.1
Upgrade ip-address to this version or later

Description

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.

Affected versions

npm

PackageVulnerableFixed in
ip-address
<= 10.7.0
No fix yet
ip-address
< 10.7.1
10.7.1

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

ip-address npm → 10.7.1

npm
npm install ip-address@10.7.1
yarn
yarn add ip-address@10.7.1
pnpm
pnpm add ip-address@10.7.1

Severity breakdown

CVSS 4.0 6.3

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

Attack vector
Network
Attack complexity
Low
Attack requirements
Present
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
Low
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

Weakness

CWE-697: Incorrect Comparison

The product compares two entities in a security-relevant context, but the comparison is incorrect.

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.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-rxp7-6hxx-x8q5
ip-address: Address6 matches a zone identifier in quadratic time ahead of its length limit, allowing a single long string to stall the process
Medium Also affects ip-address
GHSA-rpw4-54j3-4h4q
ip-address: Address6.isLinkLocal() recognizes fe80::/64 rather than fe80::/10, allowing SSRF and trust-boundary bypass to on-link hosts
Medium Also affects ip-address
GHSA-h3mg-xc3c-68pw
ip-address: Address6 builds a parse diagnostic proportional to the input with no length bound, allowing a single long string to stall or crash the process
Medium Also affects ip-address
GHSA-2vr4-cq9g-pvrc
ip-address: no classifier recognizes the NAT64 local-use range 64:ff9b:1::/48, allowing SSRF and trust-boundary bypass
Medium Also affects ip-address
GHSA-mwp4-54f8-5fhr
ip-address: Address4 decodes leading-zero octets as decimal while resolvers decode them as octal, allowing SSRF and trust-boundary bypass
High Also affects ip-address
GHSA-4xrf-jv44-h6hh
ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks
Medium Also affects ip-address
GHSA-22jq-vg5j-6vgg
ip-address: misclassification of IPv4-mapped/NAT64 IPv6 addresses can bypass SSRF and trust-boundary checks
Medium Also affects ip-address
GHSA-v2v4-37r5-5v8g
ip-address has XSS in Address6 HTML-emitting methods
Medium Also affects ip-address

Credits: waydeshi

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor