CVE-2026-101044 in pnpm
Summary
by MITRE • 09/27/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in the pacquet component of pnpm versions 12.0.0-alpha.0 through 12.0.0-alpha.4 represents a critical path traversal flaw rooted in insufficient validation of dependency metadata prior to filesystem operations. Pacquet serves as the internal package manager logic within pnpm, responsible for resolving and installing dependencies based on lockfile specifications. The core technical deficiency lies in the failure to sanitize or validate alias names and paths extracted from the lockfile before they are utilized in install-time file system join operations. When a user executes an installation command with flags such as --trust-lockfile or utilizes a frozen lockfile, pnpm trusts the integrity of the provided package.json.lock data without rigorous scrutiny of path components embedded within dependency aliases. This lack of validation allows malicious actors to inject directory traversal sequences, such as ../../escaped-link, directly into the alias fields of the lockfile.
During the installation process, these unvalidated paths are processed by pacquet to determine where symlinks and directories should be created for dependencies, binary destinations, hoisted entries, and virtual-store slots. Because the path segments are not checked against a safe containment boundary, the file system operations proceed with the attacker-supplied relative paths. This results in the creation of symbolic links and directories outside the intended project root or node_modules directory structure. The operational impact is severe, as it enables arbitrary file write capabilities within the context of the user executing the pnpm install command. An attacker who can supply a crafted lockfile to an unsuspecting developer or CI/CD pipeline can manipulate files in sensitive locations on the host system, potentially leading to code injection, privilege escalation if combined with other vulnerabilities, or disruption of critical system configurations located outside the project sandbox.
This vulnerability aligns closely with CWE-22: Improper Limitation of a Pathname to a Restricted Directory and CWE-78: OS Command Injection via Symlink following, as it exploits the file system's handling of symbolic links to escape restricted boundaries. In terms of offensive security frameworks, this behavior is characteristic of ATT&CK technique T1059.023: Symbolic Link Following, which describes how attackers use symlinks to access files and directories that are otherwise inaccessible or outside their intended scope. The flaw specifically targets the trust boundary assumption made when lockfiles are marked as trusted, highlighting a failure in input validation at the point where external data is converted into file system actions.
The remediation for this issue was implemented in version 12.0.0-alpha.5 and later releases by introducing rigorous validation logic before any filesystem materialization occurs. The updated pacquet component now validates dependency names and every virtual-store slot path using a shared safe-join containment helper function. This helper ensures that the resolved absolute path remains within the expected project directory structure, effectively neutralizing traversal attempts. Additionally, the update rejects not only relative paths containing traversal segments but also absolute paths, platform-specific reserved names, and other invalid formats by throwing an ERR_PNPM_INVALID_DEPENDENCY_NAME error. Organizations relying on affected versions of pnpm should immediately upgrade to version 12.0.0-alpha.5 or any subsequent stable release that incorporates this fix. Furthermore, developers should maintain strict control over lockfile sources and avoid using --trust-lockfile with unverified third-party dependencies until the environment is confirmed to be running patched software.