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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-31T21:17:54.033Z",
  "pubdate": "2026-08-31T21:17:54.033Z",
  "executiveSummary": "A critical path traversal vulnerability exists in pnpm, a popular package manager for Node.js, due to inadequate validation of package names defined within the pnpm-lock.yaml file.\nThe vulnerability allows an attacker to manipulate the file system during the installation process by specifying malicious package identifiers, leading to arbitrary file write operations outside of the designated node_modules directory.\nThis flaw affects pnpm versions prior to 10.34.5 and versions from 11.0.0 through 11.11.0.\nThe risk is significantly elevated when the environment configuration includes settings such as dangerouslyAllowAllBuilds or specific allowBuilds entries, which enable the execution of package lifecycle scripts.\nSuccessful exploitation grants an attacker the capability to write files to arbitrary locations on the host system, which can subsequently be leveraged to achieve Remote Code Execution (RCE) with the privileges of the user executing the pnpm install command.\nExploitation requires the victim to execute pnpm install on a maliciously crafted lockfile, typically obtained through compromised package registries or malicious repository contributions.",
  "technicalDetails": "The root cause of this vulnerability lies in the unsafe processing of the 'package name' field extracted from the pnpm-lock.yaml file. During the resolution and installation phase, pnpm uses the 'dp.parse(depPath).name' function to determine the installation directory for a package. The resulting 'pkgName' string is processed by the graph-builder components, specifically in 'deps/graph-builder/src/lockfileToDepGraph.ts' and 'pnpm11/deps/graph-builder/src/lockfileToDepGraph.ts'.\nBecause this name is used directly in filesystem operations via 'path.join(modules, pkgName)' without undergoing rigorous sanitization or validation, it is susceptible to directory traversal sequences (e.g., '../'). This allows the package manager to resolve paths outside the intended 'node_modules' target directory when interacting with 'storeController.importPackage' or the logic within 'pnpm11/lockfile/to-pnp/src/index.ts'.\nThe attack flow begins when an attacker modifies the 'pnpm-lock.yaml' file to include a malicious dependency entry. When a user runs 'pnpm install', the package manager parses this entry. Due to the lack of validation, the path traversal characters allow the installation process to write files to sensitive locations on the victim's filesystem, effectively bypassing the expected sandbox of the 'node_modules' tree.\nThe security impact is compounded by the execution of lifecycle scripts. If the user's pnpm configuration permits arbitrary code execution (specifically via 'dangerouslyAllowAllBuilds' or matching 'allowBuilds' entries), the attacker can escape the filesystem constraints to plant malicious code in executable paths or configuration files. Once the file is written to a location where a lifecycle script can be triggered or where it may be executed by the system or other processes, the attacker achieves arbitrary code execution with the privileges of the user running pnpm.\nThis vulnerability does not require authentication to the registry in the traditional sense, as the attack is facilitated by the manipulation of the local lockfile or the consumption of a tainted dependency tree. The exposure is limited to environments where pnpm performs installation processes on untrusted lockfiles."
}