CVE-2026-69192: ip-address Library SSRF Vulnerability

CVE-2026-69192 Overview

CVE-2026-69192 is an input validation flaw [CWE-20] in the ip-address JavaScript library, used for parsing and manipulating IPv4 and IPv6 addresses. Versions prior to 10.3.1 decode IPv4 octets with leading zeros as decimal, while WHATWG URL parsers, inet_aton, and getaddrinfo decode them as octal. This parser disagreement lets attackers bypass Server-Side Request Forgery (SSRF) filters that rely on Address4 classifiers. A string like 012.0.0.1 is reported as public 12.0.0.1 by the library, yet resolves to internal 10.0.0.1 when a request is issued.

Critical Impact
SSRF filters, allowlists, and trust-boundary decisions built on isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), and correctForm() can be bypassed, allowing internal network targets to be reached from external input.

Affected Products

ip-address npm library versions prior to 10.3.1
Applications using Address4 for SSRF protection or trust-boundary checks
Downstream packages and services that depend on ip-address for IPv4 classification

Discovery Timeline

2026-08-03 - CVE-2026-69192 published to NVD
2026-08-04 - Last updated in NVD database
Patch released - ip-address version 10.3.1 published on GitHub

Technical Details for CVE-2026-69192

Vulnerability Analysis

The defect lies in the parse gate of Address4, not in any single classifier. When Address4 receives an IPv4 string containing an octet with a leading zero, it accepts the input and decodes each octet as base-10. Network stacks and URL parsers that consume the same string treat leading-zero octets as octal per BSD inet_aton semantics.

This produces a semantic split between the security check and the actual network call. new Address4('012.0.0.1') yields correctForm() of 12.0.0.1 and isPrivate() returns false. A subsequent fetch('http://012.0.0.1/') connects to 10.0.0.1, an RFC 1918 private address. Every downstream classifier inherits the flawed decode: isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), and isHostInSubnet() all return values derived from the mis-parsed octets.

Root Cause

The parse function in src/ipv4.ts split the address on . and accepted any group matching the address regex, without rejecting octets with a leading zero followed by additional digits. Because JavaScript's parseInt in the parsing path treats these tokens as decimal, the library and the underlying host resolver disagreed.

Attack Vector

An attacker supplies a URL or hostname containing octal-notation octets to an application that uses Address4 to validate targets before issuing a network request. The application classifies the address as external and forwards the request. The runtime resolver interprets the string as octal and connects to an internal host, cloud metadata service, or loopback interface.

typescript

// Security patch in src/ipv4.ts (v10.3.1)
// Source: https://github.com/beaugunderson/ip-address/commit/56368cb3d66c73ba0ee9b6b834fd31b22c2fd71e
  parse(address: string) {
    const groups = address.split('.');

+   // Checked before the general match so the error names the actual problem.
+   // Address6 rejects the same notation on its v4-in-v6 path.
+   if (groups.some((group) => /^0\d/.test(group))) {
+     throw new AddressError("IPv4 addresses can't have leading zeroes.");
+   }
+
    if (!address.match(constants.RE_ADDRESS)) {
      throw new AddressError('Invalid IPv4 address.');
    }

The patch rejects any octet matching /^0\d/ before further parsing. A parallel fix in src/ipv6.ts rejects stacked subnet suffixes such as ::/0/1 that survived the previous suffix-stripping logic.

typescript

// Security patch in src/ipv6.ts (v10.3.1)
// Source: https://github.com/beaugunderson/ip-address/commit/56368cb3d66c73ba0ee9b6b834fd31b22c2fd71e
      address = address.replace(constants6.RE_SUBNET_STRING, '');
-   } else if (/\//.test(address)) {
+   }
+
+   // RE_SUBNET_STRING anchors on the end of the address, so it strips only
+   // the trailing suffix. A second one left behind (`::/0/1`) is malformed
+   // and must be rejected rather than parsed as an address group.
+   if (/\//.test(address)) {
      throw new AddressError('Invalid subnet mask.');
    }

Detection Methods for CVE-2026-69192

Indicators of Compromise

Outbound HTTP or DNS requests from application servers to RFC 1918 ranges, 127.0.0.0/8, 169.254.169.254, or cloud metadata endpoints
Application logs showing user-supplied URLs containing IPv4 octets prefixed with 0 (for example 012.0.0.1, 0177.0.0.1, 0250.0.0.1)
Web server access logs with Host headers or URL parameters matching the regex \b0\d+\.\d+\.\d+\.\d+\b

Detection Strategies

Perform software composition analysis to identify projects using ip-address at versions < 10.3.1 in package.json and package-lock.json.
Deploy web application firewall rules that reject inbound parameters containing IPv4 octets with leading zeros.
Compare application-layer target classifications against actual socket destinations to surface parser-resolver mismatches.

Monitoring Recommendations

Alert on egress traffic from internet-facing services to internal subnets, loopback, and link-local ranges.
Instrument SSRF-protective code paths to log the parsed host, classifier verdict, and resolved IP for post-request correlation.
Monitor for high-cardinality URL parameters containing non-standard IPv4 formats, including octal, hexadecimal, and dotless integer notation.

How to Mitigate CVE-2026-69192

Immediate Actions Required

Upgrade ip-address to version 10.3.1 or later in all direct and transitive dependencies.
Audit SSRF and allowlist logic that relies on Address4 classifiers such as isPrivate(), isLoopback(), and isInSubnet().
Reject user-supplied hostnames containing IPv4 octets with a leading zero at the input boundary.

Patch Information

The fix is included in ip-addressv10.3.1, released with commit 56368cb. Full advisory details are available in GHSA-mwp4-54f8-5fhr.

Workarounds

Normalize IPv4 inputs before validation by rejecting any octet matching /^0\d/ or by resolving the target through dns.lookup and validating the returned numeric address.
Enforce SSRF protection at the network layer using egress firewalls that block traffic to internal ranges, rather than relying solely on application-layer classification.
Validate that any URL host resolves to an expected public range after DNS resolution and before the outbound request is made.

bash

# Upgrade to the patched version
npm install ip-address@^10.3.1

# Verify the installed version across the dependency tree
npm ls ip-address

# Audit for known advisories in the project
npm audit --production