Summary
fast-copy: Stack exhaustion in fast-copy when copying deeply-nested values
fast-copy traverses values recursively with no bound on depth. Copying a sufficiently deeply-nested value exhausts the JavaScript call stack and throws a native RangeError: Maximum call stack size exceeded from inside the library.
Details
Both copy and copyStrict recurse once per level of nesting. The value does not need to be circular (circular references were already handled correctly via an internal cache) and it does not need to be large. A plain object nested a few thousand levels deep is only a few
kilobytes of equivalent JSON.
Measured depths at which copying begins to fail (Node.js, V8; the exact ceiling varies with JIT state and the stack available to the environment):
| Call | Last depth that copies successfully |
|---|---|
copy(object) |
2811 |
copy(array) |
3983 |
copyStrict(object) |
1874 |
copyStrict(array) |
1874 |
JSON.parse is iterative and parses deeply-nested input without difficulty, so a payload that deserializes cleanly can fail in a subsequent copy call.
Impact
The failure is a synchronous, catchable RangeError confined to the copy call that received the value. There are no memory safety concerns, no data exposure, and no effect on state outside that call. In a typical server the result is a failed request rather than a failed process.
Applications that call copy on externally-supplied data, such as request bodies, cached payloads, merged configuration, etc., do not expect a clone helper to throw may surface this as an unhandled error.
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
Fixed in 4.1.0, and backported to 3.1.0 and 2.2.0 so that every major line has a patch available without requiring a breaking upgrade.
Traversal is now bounded by a maxDepth option, defaulting to 1000, which sits below the native limit in standard environments. Exceeding it throws MaxDepthExceededError, which carries the limit that was exceeded and extends RangeError so existing handling continues to match.
The limit is configurable for consumers with legitimately deep data. On 3.x and 4.x it is set when creating a copier:
import { createCopier } from 'fast-copy';
export const copy = createCopier({ maxDepth: 5000 });
On 2.x it is passed per call, and the error is a property of the exported function rather than a named export:
import copy from 'fast-copy';
copy(value, { maxDepth: 5000 });
// detection: error instanceof copy.MaxDepthExceededError
In legacy environments without Object.setPrototypeOf, instanceof MaxDepthExceededError cannot be supported; check error.name === 'MaxDepthExceededError' or error instanceof RangeError instead.
Frequently Asked Questions
- What is GHSA-JGGR-W7FW-PC2J? GHSA-JGGR-W7FW-PC2J is a medium-severity security vulnerability in fast-copy (npm), affecting versions >= 4.0.0, < 4.1.0. It is fixed in 4.1.0, 3.1.0, 2.2.0.
- Which versions of fast-copy are affected by GHSA-JGGR-W7FW-PC2J? fast-copy (npm) versions >= 4.0.0, < 4.1.0 is affected.
- Is there a fix for GHSA-JGGR-W7FW-PC2J? Yes. GHSA-JGGR-W7FW-PC2J is fixed in 4.1.0, 3.1.0, 2.2.0. Upgrade to this version or later.
- Is GHSA-JGGR-W7FW-PC2J exploitable, and should I be worried? Whether GHSA-JGGR-W7FW-PC2J 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 GHSA-JGGR-W7FW-PC2J 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 GHSA-JGGR-W7FW-PC2J?
- Upgrade
fast-copyto 4.1.0 or later - Upgrade
fast-copyto 3.1.0 or later - Upgrade
fast-copyto 2.2.0 or later
- Upgrade