# GHSA-jggr-w7fw-pc2j: fast-copy: Stack exhaustion in fast-copy when copying deeply-nested values > An attacker can cause a denial of service by providing deeply nested data to the fast-copy library, triggering a stack overflow error. - **Severity:** Not scored - **Exploited in the wild:** Not known - **Login needed:** Not needed - **Attackable:** Over the internet - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 5 Oct 2026 ## What is GHSA-jggr-w7fw-pc2j? GHSA-jggr-w7fw-pc2j is a denial of service vulnerability in fast-copy, published on 5 Oct 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. ### Official description ## Summary `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. ## Patches 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: ```js 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: ```js 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. ## Which versions are affected by GHSA-jggr-w7fw-pc2j? 6 open source packages ship an affected version, including fast-copy. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `fast-copy` | npm | All versions | 2.2.0 | | `fast-copy` | npm | All versions | 2.2.0 | | `fast-copy` | npm | From 3.0.0 | 3.1.0 | | `fast-copy` | npm | From 3.0.0 | 3.1.0 | | `fast-copy` | npm | From 4.0.0 | 4.1.0 | | `fast-copy` | npm | From 4.0.0 | 4.1.0 | ## How do I fix GHSA-jggr-w7fw-pc2j? Upgrade fast-copy to a fixed version for your release line: 2.2.0, 3.1.0 or 4.1.0. ## Is GHSA-jggr-w7fw-pc2j being exploited? There is no known exploitation of GHSA-jggr-w7fw-pc2j in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for GHSA-jggr-w7fw-pc2j and fix it if it is affected. What it is: GHSA-jggr-w7fw-pc2j is a denial of service vulnerability in fast-copy, published on 5 Oct 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. Exploitation: There is no known exploitation of GHSA-jggr-w7fw-pc2j in the wild and no public exploit code. Affected packages and fixed versions: - fast-copy (npm): affected all versions; fixed in 2.2.0 - fast-copy (npm): affected all versions; fixed in 2.2.0 - fast-copy (npm): affected from 3.0.0; fixed in 3.1.0 - fast-copy (npm): affected from 3.0.0; fixed in 3.1.0 - fast-copy (npm): affected from 4.0.0; fixed in 4.1.0 - fast-copy (npm): affected from 4.0.0; fixed in 4.1.0 Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/GHSA-jggr-w7fw-pc2j/ (Markdown: https://insights.sbomify.com/GHSA-jggr-w7fw-pc2j/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/GHSA-jggr-w7fw-pc2j --- From sbomify Insights: https://insights.sbomify.com/GHSA-jggr-w7fw-pc2j/ Summaries are generated and may contain mistakes; the official description above is the record.