CVE-2026-101911: Denial of Service via Uncontrolled Resource Consumption in ip-address Library

The ip-address package is a widely used Node.js and JavaScript library designed to parse, validate, and manipulate IPv4 and IPv6 addresses. In modern network-facing applications, this library is frequently deployed to inspect client IP addresses extracted from HTTP headers, request bodies, query parameters, or configurations. These endpoints represent a critical attack surface, as they process untrusted input before establishing security policies, checking access control lists, or preventing Server-Side Request Forgery (SSRF).

This vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). Due to the lack of early-stage length bounds on the input string, the parser attempts to process arbitrarily large data streams. This lack of validation exposes application servers to remote, unauthenticated Denial of Service (DoS) attacks.

The core of the threat lies in the synchronous nature of Node.js execution. When an application passes an unvalidated, large payload to the Address6 constructor, the single-threaded event loop becomes completely blocked. The application is unable to process concurrent network requests during this window, leading to widespread performance degradation or complete downtime.

The root cause of CVE-2026-101911 lies in the internal error-handling and diagnostic logic within the library's address-parsing engine. When an input string is determined to be malformed, the parser does not simply fail-fast. Instead, it attempts to generate an HTML-formatted diagnostic message highlighting the precise syntactic errors within the address.

To identify and highlight illegal characters, the parser executes a synchronous regular expression substitution using constants6.RE_BAD_CHARACTERS (defined as /([^0-9a-f:/%])/gi). For every invalid character encountered in the input, the engine wraps the character inside a verbose HTML span element using address.replace(constants6.RE_BAD_CHARACTERS, '<span class="parse-error">$1</span>').

This substitution introduces an expansion overhead of exactly 34 bytes for every single invalid character (27 bytes for <span class="parse-error"> and 7 bytes for </span>). Because the operation occurs synchronously on Node's single-threaded event loop, processing large strings causes two compounding failure states:

1. Memory Amplification: JavaScript engines allocate strings in a contiguous memory block. Due to V8's internal UTF-16 representation, garbage collection tracking overhead, and temporary string slice allocations during the substitution loop, the physical memory footprint grows by an amplification factor of approximately 106x compared to the original input size.

2. CPU Starvation and Engine Failure: At 16 MiB of invalid input, the generated HTML string exceeds V8's maximum allowed string length, throwing a synchronous RangeError. At 32 MiB, the allocation request exceeds contiguous heap boundary limits, forcing the V8 runtime to trigger an uncatchable Fatal JavaScript invalid size error abort, terminating the entire server process.

To understand the vulnerability and its remediation, we inspect the changes introduced in the codebase. Version 10.7.1 introduces mathematical and logical bounds checks immediately inside the constructors before any string manipulation or regular expression executions occur.

In src/ipv6.ts, the developer established that the longest valid representation of an IPv6 address is 45 characters. This includes the dual IPv4-mapped IPv6 formats (e.g., ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255). The patch implements a strict length check against this maximum theoretical limit:

// src/ipv6.ts - Patched Implementation
export class Address6 {
  constructor(address: string) {
    // ... pre-processing ...
    
    // The longest well-formed address is all but the last two groups written
    // as four hex digits with their colons, then a 15-character dotted quad:
    // 5 * (groups - 2) + 15, which is 45 for eight groups, the same line
    // CPython's ipaddress module draws. Rejecting longer input here keeps the
    // parse diagnostics, which wrap every offending character in a span,
    // proportional to an address rather than to whatever was passed in.
    const longest = this.groups * 5 + 5; // 8 * 5 + 5 = 45
 
    if (address.length > longest) {
      throw new AddressError(`IPv6 addresses are at most ${longest} characters.`);
    }
 
    this.addressMinusSuffix = address;
    this.parsedAddress = this.parse(this.addressMinusSuffix);
  }
}

Similarly, src/ipv4.ts was patched to prevent memory exhaustion by enforcing a limit of 15 characters (e.g., 255.255.255.255):

// src/ipv4.ts - Patched Implementation
export class Address4 {
  constructor(address: string) {
    // ... pre-processing ...
 
    // Four three-digit octets and three dots: the longest well-formed address
    // is 15 characters. Longer input is rejected before parsing.
    const longest = constants.GROUPS * 4 - 1; // 4 * 4 - 1 = 15
 
    if (address.length > longest) {
      throw new AddressError(`IPv4 addresses are at most ${longest} characters.`);
    }
 
    this.addressMinusSuffix = address;
    this.parsedAddress = this.parse(address);
  }
}

A critical analysis of this patch shows that it successfully mitigates the primary resource amplification path. However, developers must be aware that the length validation check occurs after the initial replacement of zone identifiers (RE_ZONE_STRING) and CIDR subnets. If these pre-processing regex operations are executed against a massively long raw input string, CPU-bound regex overhead could still occur if the raw input is not bounded upstream.

An attacker can exploit this vulnerability by submitting an excessively long string to any input field that the application parses with ip-address. Common injection vectors include HTTP request headers like X-Forwarded-For or Client-IP, query parameters, or API request fields that accept IP addresses for logging, geolocation, or rate limiting.

The attack vector requires no authentication and can be executed via simple HTTP requests. When the target application invokes new Address6(payload) or Address6.isValid(payload) on the untrusted string, the server event loop blocks.

The following diagram shows the request execution lifecycle and how the resource exhaustion occurs in vulnerable versus patched versions of the library:

In the vulnerable scenario, a payload composed of 16 million non-hexadecimal characters (such as standard exclamation marks or periods) leads to a rapid memory spike and a RangeError. Increasing the payload to 32 MiB results in an uncatchable process-level exception that terminates the Node.js process immediately, bypasses all try-catch constructs, and shuts down the microservice.

The primary remediation strategy is upgrading the ip-address dependency to version 10.7.1 or higher. The fixed version introduces early input length validation to prevent execution of the expensive diagnostics subsystem.

In environments where upgrading dependencies immediately is not feasible, application-level defensive mitigations must be implemented to protect the parsing interface:

1. Implement Early Input Length Filtering: Before passing any string to the ip-address library, enforce an explicit length constraint. No valid IP address representation (including IPv4, IPv6, zone indices, and CIDR masks) requires more than 64 characters. Reject any address strings exceeding this boundary:

function safeParseIP(inputString) {
  if (typeof inputString !== 'string' || inputString.length > 64) {
    throw new Error('Invalid IP address: input exceeds maximum allowable length.');
  }
  return new Address6(inputString);
}

2. Enforce Global Body Limits: Ensure that web application framework parsing tools (such as the body-parser middleware for Express) enforce low maximum payload limits (e.g., limiting JSON and URL-encoded bodies to less than 100 KiB) to prevent the ingestion of megabyte-scale attack strings.

3. Use Process Monitoring: Run the Node.js application within a process manager like PM2 or container orchestration systems like Kubernetes. This ensures that even if an unhandled process termination is triggered, the instance is automatically restarted to maintain service availability.