Summary
pnpm: pacquet trust-lockfile install can create dependency symlinks outside the project
A crafted lockfile alias could reach several install-time filesystem joins. With --trust-lockfile or a frozen lockfile, traversal segments could create links outside the intended project or node_modules boundary. This patch validates dependency names and every virtual-store slot before creating directories, links, bins, or hoisted entries.
Security boundary
- A shared safe-join helper rejects traversal, absolute, platform-specific, and reserved dependency names before filesystem materialization.
- Direct and transitive dependency links, package links, bin destinations, and public/private hoist destinations use the same containment rule.
- Global virtual-store slots validate the complete slot path, including version-derived components, before directory creation.
- Snapshot slots and package names are checked before store initialization and before the current-lockfile fast path, closing the warm-install bypass.
- Rejections preserve
ERR_PNPM_INVALID_DEPENDENCY_NAME.
Exploit replay
Before the patch, pacquet install --frozen-lockfile --trust-lockfile accepted a ../../escaped-link dependency key and created a symlink outside the project. With this patch, the same lockfile is rejected before materialization and no outside link is created.
Files changed
pacquet/crates/package-manager/src/safe_join_modules_dir.rsdefines the shared containment rule.- Install, symlink, bin, hoist, virtual-store, and frozen-lockfile paths call that helper before filesystem materialization.
- The corresponding
tests.rsfiles cover every sink, including warm installs and global virtual-store slots.
Commands run
$ cargo test --locked -p pacquet-package-manager --lib
PASS: 434 tests
$ cargo clippy --locked -p pacquet-package-manager --all-targets -- --deny warnings
PASS
$ cargo fmt --all -- --check
PASS
Validation
- Full pacquet package-manager suite: 434 passed.
- Focused regressions cover direct and transitive aliases, bins, hoists, package names, global virtual-store version traversal, and a poisoned prior-install slot.
cargo clippy -p pacquet-package-manager --all-targets -- -D warnings: passed.cargo fmt --all -- --checkandgit diff --check: passed.
Compatibility
Valid unscoped and scoped dependency aliases continue to work. The reproduced escape was specific to pacquet, so this branch does not change the TypeScript CLI or the lockfile format.
Written by an agent (Codex, GPT-5).
Impact
Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.
GHSA-2RX9-3G3H-C2JV has a CVSS score of 7.1 (High). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (12.0.0-alpha.5); upgrading removes the vulnerable code path.
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
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-2RX9-3G3H-C2JV? GHSA-2RX9-3G3H-C2JV is a high-severity path traversal vulnerability in pnpm (npm), affecting versions >= 12.0.0-alpha.0, < 12.0.0-alpha.5. It is fixed in 12.0.0-alpha.5. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
- How severe is GHSA-2RX9-3G3H-C2JV? GHSA-2RX9-3G3H-C2JV has a CVSS score of 7.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of pnpm are affected by GHSA-2RX9-3G3H-C2JV? pnpm (npm) versions >= 12.0.0-alpha.0, < 12.0.0-alpha.5 is affected.
- Is there a fix for GHSA-2RX9-3G3H-C2JV? Yes. GHSA-2RX9-3G3H-C2JV is fixed in 12.0.0-alpha.5. Upgrade to this version or later.
- Is GHSA-2RX9-3G3H-C2JV exploitable, and should I be worried? Whether GHSA-2RX9-3G3H-C2JV 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-2RX9-3G3H-C2JV 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-2RX9-3G3H-C2JV? Upgrade
pnpmto 12.0.0-alpha.5 or later.