GHSA-h3mg-xc3c-68pw CVE-2026-101911
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
- Severity
- 6.3 / 10
- Medium · CVSS 4.0
- Exploit chance (EPSS)
- 0.38%
- Chance of exploitation in the next 30 days. Higher than 32.36% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-400 Uncontrolled Resource Consumption
- CWE-770 Allocation of Resources Without Limits or Throttling
- Fix
10.7.1- Upgrade ip-address to this version or later
Description
Summary
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.
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.
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 ip-address@10.7.0, 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.
Remediation
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');
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| ip-address | <= 10.7.0 |
No fix yet |
| ip-address | < 10.7.1 |
10.7.1 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
ip-address npm → 10.7.1
- npm
npm install ip-address@10.7.1- yarn
yarn add ip-address@10.7.1- pnpm
pnpm add ip-address@10.7.1
Severity breakdown
CVSS 4.0 6.3
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- Low
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
Weakness
CWE-400: Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource.
How to prevent it
- Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
- Implementation: Ensure that all failures in resource allocation place the system into a safe posture.
CWE-770: Allocation of Resources Without Limits or Throttling
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.
How to prevent it
- Requirements: Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
- Architecture and Design: Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.
- Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
- Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.
- Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
- Architecture and Design, Implementation: If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery. Ensure that all failures in resource allocation place the system into a safe posture.
- Operation, Architecture and Design: Use quotas or other resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
References
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-rxp7-6hxx-x8q5 ip-address: Address6 matches a zone identifier in quadratic time ahead of its length limit, allowing a single long string to stall the process | Medium | Also affects ip-address |
| GHSA-rpw4-54j3-4h4q ip-address: Address6.isLinkLocal() recognizes fe80::/64 rather than fe80::/10, allowing SSRF and trust-boundary bypass to on-link hosts | Medium | Also affects ip-address |
| GHSA-j6r3-76f7-8jcv ip-address: isInSubnet() and isHostInSubnet() compare addresses of different families as if they shared an address space, allowing an allowlist check to admit an address outside its range | Medium | Also affects ip-address |
| GHSA-2vr4-cq9g-pvrc ip-address: no classifier recognizes the NAT64 local-use range 64:ff9b:1::/48, allowing SSRF and trust-boundary bypass | Medium | Also affects ip-address |
| GHSA-mwp4-54f8-5fhr ip-address: Address4 decodes leading-zero octets as decimal while resolvers decode them as octal, allowing SSRF and trust-boundary bypass | High | Also affects ip-address |
| GHSA-4xrf-jv44-h6hh ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks | Medium | Also affects ip-address |
| GHSA-22jq-vg5j-6vgg ip-address: misclassification of IPv4-mapped/NAT64 IPv6 addresses can bypass SSRF and trust-boundary checks | Medium | Also affects ip-address |
| GHSA-v2v4-37r5-5v8g ip-address has XSS in Address6 HTML-emitting methods | Medium | Also affects ip-address |
Credits: waydeshi
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor