CVE-2026-82392 in pnpm
Summary
by MITRE • 09/01/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified involves a critical path traversal flaw within the pnpm package manager, specifically affecting versions prior to 10.34.5 and those ranging from 11.0.0 through 11.11.0. This security issue stems from improper validation of input data derived from attacker-controlled lockfiles, which allows for arbitrary file system writes and potential remote code execution under specific configuration conditions. The core technical flaw resides in the mechanism used to parse package names from the pnpm-lock.yaml file. During the installation process, the software utilizes a parsing function, dp.parse(depPath).name, to extract the name of a dependency directly from keys within the lockfile provided by the user or fetched from a registry. This extracted name is then propagated through several internal modules without adequate sanitization or validation against path traversal patterns such as dot-dot-slash sequences.
The operational impact of this flaw becomes severe when the parsed package name, which may contain maliciously crafted directory traversal characters, is passed to functions responsible for file system operations. Specifically, the unvalidated name is used in conjunction with path.join() within the modules directory structure, directed toward the store controller's importPackage function, and utilized in the generation of Plug'n'Play (PnP) resolution files. Because these functions do not strictly enforce that the resulting paths remain confined to the expected project directories or node_modules folder, an attacker can manipulate the package name to write arbitrary contents outside of the intended sandboxed environment. This capability effectively breaks the isolation guarantees provided by modern JavaScript package managers, allowing malicious payloads to be placed in sensitive locations on the host file system where they may persist beyond the scope of a single installation command.
The severity of this vulnerability is significantly amplified when the user's configuration permits the execution of lifecycle scripts for dependencies. If the dangerouslyAllowAllBuilds setting is enabled or if there exists an allowBuilds entry that matches the malicious package, the escaped payload can trigger executable code with the privileges of the user running pnpm install. This transforms a file system manipulation issue into a full remote code execution vector. An attacker could craft a specially designed lockfile containing dependencies with names constructed to traverse up directory levels and write backdoors or malware scripts to locations such as the project root, home directory, or other critical paths. When these packages are installed, the lifecycle hooks defined within them would execute immediately, granting the attacker control over the system environment under the context of the invoking user.
From a classification perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as it involves accessing files or directories that are outside the restricted directory intended by the application logic. Furthermore, given the potential for executing arbitrary code through lifecycle scripts triggered during package installation, it also relates to CWE-78: Improper Neutralization of Special Elements used in an OS Command (OS Command Injection) and CWE-94: Improper Control of Generation of Code (Code Injection). In terms of adversary tactics, this exploit maps to the ATT&CK technique T1059.006: PowerShell on Windows or similar script execution mechanisms depending on the operating system, as well as T1204.002: Malicious File, where malicious artifacts are dropped onto disk for later use. The attack vector is primarily remote via a crafted lockfile that might be introduced through compromised dependencies in a supply chain scenario or directly by an attacker with access to modify dependency resolution files within a project context.
Mitigation strategies must prioritize immediate upgrading of the pnpm package manager to version 10.34.5 or later, which includes patches for this path traversal and validation issue. For environments where upgrading is not immediately feasible, administrators should enforce strict configuration policies that disable dangerous build options by ensuring dangerouslyAllowAllBuilds remains false and carefully curating allowBuilds entries to exclude untrusted packages. Additionally, organizations should implement rigorous supply chain security practices, including verifying the integrity of lockfiles before installation, using automated tools to detect anomalies in dependency trees, and restricting user privileges during package management operations where possible. Regular auditing of installed dependencies and monitoring for unexpected file system changes can also help in detecting potential exploitation attempts early.