Listen to this Post
The hoisted dependency alias vulnerability tracked as GHSA‑fr4h‑3cph‑29xv / CAND‑PNPM‑059 has been patched in both pnpm and pacquet. The flaw resides in how lockfile aliases are processed during installation when packages are hoisted to the top‑level `node_modules` directory.
During a standard pnpm install, the hoisted graph builder resolves each dependency’s name and constructs filesystem paths under the hoisted `node_modules` folder. Prior to the fix, a malicious or crafted lockfile could supply an alias that contained path‑traversal sequences (e.g., ../) or reserved directory names such as `.bin` or .pnpm. Because the alias was joined directly into the hoisted directory path without sufficient sanitisation, an attacker could force the installer to write files outside the intended install root. In the worst case, this could overwrite critical pnpm‑owned layout files (like `.pnpm` or .bin), leading to arbitrary file write or denial of service.
The security boundary is enforced at two key points. In the TypeScript codebase, the shared `safeJoinModulesDir` helper (located in fs/symlink-dependency/src/safeJoinModulesDir.ts) is used as the final sink for `dep.name` before any filesystem operation. This helper rejects any name that contains traversal (../), absolute paths, platform‑specific separators, or reserved package names. At the hoisted graph level, `installing/deps-restorer/src/lockfileToHoistedDepGraph.ts` validates the parsed dependency name (dep.0.name) before adding the graph node or recursing. Both implementations return the error code `ERR_PNPM_INVALID_DEPENDENCY_NAME` when an invalid name is detected.
The Rust implementation in pacquet mirrors this logic exactly. The hoister validates `dep.0.name` in `crates/package-manager/src/hoisted_dep_graph.rs` and enforces the same containment rules via safe_join_modules_dir.rs. This ensures that the fix is consistent across both package managers.
Before the patch, a traversal alias in a hoisted lockfile would cause the package files to be extracted outside the intended installation root. With the patch applied, both pnpm and pacquet reject the alias before any graph insertion or filesystem work, so the escaped file is never created.
Comprehensive tests now cover traversal attempts, reserved aliases, and valid scoped names. The TypeScript symlink helper passes 24 tests, the exploit regression passes 1 test, and the full pacquet library suite passes 426 tests. The changes are already merged into the private security fork and are ready for review.
DailyCVE Form:
Platform: pnpm / pacquet
Version: <10.34.4, <11.7.0 (pnpm); same commit (pacquet)
Vulnerability: Path Traversal (hoisted dependency alias)
Severity: Medium
Date: June 27, 2026
Prediction: June 15, 2026 (patch in 11.7.0)
What Undercode Say:
TypeScript symlink helper tests $ pnpm --filter @pnpm/fs.symlink-dependency test PASS: 24 tests Exploit regression and positive install control $ pnpm --filter @pnpm/installing.deps-restorer test test/index.ts PASS: exploit regression and positive install control Rust library suite for pacquet $ cargo test --locked -p pacquet-package-manager --lib PASS: 426 tests Code formatting check $ cargo fmt --all -- --check PASS
Key code changes:
– `fs/symlink-dependency/src/safeJoinModulesDir.ts` – provides the TypeScript containment helper.
– `installing/deps-restorer/src/lockfileToHoistedDepGraph.ts` – validates parsed dependency name at the hoisted graph sink.
– `pacquet/crates/package-manager/src/{hoisted_dep_graph.rs, safe_join_modules_dir.rs}` – mirrors the boundary in Rust.
Validation summary:
- TypeScript symlink helper: 24 passed
- TypeScript exploit regression: 1 passed
- TypeScript positive hoisted‑install control: 1 passed
- Targeted strict TypeScript compiles: passed
- Targeted ESLint: zero errors
- Pacquet helper tests: 3 passed
- Full pacquet package‑manager library suite: 426 passed
cargo fmt, parsed two‑document lockfile validation,git diff --check: passed
Exploit:
A crafted lockfile can supply a dependency alias containing `../` sequences (e.g., "alias": "../../etc/passwd") or reserved names like `.bin` or .pnpm. When pnpm or pacquet builds the hoisted graph, it joins this alias directly under the hoisted `node_modules` directory without sanitisation. The installer then attempts to write package files to the resulting path, effectively escaping the intended install root. This allows an attacker to overwrite arbitrary files on the filesystem with contents they control, potentially leading to remote code execution or privilege escalation if critical system files are targeted.
Protection:
- Upgrade pnpm to version 10.34.4 or 11.7.0 (or later).
- Upgrade pacquet to the commit that includes the same patch (the fix is mirrored in the Rust codebase).
- If you cannot upgrade immediately, manually review your `pnpm-lock.yaml` files for any dependency aliases that contain
../, absolute paths, or reserved names (.bin,.pnpm). Remove or sanitise such entries before runningpnpm install. - Consider using a lockfile validator or pre‑commit hook that rejects suspicious alias patterns.
- Monitor your CI/CD pipelines for unexpected file writes outside the project directory.
Impact:
- Arbitrary file write – An attacker with control over the lockfile (e.g., via a compromised dependency or a malicious pull request) can write files anywhere the install process has permissions.
- Overwrite of pnpm‑owned layout – Reserved aliases like `.bin` or `.pnpm` could corrupt the internal structure of
node_modules, breaking future installs or causing undefined behaviour. - Supply‑chain risk – In a shared repository or CI environment, a malicious lockfile change could be used to stage further attacks, such as replacing executable binaries or injecting backdoors.
- No customer data exposure – This vulnerability does not directly expose sensitive data; however, arbitrary file write can be a stepping stone to more severe exploits.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
