{"id":"CVE-2026-82392","aliases":["EUVD-2026-68816","GHSA-c59q-g84q-2gj5"],"status":"published","title":"pnpm: Virtual store linker path traversal via unvalidated depPath name in lockfileToDepGraph","description":"pnpm is a package manager. Prior to 10.34.5 and from 11.0.0 until 11.11.0, pnpm parses the package name from attacker-controlled pnpm-lock.yaml packages keys with dp.parse(depPath).name and uses it without validation in deps/graph-builder/src/lockfileToDepGraph.ts and pnpm11/deps/graph-builder/src/lockfileToDepGraph.ts. The name reaches path.join(modules, pkgName), storeController.importPackage, and pnpm11/lockfile/to-pnp/src/index.ts, allowing package contents to be written outside node_modules when a user runs pnpm install. When dangerouslyAllowAllBuilds or a matching allowBuilds entry permits lifecycle scripts, the escaped package can execute code with the user's privileges. This issue is fixed in versions 10.34.5 and 11.11.0.","severity":{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00615,"percentile":0.49978,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-22"],"published":"2026-08-31T21:03:25Z","modified":"2026-10-28T02:31:13Z","fixes":[{"ecosystem":"npm","package":"pnpm","fixed_in":["10.34.5","11.11.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"pnpm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"10.34.5"}]}]},{"source":"ghsa","ecosystem":"npm","package":"pnpm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"11.0.0"},{"fixed":"11.11.0"}]}]},{"source":"osv","ecosystem":"npm","package":"pnpm","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"10.34.5"}]}]},{"source":"osv","ecosystem":"npm","package":"pnpm","ranges":[{"type":"SEMVER","events":[{"introduced":"11.0.0"},{"fixed":"11.11.0"}]}]}],"products":[{"vendor":"pnpm","product":"pnpm"}],"references":[{"url":"https://github.com/pnpm/pnpm/security/advisories/GHSA-c59q-g84q-2gj5","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/pnpm/pnpm/pull/12872","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/pnpm/pnpm/pull/12890","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/pnpm/pnpm/commit/51300fd41c5e4c8f47635108e373cc3d1f324fa7","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/pnpm/pnpm/commit/78e29fe5583a1e5d69ea05e414eff310f78d5ed9","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/pnpm/pnpm/releases/tag/v10.34.5","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/pnpm/pnpm/releases/tag/v11.11.0","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-82392","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-c59q-g84q-2gj5"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/82xxx/CVE-2026-82392.json","tags":["advisory"]},{"url":"https://github.com/pnpm/pnpm","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-82392","title":"pnpm: Virtual store linker path traversal via unvalidated depPath name in lockfileToDepGraph","description":"pnpm is a package manager. Prior to 10.34.5 and from 11.0.0 until 11.11.0, pnpm parses the package name from attacker-controlled pnpm-lock.yaml packages keys with dp.parse(depPath).name and uses it without validation in deps/graph-builder/src/lockfileToDepGraph.ts and pnpm11/deps/graph-builder/src/lockfileToDepGraph.ts. The name reaches path.join(modules, pkgName), storeController.importPackage, and pnpm11/lockfile/to-pnp/src/index.ts, allowing package contents to be written outside node_modules when a user runs pnpm install. When dangerouslyAllowAllBuilds or a matching allowBuilds entry permits lifecycle scripts, the escaped package can execute code with the user's privileges. This issue is fixed in versions 10.34.5 and 11.11.0.","status":"published","published":"2026-08-31T21:03:25.652Z","modified":"2026-09-01T14:57:53.435Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"high","assessor":"cna"}],"cwes":["CWE-22"],"updated_at":"2026-11-02T13:40:46.161838Z"}],"euvd":[{"id":"EUVD-2026-68816","description":"pnpm is a package manager. Prior to 10.34.5 and from 11.0.0 until 11.11.0, pnpm parses the package name from attacker-controlled pnpm-lock.yaml packages keys with dp.parse(depPath).name and uses it without validation in deps/graph-builder/src/lockfileToDepGraph.ts and pnpm11/deps/graph-builder/src/lockfileToDepGraph.ts. The name reaches path.join(modules, pkgName), storeController.importPackage, and pnpm11/lockfile/to-pnp/src/index.ts, allowing package contents to be written outside node_modules when a user runs pnpm install. When dangerouslyAllowAllBuilds or a matching allowBuilds entry permits lifecycle scripts, the escaped package can execute code with the user's privileges. This issue is fixed in versions 10.34.5 and 11.11.0.","status":"published","published":"2026-08-31T21:03:25Z","modified":"2026-09-01T14:57:53Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"high"}],"updated_at":"2026-11-02T18:01:18.264709Z"}],"ghsa":[{"id":"GHSA-c59q-g84q-2gj5","title":"pnpm: Virtual store linker path traversal via unvalidated depPath name in lockfileToDepGraph","description":"## Summary\n\nThe virtual store linker constructs package installation directories using `path.join(modules, pkgName)` where `pkgName` is extracted from lockfile `packages` keys via `dp.parse(depPath).name` without validation. A crafted `pnpm-lock.yaml` with traversal sequences in depPath keys (e.g., `../../../tmp/pwned@1.0.0`) causes package content to be written to arbitrary filesystem paths during `pnpm install`.\n\nThis is an incomplete fix of GHSA-fr4h-3cph-29xv — the `safeJoinModulesDir` containment helper was applied to the hoisted linker and `symlinkDependency` but NOT to the virtual store linker's `lockfileToDepGraph.ts:233`.\n\n## Details\n\n### Root Cause\n\n`dp.parse()` at `pnpm11/deps/path/src/index.ts:135` extracts the package name as:\n```typescript\nconst name = dependencyPath.substring(0, sepIndex)\n```\n\nThis is a raw substring operation with zero validation that `name` is a valid npm package name. A depPath of `../../../tmp/pwned@1.0.0` yields `name = '../../../tmp/pwned'`.\n\n### Vulnerable Code Path\n\n1. `pnpm-lock.yaml` → `lockfile.packages['../../../../../../../tmp/pwned@1.0.0']` (attacker-controlled lockfile key)\n2. `nameVerFromPkgSnapshot(depPath, pkgSnapshot)` at `lockfile/utils/src/nameVerFromPkgSnapshot.ts:16` → calls `dp.parse(depPath)` → returns `{ name: '../../../../../../../tmp/pwned' }`\n3. `lockfileToDepGraph.ts:232` → `modules = path.join(dirInVirtualStore, 'node_modules')`\n4. `lockfileToDepGraph.ts:233` → `dir = path.join(modules, pkgName)` → resolves to `/tmp/pwned` (ESCAPES virtual store)\n5. `storeController.importPackage(depNode.dir, ...)` → writes package content to the traversed path\n\n### Why Existing Defenses Don't Catch It\n\n- **`depPathToFilename()`** — replaces `/` with `+` for the `dirInVirtualStore` path, but `pkgName` comes SEPARATELY from `dp.parse()` and is NOT passed through this function\n- **`verifyLockfileResolutions()`** — validates dependency map keys (aliases) via `isValidDependencyAlias()`, but never validates the depPath keys themselves\n- **Lockfile parser** — `yaml.load(lockfileRawContent)` with no schema validation on `packages` keys\n- **`importPackage()`** — accepts `targetDir` and passes it directly to `cafsStore.importPackage(targetDir, ...)` with zero containment check\n- **Integrity verification** — requires a real fetchable package but does not validate the destination path\n\n### Escalation to RCE (non-default config)\n\nWhen `dangerouslyAllowAllBuilds: true` is configured (or the traversal package name is in the explicit `allowBuilds` list), the same traversed path is used in the rebuild phase at `after-install/src/index.ts:402,470`. The attacker's `postinstall` script then executes with the victim's shell access. Under default config, `allowBuild` returns false for unknown packages, limiting impact to arbitrary file write.\n\n### Also Affected (PnP linker)\n\nWhen `nodeLinker: pnp` is configured, `lockfileToPackageRegistry()` at `lockfile/to-pnp/src/index.ts:105-110` uses the same unvalidated `dp.parse().name` in `packageLocation` construction, allowing the `.pnp.cjs` resolver map to point outside the virtual store. This is a lower-impact variant (PnP is not the default linker).\n\n## Impact\n\nAn attacker who can commit a crafted `pnpm-lock.yaml` to a repository (or supply one via a malicious package) can cause arbitrary file writes on the machine of any user who runs `pnpm install`. Written content is the actual package files from a real npm package (attacker controls which package and which destination).\n\nTargets for arbitrary file write include:\n- `.git/hooks/pre-commit` — code execution on next git operation\n- `~/.local/bin/` — binary hijacking\n- Project source files — supply chain injection\n\n## Reproduction\n\nCraft a `pnpm-lock.yaml`:\n```yaml\nlockfileVersion: '9.0'\npackages:\n  ../../../../../../../tmp/pwned@1.0.0:\n    resolution: {integrity: sha512-\u003creal-package-integrity\u003e}\n    engines: {node: '\u003e=14'}\nsnapshots:\n  ../../../../../../../tmp/pwned@1.0.0: {}\nimporters:\n  .:\n    dependencies:\n      legitimate-name:\n        specifier: ^1.0.0\n        version: ../../../../../../../tmp/pwned@1.0.0\n```\n\nRun `pnpm install` — package content is written to `/tmp/pwned/` instead of the virtual store.\n\n## Recommended Fix\n\nApply `safeJoinModulesDir` (or equivalent validation) at:\n- `lockfileToDepGraph.ts:233` — `path.join(modules, pkgName)`\n- `after-install/src/index.ts:402` — `path.join(pkgModulesDir(depPath), pkgInfo.name)`\n- `lockfile/to-pnp/src/index.ts:105-110` — PnP `packageLocation`\n\nAlternatively, validate depPath keys during lockfile parsing to reject any that don't produce valid npm package names via `dp.parse()`.\n\n## Relationship to GHSA-fr4h-3cph-29xv\n\nGHSA-fr4h-3cph-29xv fixed the hoisted linker path (`lockfileToHoistedDepGraph.ts:222`) by adding `safeJoinModulesDir`. The same fix was NOT applied to the virtual store linker, which uses the identical `dp.parse().name → path.join()` pattern at `lockfileToDepGraph.ts:233`.","status":"published","published":"2026-09-02T14:37:13Z","modified":"2026-09-02T14:37:14Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"high"}],"cwes":["CWE-22"],"updated_at":"2026-11-02T14:41:10.121131Z"}],"nvd":[{"id":"CVE-2026-82392","description":"pnpm is a package manager. Prior to 10.34.5 and from 11.0.0 until 11.11.0, pnpm parses the package name from attacker-controlled pnpm-lock.yaml packages keys with dp.parse(depPath).name and uses it without validation in deps/graph-builder/src/lockfileToDepGraph.ts and pnpm11/deps/graph-builder/src/lockfileToDepGraph.ts. The name reaches path.join(modules, pkgName), storeController.importPackage, and pnpm11/lockfile/to-pnp/src/index.ts, allowing package contents to be written outside node_modules when a user runs pnpm install. When dangerouslyAllowAllBuilds or a matching allowBuilds entry permits lifecycle scripts, the escaped package can execute code with the user's privileges. This issue is fixed in versions 10.34.5 and 11.11.0.","status":"published","published":"2026-08-31T21:17:54.033Z","modified":"2026-09-09T21:09:13.08Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"high","assessor":"secondary"}],"cwes":["CWE-22"],"updated_at":"2026-11-02T14:12:42.691315Z"}],"osv":[{"id":"CVE-2026-82392","title":"pnpm: Virtual store linker path traversal via unvalidated depPath name in lockfileToDepGraph","description":"pnpm is a package manager. Prior to 10.34.5 and from 11.0.0 until 11.11.0, pnpm parses the package name from attacker-controlled pnpm-lock.yaml packages keys with dp.parse(depPath).name and uses it without validation in deps/graph-builder/src/lockfileToDepGraph.ts and pnpm11/deps/graph-builder/src/lockfileToDepGraph.ts. The name reaches path.join(modules, pkgName), storeController.importPackage, and pnpm11/lockfile/to-pnp/src/index.ts, allowing package contents to be written outside node_modules when a user runs pnpm install. When dangerouslyAllowAllBuilds or a matching allowBuilds entry permits lifecycle scripts, the escaped package can execute code with the user's privileges. This issue is fixed in versions 10.34.5 and 11.11.0.","status":"published","published":"2026-08-31T21:03:25.652Z","modified":"2026-10-28T02:31:13.469613244Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"high"}],"cwes":["CWE-22"],"updated_at":"2026-11-02T15:45:18.131258Z"},{"id":"GHSA-c59q-g84q-2gj5","title":"pnpm: Virtual store linker path traversal via unvalidated depPath name in lockfileToDepGraph","description":"## Summary\n\nThe virtual store linker constructs package installation directories using `path.join(modules, pkgName)` where `pkgName` is extracted from lockfile `packages` keys via `dp.parse(depPath).name` without validation. A crafted `pnpm-lock.yaml` with traversal sequences in depPath keys (e.g., `../../../tmp/pwned@1.0.0`) causes package content to be written to arbitrary filesystem paths during `pnpm install`.\n\nThis is an incomplete fix of GHSA-fr4h-3cph-29xv — the `safeJoinModulesDir` containment helper was applied to the hoisted linker and `symlinkDependency` but NOT to the virtual store linker's `lockfileToDepGraph.ts:233`.\n\n## Details\n\n### Root Cause\n\n`dp.parse()` at `pnpm11/deps/path/src/index.ts:135` extracts the package name as:\n```typescript\nconst name = dependencyPath.substring(0, sepIndex)\n```\n\nThis is a raw substring operation with zero validation that `name` is a valid npm package name. A depPath of `../../../tmp/pwned@1.0.0` yields `name = '../../../tmp/pwned'`.\n\n### Vulnerable Code Path\n\n1. `pnpm-lock.yaml` → `lockfile.packages['../../../../../../../tmp/pwned@1.0.0']` (attacker-controlled lockfile key)\n2. `nameVerFromPkgSnapshot(depPath, pkgSnapshot)` at `lockfile/utils/src/nameVerFromPkgSnapshot.ts:16` → calls `dp.parse(depPath)` → returns `{ name: '../../../../../../../tmp/pwned' }`\n3. `lockfileToDepGraph.ts:232` → `modules = path.join(dirInVirtualStore, 'node_modules')`\n4. `lockfileToDepGraph.ts:233` → `dir = path.join(modules, pkgName)` → resolves to `/tmp/pwned` (ESCAPES virtual store)\n5. `storeController.importPackage(depNode.dir, ...)` → writes package content to the traversed path\n\n### Why Existing Defenses Don't Catch It\n\n- **`depPathToFilename()`** — replaces `/` with `+` for the `dirInVirtualStore` path, but `pkgName` comes SEPARATELY from `dp.parse()` and is NOT passed through this function\n- **`verifyLockfileResolutions()`** — validates dependency map keys (aliases) via `isValidDependencyAlias()`, but never validates the depPath keys themselves\n- **Lockfile parser** — `yaml.load(lockfileRawContent)` with no schema validation on `packages` keys\n- **`importPackage()`** — accepts `targetDir` and passes it directly to `cafsStore.importPackage(targetDir, ...)` with zero containment check\n- **Integrity verification** — requires a real fetchable package but does not validate the destination path\n\n### Escalation to RCE (non-default config)\n\nWhen `dangerouslyAllowAllBuilds: true` is configured (or the traversal package name is in the explicit `allowBuilds` list), the same traversed path is used in the rebuild phase at `after-install/src/index.ts:402,470`. The attacker's `postinstall` script then executes with the victim's shell access. Under default config, `allowBuild` returns false for unknown packages, limiting impact to arbitrary file write.\n\n### Also Affected (PnP linker)\n\nWhen `nodeLinker: pnp` is configured, `lockfileToPackageRegistry()` at `lockfile/to-pnp/src/index.ts:105-110` uses the same unvalidated `dp.parse().name` in `packageLocation` construction, allowing the `.pnp.cjs` resolver map to point outside the virtual store. This is a lower-impact variant (PnP is not the default linker).\n\n## Impact\n\nAn attacker who can commit a crafted `pnpm-lock.yaml` to a repository (or supply one via a malicious package) can cause arbitrary file writes on the machine of any user who runs `pnpm install`. Written content is the actual package files from a real npm package (attacker controls which package and which destination).\n\nTargets for arbitrary file write include:\n- `.git/hooks/pre-commit` — code execution on next git operation\n- `~/.local/bin/` — binary hijacking\n- Project source files — supply chain injection\n\n## Reproduction\n\nCraft a `pnpm-lock.yaml`:\n```yaml\nlockfileVersion: '9.0'\npackages:\n  ../../../../../../../tmp/pwned@1.0.0:\n    resolution: {integrity: sha512-\u003creal-package-integrity\u003e}\n    engines: {node: '\u003e=14'}\nsnapshots:\n  ../../../../../../../tmp/pwned@1.0.0: {}\nimporters:\n  .:\n    dependencies:\n      legitimate-name:\n        specifier: ^1.0.0\n        version: ../../../../../../../tmp/pwned@1.0.0\n```\n\nRun `pnpm install` — package content is written to `/tmp/pwned/` instead of the virtual store.\n\n## Recommended Fix\n\nApply `safeJoinModulesDir` (or equivalent validation) at:\n- `lockfileToDepGraph.ts:233` — `path.join(modules, pkgName)`\n- `after-install/src/index.ts:402` — `path.join(pkgModulesDir(depPath), pkgInfo.name)`\n- `lockfile/to-pnp/src/index.ts:105-110` — PnP `packageLocation`\n\nAlternatively, validate depPath keys during lockfile parsing to reject any that don't produce valid npm package names via `dp.parse()`.\n\n## Relationship to GHSA-fr4h-3cph-29xv\n\nGHSA-fr4h-3cph-29xv fixed the hoisted linker path (`lockfileToHoistedDepGraph.ts:222`) by adding `safeJoinModulesDir`. The same fix was NOT applied to the virtual store linker, which uses the identical `dp.parse().name → path.join()` pattern at `lockfileToDepGraph.ts:233`.","status":"published","published":"2026-09-02T14:37:13Z","modified":"2026-09-02T14:45:06.876655826Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L","level":"high"}],"cwes":["CWE-22"],"updated_at":"2026-11-02T15:46:44.571161Z"}]}}