chore(deps): update dependency ip-address to >=10.3.1 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
ip-address	>=10.1.1 → >=10.3.1

---

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

CVE-2026-54272 / GHSA-22jq-vg5j-6vgg

More information

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

• CVSS Score: 6.9 / 10 (Medium)
• Vector String: 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

References

• https://github.com/beaugunderson/ip-address/security/advisories/GHSA-22jq-vg5j-6vgg
• https://nvd.nist.gov/vuln/detail/CVE-2026-54272
• https://github.com/beaugunderson/ip-address/commit/4a1f613f4c1bec915677dea923c10aaa09361ef9
• https://github.com/beaugunderson/ip-address/releases/tag/v10.2.1
• https://github.com/advisories/GHSA-22jq-vg5j-6vgg

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks

CVE-2026-69198 / GHSA-4xrf-jv44-h6hh

More information

Details

Summary

Every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target.

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

isInSubnet in src/common.ts opens with a guard that compares the two prefix lengths:

export function isInSubnet(this, address) {
  if (this.subnetMask < address.subnetMask) {
    return false;                                  // <-- reached before any bit comparison
  }

  if (this.mask(address.subnetMask) === address.mask()) {
    return true;
  }

  return false;
}

That guard is correct for the question isInSubnet is named for — whether one network is contained in another, where a /0 network genuinely is not inside a /8. It is wrong for classification, which asks a question about the address itself and must not depend on the prefix the caller happened to write. /0 is shorter than every reference prefix in the special-use tables (loopback /8, link-local /16, CGNAT /10, ULA /7, multicast /4), so for a classification call the bit comparison is never reached and the method returns false.

The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask — the defect is solely that the containment guard sits in the classification path. Host bits are retained through parsing, so correctForm() still yields the real target and the address remains fully usable for connecting.

/0 is the universal case because it is shorter than every reference prefix, but any suffix shorter than the specific range being tested has the same effect: 10.0.0.5/7 defeats isPrivate() for 10.0.0.0/8.

Affected versions

>= 10.1.1, <= 10.2.1. 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 it and are not affected through this vector. The containment guard itself is much older, but isInSubnet alone is a subnet-containment predicate whose behavior here is correct.

This also defeats the fix released in 10.2.1 for GHSA-22jq-vg5j-6vgg: that release classifies IPv4-mapped and NAT64 addresses by their embedded IPv4 address, but the normalization is reached through isInSubnet, so ::ffff:127.0.0.1/0 reverts to being reported as non-internal.

Impact

Every classifier is affected on both Address4 and Address6. The sole exception is Address6.isLinkLocal() for native fe80::/10 addresses, which compares raw bits directly; its IPv4-mapped path is still affected.

Address	Reported as	Actually points at
127.0.0.1/0	not loopback	loopback (127.0.0.0/8)
10.0.0.1/0, 10.0.0.5/7	not private	RFC 1918 10/8
172.16.5.5/0	not private	RFC 1918 172.16/12
192.168.1.1/0	not private	RFC 1918 192.168/16
169.254.169.254/0	not link-local	link-local / cloud metadata (IMDS)
100.64.0.1/0	not CGNAT	CGNAT 100.64/10
0.0.0.0/0, 255.255.255.255/0	not unspecified / not broadcast	unspecified / broadcast
::1/0	not loopback	IPv6 loopback
fc00::1/0	not ULA, not private	IPv6 ULA fc00::/7
ff02::1/0	not multicast	IPv6 multicast
::ffff:127.0.0.1/0	not loopback	loopback, via IPv4-mapped
::ffff:169.254.169.254/0	not link-local	IMDS, via IPv4-mapped
64:ff9b::7f00:1/0	not loopback	loopback, via NAT64

getType() returns Global unicast for all of the IPv6 cases above, and getScope() follows it.

Reachability

A CIDR suffix is not legal in a URL host, so this is not reachable through the most common SSRF shape. new URL('http://127.0.0.1/0') parses hostname as 127.0.0.1 and pathname as /0, and a guard that classifies the extracted hostname is unaffected. Exploitation requires an application that accepts a bare address string that may carry a suffix and passes it to the constructor before classifying — for example an allow/deny field, a webhook target, or a proxy destination taken as a plain host rather than parsed out of a URL.

Proof of concept

npm i ip-address@10.2.1, then:

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.isPrivate() || a.isLoopback() || a.isLinkLocal() || a.isULA()
        || a.isMulticast() || a.isUnspecified();
  } catch {}
  return false;
}

for (const h of ['127.0.0.1', '10.0.0.1', '::1',
                 '127.0.0.1/0', '10.0.0.5/7', '169.254.169.254/0',
                 '::1/0', '::ffff:127.0.0.1/0', '64:ff9b::7f00:1/0']) {
  console.log(isBlocked(h) ? 'BLOCK ' : 'ALLOW ', h, '->', new (h.includes(':') ? Address6 : Address4)(h).correctForm());
}

On affected versions every suffixed internal target is allowed, and correctForm() shows the request would reach the real internal address:

BLOCK  127.0.0.1 -> 127.0.0.1
BLOCK  10.0.0.1 -> 10.0.0.1
BLOCK  ::1 -> ::1
ALLOW  127.0.0.1/0 -> 127.0.0.1
ALLOW  10.0.0.5/7 -> 10.0.0.5
ALLOW  169.254.169.254/0 -> 169.254.169.254
ALLOW  ::1/0 -> ::1
ALLOW  ::ffff:127.0.0.1/0 -> ::ffff:7f00:1
ALLOW  64:ff9b::7f00:1/0 -> 64:ff9b::7f00:1

The first three lines are blocked as expected; the same destinations with a CIDR suffix are allowed through.

Remediation

Upgrade to the patched release. In the fix, classification no longer consults the address's own prefix: a new isHostInSubnet() compares the address's host bits against the reference range only, and every classifier (isLoopback, isPrivate, isLinkLocal, isCGNAT, isMulticast, isUnspecified, isBroadcast, isULA, isMapped4, isTeredo, is6to4, isDocumentation, getType, and the IPv4-mapped/NAT64 normalization behind embeddedIPv4) uses it. isInSubnet keeps its subnet-containment semantics unchanged, including the guard that a wider network is not contained in a narrower one. After upgrading, new Address4('127.0.0.1/0').isLoopback() returns true.

If you cannot upgrade immediately, strip the suffix before classifying by re-parsing addressMinusSuffix:

const parsed = new Address4(userInput);
const host = new Address4(parsed.addressMinusSuffix);   // classify this one

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 @​hi-im-glitchless.

Severity

• CVSS Score: 6.9 / 10 (Medium)
• Vector String: 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

References

• https://github.com/beaugunderson/ip-address/security/advisories/GHSA-4xrf-jv44-h6hh
• https://github.com/beaugunderson/ip-address/commit/488fe9bc7c35363b4b090494fc38c266d217740d
• https://github.com/beaugunderson/ip-address/releases/tag/v10.2.2
• https://github.com/advisories/GHSA-4xrf-jv44-h6hh

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

ip-address: Address4 decodes leading-zero octets as decimal while resolvers decode them as octal, allowing SSRF and trust-boundary bypass

CVE-2026-69192 / GHSA-mwp4-54f8-5fhr

More information

Details

Summary

Address4 accepts an octet written with a leading zero and decodes it as decimal, while the WHATWG URL host parser, inet_aton, and getaddrinfo all decode a leading zero as octal. The library and the network stack therefore disagree about which host a string names. new Address4('012.0.0.1') reports correctForm() of 12.0.0.1 and isPrivate() of false, but fetch('http://012.0.0.1/') connects to 10.0.0.1.

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) will classify 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

Address4.parse gates untrusted input on RE_ADDRESS (src/v4/constants.ts:5), whose per-octet alternative is:

(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)

The [01]?[0-9][0-9]? branch matches a leading zero, so 012 passes validation. Every downstream decode then reads the octet with parseInt(part, 10) (src/common.ts:87), yielding 12. A resolver reading the same string treats the leading 0 as base 8 and yields 10.

The defect is in the parse gate rather than in any one classifier, so every consumer of Address4 inherits it: isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), and correctForm() are all computed from the mis-decoded octets.

Address6 already rejects this notation on its IPv4-in-IPv6 path, throwing "IPv4 addresses can't have leading zeroes." (src/ipv6.ts:751-762), so Address4 is the outlier within the library.

Affected versions

<= 10.3.0. Unlike GHSA-22jq-vg5j-6vgg and GHSA-4xrf-jv44-h6hh, which were bounded below by the is* classification API introduced in 10.1.1, this defect is in parse and reaches every release: a guard built on isInSubnet() against the RFC 1918 ranges is affected in versions predating that API.

Impact

The disagreement runs in both directions. Under-blocking is the security-relevant case; over-blocking is a correctness and availability problem.

Input	correctForm()	Classified as	Resolver reaches	Effect
012.0.0.1	12.0.0.1	public	10.0.0.1	internal target allowed
012.012.012.012	12.12.12.12	public	10.10.10.10	internal target allowed
010.0.0.1	10.0.0.1	private	8.0.0.1	public target blocked

Reachable targets are those whose leading octet is expressible as a three-character octal literal, which covers the whole of 10.0.0.0/8 and 0.0.0.0/8. A four-character octet such as 0177 for 127 is rejected by the regex, so loopback is not reachable through this path; see the note on rejection below for why rejection is not the same as safety.

Reachability

A leading-zero address is a legal URL host, so this is reachable through the ordinary URL path with no unusual application shape required:

new URL('http://012.0.0.1/').hostname   // '10.0.0.1'

This distinguishes it from GHSA-4xrf-jv44-h6hh, where the /0 CIDR suffix could not survive URL parsing and exploitation therefore required an application that accepted a bare suffix-bearing string. Here the attack rides the same code path a normal user-supplied URL takes.

Proof of concept

npm i ip-address@10.3.0, then:

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

// A guard of the shape the library documents.
function isBlocked(host) {
  return Address4.isValid(host) && new Address4(host).isPrivate();
}

for (const h of ['10.0.0.1', '012.0.0.1', '012.012.012.012']) {
  console.log(isBlocked(h) ? 'BLOCK' : 'ALLOW', h,
              '-> resolver reaches', new URL('http://' + h + '/').hostname);
}

On affected versions:

BLOCK 10.0.0.1 -> resolver reaches 10.0.0.1
ALLOW 012.0.0.1 -> resolver reaches 10.0.0.1
ALLOW 012.012.012.012 -> resolver reaches 10.10.10.10

The literal RFC 1918 address is blocked as expected; the octal-ambiguous spellings of the same destinations are allowed through.

Remediation

Upgrade to the patched release. In the fix, Address4.parse rejects any octet with a leading zero followed by further digits, mirroring the check Address6 already applies at src/ipv6.ts:751, and RE_ADDRESS is tightened so those forms no longer appear in the valid corpus. After upgrading, Address4.isValid('012.0.0.1') returns false and the constructor throws AddressError.

This rejects input that previous releases accepted. An application that deliberately feeds zero-padded addresses such as 010.010.010.010 from a legacy system must strip the padding before parsing.

If you cannot upgrade immediately, reject any host whose octets carry a leading zero before you parse it:

if (host.split('.').some((octet) => /^0\d/.test(octet))) throw new Error('ambiguous address');

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.

One specific pitfall is worth naming, because the fix above does not remove it. Address4.isValid() returning false means "this is not a dotted-quad IPv4 literal"; it does not mean "this is not an address that will reach an internal host". Every one of the following is rejected by isValid() and still resolves to loopback:

0177.0.0.1    0x7f.0.0.1    0x7f000001    2130706433
127.1         127.0.1       127.0.0.1.    １２７.0.0.1

A guard shaped if (Address4.isValid(h)) { check() } else { treatAsHostname() } therefore routes all of them past the IP check. Rejecting these is correct behavior for an IPv4 parser and is not changed by this advisory, but a guard must treat "not a valid literal" as a case to resolve and re-check, never as a case to allow.

Severity

• CVSS Score: 7.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:N

References

• https://github.com/beaugunderson/ip-address/security/advisories/GHSA-mwp4-54f8-5fhr
• https://github.com/beaugunderson/ip-address/commit/56368cb3d66c73ba0ee9b6b834fd31b22c2fd71e
• https://github.com/beaugunderson/ip-address/releases/tag/v10.3.1
• https://github.com/advisories/GHSA-mwp4-54f8-5fhr

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

beaugunderson/ip-address (ip-address)

v10.3.1

Compare Source

Full Changelog: beaugunderson/ip-address@v10.3.0...v10.3.1

v10.3.0

Compare Source

Full Changelog: beaugunderson/ip-address@v10.2.2...v10.3.0

v10.2.2

Compare Source

Full Changelog: beaugunderson/ip-address@v10.2.1...v10.2.2

v10.2.1

Compare Source

Full Changelog: beaugunderson/ip-address@v10.2.0...v10.2.1

v10.2.0

Compare Source

---

Configuration

📅 Schedule: (in timezone UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[h4yfans]

Superseded by #1356 (merged as a0177e1de), which lands this together with the other bot dependency bumps in one lockfile regenerated against current main. This PR was 160+ commits behind, so merging it directly risked a lockfile that no longer matched the manifests.

Verified on main: hono 4.13.1, ip-address 10.5.0, nanoid 5.1.16, prettier 3.9.6, motion 12.34.0.