GHSA-2h3h-q99f-3fhc
HIGH@npmcli/arborist vulnerable to UNIX Symbolic Link (Symlink) Following
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
@npmcli/arboristReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Impact
Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution
@npmcli/arborist, the library that calculates dependency trees and manages the node_modules folder hierarchy for the npm command line interface, aims to guarantee that package dependency contracts will be met, and the extraction of package contents will always be performed into the expected folder.
This is, in part, accomplished by resolving dependency specifiers defined in package.json manifests for dependencies with a specific name, and nesting folders to resolve conflicting dependencies.
When multiple dependencies differ only in the case of their name, Arborist's internal data structure saw them as separate items that could coexist within the same level in the node_modules hierarchy. However, on case-insensitive file systems (such as macOS and Windows), this is not the case. Combined with a symlink dependency such as file:/some/path, this allowed an attacker to create a situation in which arbitrary contents could be written to any location on the filesystem.
For example, a package pwn-a could define a dependency in their package.json file such as "foo": "file:/some/path". Another package, pwn-b could define a dependency such as FOO: "file:foo.tgz". On case-insensitive file systems, if pwn-a was installed, and then pwn-b was installed afterwards, the contents of foo.tgz would be written to /some/path, and any existing contents of /some/path would be removed.
Anyone using npm v7.20.6 or earlier on a case-insensitive filesystem is potentially affected.
Patches
2.8.2 (included in npm v7.20.7 and above)
Fix and Caveats
There are two parts to the fix:
- Immediately prior to extraction, if the target folder is not a directory, it is moved aside. (If the installation fails, filesystem entries moved aside in this manner are moved back as part of the rollback process.)
- The
childrenmap that represents child nodes in the tree is replaced with a case-insensitive map object, such thatnode.children.get('foo')andnode.children.get('FOO')will return the same object, enabling Arborist to detect and handle this class of tree collision.
This second item imposes a caveat on case sensitive filesystems where two packages with names which differ only in case may already exist at the same level in the tree, causing unpredictable behavior in this rare edge case. Note that in such cases, the package-lock.json already creates a situation which is hazardous to use on case-sensitive filesystems, and will likely lead to other problems.
If affected by this caveat, please run npm update to rebuild your tree and generate a new package-lock.json file.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @npmcli/arborist | all versions | 2.8.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @npmcli/arborist. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @npmcli/arborist to 2.8.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2h3h-q99f-3fhc is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-2h3h-q99f-3fhc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-2h3h-q99f-3fhc. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-2h3h-q99f-3fhc in your dependencies?
O3 detects GHSA-2h3h-q99f-3fhc across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.