Description

pacquet, the Rust package-manager component shipped in the pnpm npm package versions >=12.0.0-alpha.0 and <12.0.0-alpha.5, does not validate dependency alias/name paths taken from a lockfile before using them in install-time filesystem joins. When a user installs a project with an attacker-supplied lockfile using --trust-lockfile or a frozen lockfile, alias entries containing path traversal segments (for example '../../escaped-link') are used when creating dependency and package links, bin destinations, hoisted entries, and virtual-store slots, allowing symlinks and directories to be created outside the intended project and node_modules boundary. Version 12.0.0-alpha.5 validates dependency names and every virtual-store slot path with a shared safe-join containment helper before any filesystem materialization, rejecting traversal, absolute, platform-specific, and reserved names with ERR_PNPM_INVALID_DEPENDENCY_NAME.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-27T18:16:30.753Z",
  "pubdate": "2026-09-27T18:16:30.753Z",
  "executiveSummary": "The Rust-based package management component, pacquet, integrated into pnpm versions >=12.0.0-alpha.0 and <12.0.0-alpha.5, contains a critical path traversal vulnerability.\nThis vulnerability arises from improper validation of dependency alias and name paths retrieved from project lockfiles during the installation phase.\nAn attacker can exploit this flaw by supplying a malicious lockfile, which, when processed with --trust-lockfile or via a frozen lockfile installation, allows for the creation of symlinks and directories outside the designated node_modules or project boundary.\nThe vulnerability grants an attacker the ability to perform arbitrary file system writes within the context of the user running the installation process.\nImpacts include potential unauthorized file overwrites, system configuration modification, or the injection of malicious binaries into system-wide paths.\nThe risk is elevated for automated CI/CD environments or developer machines where lockfiles from untrusted sources might be processed.\nRemediation requires upgrading the pnpm package to version 12.0.0-alpha.5 or later, which implements strict containment checks for all dependency names and virtual-store path materializations.",
  "technicalDetails": "The root cause of this vulnerability is the lack of input sanitization for dependency aliases and names during the filesystem joining process in pacquet. When the installer iterates through entries in a lockfile, it fails to verify that the path segments do not contain traversal sequences, such as '../../'.\nIn the vulnerable versions, the pacquet component directly consumes these path strings when constructing paths for dependency links, bin destinations, hoisted entries, and virtual-store slots. Because the system does not enforce a chroot-like boundary, these path traversal segments are resolved by the underlying OS, enabling the creation of filesystem objects at arbitrary locations relative to the working directory.\nThe attack flow begins with an attacker preparing a malicious lockfile that includes dependency names formatted with traversal characters (e.g., '../../escaped-link'). When a victim runs a pnpm installation utilizing this lockfile, pacquet interprets these entries as legitimate filesystem paths.\nThe exploitation process specifically manifests during the materialization of the virtual store. As pacquet executes the installation logic, the unsafe concatenation of the project root and the malicious dependency name allows the process to escape the intended node_modules directory. Consequently, symlinks or directories are materialized at the destination dictated by the traversal sequence.\nThis behavior exposes the host system to arbitrary write operations. For instance, an attacker could attempt to overwrite critical configuration files or place malicious executables in locations that would later be executed by the user or system processes.\nVersion 12.0.0-alpha.5 addresses this by introducing a shared safe-join containment helper. This mechanism validates every dependency name and virtual-store slot path against a strictly defined boundary policy before any filesystem operations occur. If the validator detects traversal segments, absolute paths, platform-specific exploits, or reserved names, it triggers an ERR_PNPM_INVALID_DEPENDENCY_NAME error, effectively halting the installation and preventing the traversal attempt.\nNo specific authentication or network exposure is required for exploitation; the vulnerability is triggered locally during the execution of standard package installation commands, provided the attacker can convince a user or system to process a compromised lockfile."
}