CVE-2026-69192: SSRF Bypass via Parser Differential (Octal vs Decimal) in ip-address JavaScript Library

The 'ip-address' JavaScript library is a widely utilized dependency for parsing, validating, and manipulating IPv4 and IPv6 addresses. Applications frequently leverage this package within security-critical components, such as input sanitizers and Server-Side Request Forgery (SSRF) protection layers, to validate user-supplied hostnames before issuing outbound HTTP requests.

The core of the vulnerability lies in a parser differential between the validation library and the downstream network resolution environments. While the 'ip-address' library parses input strings in a specific format, the runtime network APIs (such as Node.js's network client, getaddrinfo, and operating system resolvers) decode those same inputs differently. This structural inconsistency creates a blind spot where security boundaries can be systematically bypassed.

The vulnerability is classified under CWE-918 (Server-Side Request Forgery) and CWE-20 (Improper Input Validation). By constructing an IPv4 address containing octets with leading zeros, an unauthenticated remote attacker can force the application to treat an internal IP address as public, bypassing the intended security filters and routing arbitrary traffic to restricted resources.

The root cause of this vulnerability is a fundamental semantic mismatch during the parsing of IPv4 octets. In versions of 'ip-address' prior to 10.3.1, the library used regular expressions to identify decimal segments and subsequently converted these string segments to numeric representations using parseInt(part, 10). The inclusion of the explicit radix of 10 instructed the engine to interpret the string strictly in base-10, disregarding any leading zero markers.

For example, if an attacker provides the string '012.0.0.1', the library validates each group independently. The first group, '012', is decoded via parseInt('012', 10) to yield the decimal value 12. Consequently, the library reconstructs the normalized IP as '12.0.0.1'. Since this IP address belongs to a public class A range, validation methods like isPrivate() or isLoopback() return a boolean false value, indicating the address is safe to access.

Conversely, standard network resolution environments follow different decoding rules. Under the POSIX standard and systems implementing inet_aton or getaddrinfo, any numeric octet prefixed with a leading zero is evaluated as an octal (base-8) representation rather than base-10. Under this interpretation, the octet '012' is converted to (1 * 8^1) + (2 * 8^0) = 10. The resulting network address resolves to '10.0.0.1', which is a private RFC 1918 Class A IP address.

The vulnerability was addressed in version 10.3.1 by modifying the regular expression used for address validation and adding pre-checks within the parser. In the vulnerable version, the library relied on RE_ADDRESS in src/v4/constants.ts to identify valid IPv4 addresses. This regex allowed optional leading zeros ([01]?[0-9][0-9]?) which allowed multi-digit octets like 012 to pass validation.

// VULNERABLE REGEX IN src/v4/constants.ts
export const RE_ADDRESS =
  /^(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$/g;

The patch modified the regular expression to explicitly disallow multi-digit octets from starting with zero. In the updated implementation, single-digit octets 0-9 are allowed, and double-digit octets 10-99 or triple-digit octets 100-255 must begin with a non-zero character. This change prevents the parsing of octal representation formats.

// PATCHED REGEX IN src/v4/constants.ts
export const RE_ADDRESS =
  /^(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])$/g;

Additionally, explicit defensive checks were introduced in the initialization pipeline in src/ipv4.ts. The parser now inspects each dot-separated segment using a simple lookahead pattern /^0\d/ to throw an explicit AddressError when leading zeroes are detected before matching against the main regex.

// DEFENSIVE CHECKS ADDED IN src/ipv4.ts
parse(address: string) {
  const groups = address.split('.');
 
  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.');
  }
}

An attacker can exploit this vulnerability by submitting a crafted URL where the host portion is formatted with leading-zero IPv4 octets. In a typical scenario, an target application accepts a user-provided URL and parses the hostname to verify if it points to a restricted internal address. Because the validation layer uses ip-address, the hostname passes the check as safe.

The target application, after allowing the connection, passes the original un-normalized URL to its HTTP client (such as Axios or Node's http module). The underlying HTTP client depends on the runtime environment or system-level resolvers to resolve the hostname. The resolver decodes the leading-zero octet in octal, establishing a connection to the internal network instead of the public network representation recognized by ip-address.

This behavior bypasses blacklist and whitelist defenses. For instance, the system may prevent requests to '10.0.0.0/8', but a request to '010.0.0.1' translates to '8.0.0.1' (public) in ip-address, while standard network environments route it to '8.0.0.1' as well. In contrast, '012.0.0.1' translates to public '12.0.0.1' in ip-address, but routes to '10.0.0.1' in the system resolver, executing SSRF.

The impact of CVE-2026-69192 is high because it allows attackers to bypass boundary restrictions designed to protect private services. By leveraging this vulnerability, a remote attacker can interact with internal web servers, metadata APIs, container orchestration interfaces, or databases that are otherwise inaccessible from the public internet.

When deployed within cloud environments, SSRF can lead to the compromise of cloud credentials via access to metadata services (such as AWS IMDSv1 at 'http://169.254.169.254' or equivalent metadata endpoints in Google Cloud and Azure). Although IMDSv2 provides mitigation via session tokens, many environments still fall back to IMDSv1, rendering them vulnerable to total host takeover.

The vulnerability is tracked with a CVSS v4.0 score of 7.7, reflecting a high impact on subsequent systems. While the direct confidentiality of the target server itself is not immediately violated by the parsing library itself, the library is a critical validation control, meaning its failure directly compromises the confidentiality and integrity of subsequent internal targets.

The primary remediation strategy is upgrading the ip-address library to version 10.3.1 or higher. This update restricts the syntax allowed by the library to match strict standard dot-decimal notation, throwing a clean parsing error for any ambiguous representations.

For systems where an immediate package upgrade is not feasible, developers should implement a pre-validation filter. This filter can scan the input IP string and reject it if any octet contains a leading zero. A simple regular expression such as /\b0\d+/ can identify invalid segments in the hostname before passing the string to the validation library.

Additionally, defense-in-depth principles should be applied at the network layer. Rather than relying solely on application-level validations, organizations should implement strict egress firewalls and network segmentation. Isolating the application servers from internal administrative interfaces prevents successful SSRF even if the application-level validation is bypassed.