CVE-2026-82392: pnpm: Virtual store linker path traversal via unvalidated depPath name in lockfileToDepGraph
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 nodemodules 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pnpmto a version that resolves this vulnerability.Fixed in 10.34.5 - Upgrade
Upgrade
pnpmto a version that resolves this vulnerability.Fixed in 11.11.0 - Configuration
Ensure pnpm is not configured with dangerouslyAllowAllBuilds enabled; this setting can allow lifecycle scripts to run and execute code with the user's privileges when an escaped package is present.
pnpm dangerouslyAllowAllBuilds = false
Event History
Frequently Asked Questions
Which installations need to be remediated?
pnpm versions before 10.34.5 are affected, as are versions from 11.0.0 through 11.11.0. Upgrade to 10.34.5 or 11.11.0, as applicable.
What must an attacker provide or persuade a user to do?
The attacker needs to control a package key in pnpm-lock.yaml such that its depPath name is malicious. Exploitation occurs when a user runs pnpm install against that lockfile.
Does exploitation automatically result in code execution?
The traversal can write package contents outside node_modules during installation. Code execution with the user's privileges requires lifecycle scripts to be permitted through dangerouslyAllowAllBuilds or a matching allowBuilds entry.
What can be done if an upgrade is not immediately possible?
Avoid running pnpm install with untrusted or attacker-controlled pnpm-lock.yaml files. Do not enable dangerouslyAllowAllBuilds, and do not add allowBuilds entries for packages that may be supplied through an untrusted lockfile.