Summary
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
new Address6() and Address6.isValid() place no bound on the length of the string they parse. When the string contains a character that cannot appear in an IPv6 address, the parser builds a diagnostic that wraps every such character in a 34-byte <span class="parse-error">, so the work and the memory scale with the input rather than with an address. A 1 MiB string of ! costs about 110 MB and 70 ms of synchronous work, 8 MiB costs about 800 MB and half a second, 16 MiB throws a RangeError in place of the documented AddressError, and 32 MiB aborts the Node process. isValid() builds the diagnostic and discards it, so a caller that only asks whether a string is valid pays the full price.
An application that validates an attacker-supplied string with these methods can be stalled or crashed by a single oversized request. This is a crash on input that should have been rejected cleanly, which SECURITY.md lists as in scope.
Details
parse() in src/ipv6.ts checks for characters outside [0-9a-f:/%] and, on finding any, throws an AddressError whose parseMessage is the whole input with each offending character wrapped:
const badCharacters = address.match(constants6.RE_BAD_CHARACTERS);
if (badCharacters) {
throw new AddressError(
`Bad character${badCharacters.length > 1 ? 's' : ''} detected in address: ${badCharacters.join('')}`,
address.replace(constants6.RE_BAD_CHARACTERS, '<span class="parse-error">$1</span>'),
);
}
RE_BAD_CHARACTERS is /([^0-9a-f:/%])/gi. For an input made entirely of punctuation the match allocates one string per character, the join copies them all into the message, and the replace produces a string 34 times the input. Nothing before this point looks at the length: the constructor strips a CIDR suffix and a zone identifier and hands the rest to parse(). The RE_BAD_ADDRESS branch below it builds its diagnostic the same way at about a third of the ratio, for input in the hex-and-colon alphabet such as fffff: repeated.
parse() is reached only through the constructor, so every entry point that constructs an Address6 from a string it has not already bounded is affected: new Address6(), isValid(), both arguments of fromAddressAndMask() and fromAddressAndWildcardMask(), fromWildcard(), and the prefix argument of fromAddress4Nat64() and toAddress4Nat64(). fromURL() admits only hex, colons, and dots in a host, so it reaches the RE_BAD_ADDRESS branch and not the other. fromArpa() caps its input at 32 nibbles before constructing anything, and fromBigInt(), fromByteArray(), and fromAddress4() build the string themselves, so those are unaffected.
The replace is where size becomes fatal. V8 caps a string at 2^29 - 24 characters, so past 16 MiB of input the replace throws RangeError: Invalid string length rather than the AddressError callers catch; isValid() swallows it, but a constructor call guarded by instanceof AddressError does not. Past 32 MiB the replacement builder's internal array exceeds its maximum size and V8 aborts the process with Fatal JavaScript invalid size error, which no try/catch intercepts.
Affected versions
<= 10.7.0. The diagnostic has had this shape since the parser was written, so every release is affected.
Reachability
Reaching the sizes above requires that the application hand the parser a string it has not already bounded. A host taken from a URL or an HTTP header is bounded by the server's header limit (Node's default is 16 KB), and at that size the cost is a millisecond. The megabyte sizes need a request body the application accepts at that scale and passes through unchecked. Common body parsers default to between 100 KB and 1 MB, which caps the effect at a stall of under 100 ms per request, and the abort needs 32 MiB in a single field, which no default admits. The severity is scored for the stall, not the abort: an application that accepts 32 MiB bodies into an address parser is the exception, and the reader running one should treat this as a crash.
Proof of concept
npm i [email protected], then:
const { Address6 } = require('ip-address');
for (const mib of [1, 8]) {
const input = '!'.repeat(mib * 1024 * 1024);
const before = process.memoryUsage().heapUsed;
const start = process.hrtime.bigint();
Address6.isValid(input);
const ms = Number(process.hrtime.bigint() - start) / 1e6;
const mb = (process.memoryUsage().heapUsed - before) / 1048576;
console.log(`${mib} MiB: ${ms.toFixed(0)} ms, ${mb.toFixed(0)} MB`);
}
try {
new Address6('!'.repeat(16 * 1024 * 1024));
} catch (e) {
console.log(`16 MiB: ${e.name}: ${e.message}`);
}
new Address6('!'.repeat(32 * 1024 * 1024));
On affected versions (node 24.19.0):
1 MiB: 73 ms, 112 MB
8 MiB: 464 ms, 784 MB
16 MiB: RangeError: Invalid string length
#
# Fatal error in , line 0
# Fatal JavaScript invalid size error 142606336
#
The last line is V8 terminating the process; the script does not reach its end.
Impact
Address6.isValid() on N bytes of !, measured on node 24.19.0:
| Input | Wall time | Transient heap | Outcome |
|---|---|---|---|
| 16 KiB | 1 ms | 1 MB | false |
| 1 MiB | 73 ms | 112 MB | false |
| 8 MiB | 464 ms | 784 MB | false |
| 16 MiB | RangeError: Invalid string length from the constructor; isValid() returns false |
||
| 32 MiB | the process aborts |
The parse is synchronous, so the event loop is blocked for the whole of the wall time and nothing else on that process is served. The heap is transient and is reclaimed after the call returns, so memory does not accumulate across requests; the abort at 32 MiB is a single request. Address4 has no diagnostic of this shape and parses the same 8 MiB in a few milliseconds.
Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Upgrade to the patched release. In the fix, the constructor rejects an address longer than the family allows before parse() runs: 45 characters for IPv6 once the CIDR suffix and zone identifier are stripped (six four-digit groups, six colons, and a dotted quad, the same line CPython's ipaddress module draws), and 15 characters for IPv4. The rejection is an AddressError with no parseMessage, so isValid() returns false for the cost of a length comparison and the 32 MiB input above is rejected in the same time as a 46-character one. A zone identifier is not counted, since it never reaches the diagnostic.
This rejects nothing a previous release accepted: every string longer than the limit already failed to parse.
If you cannot upgrade immediately, reject a candidate longer than an address with a zone identifier can be before you parse it:
if (host.length > 64) throw new Error('not an IP address');
Frequently Asked Questions
- What is CVE-2026-101911? CVE-2026-101911 is a medium-severity uncontrolled resource consumption vulnerability in ip-address (npm), affecting versions <= 10.7.0. It is fixed in 10.7.1. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
- Which versions of ip-address are affected by CVE-2026-101911? ip-address (npm) versions <= 10.7.0 is affected.
- Is there a fix for CVE-2026-101911? Yes. CVE-2026-101911 is fixed in 10.7.1. Upgrade to this version or later.
- Is CVE-2026-101911 exploitable, and should I be worried? Whether CVE-2026-101911 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-101911 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-101911? Upgrade
ip-addressto 10.7.1 or later.