GHSA-QRV3-253H-G69C

Summary

Summary pnpm accepts package names from the env lockfile configDependencies section and uses those names directly when creating config dependency symlinks under nodemodules/.pnpm-config. A malicious repository can commit a crafted pnpm-lock.yaml whose env-lockfile document contains a traversal-shaped config dependency name such as ../../PWNEDCFGDEP. During pnpm install, pnpm installs the config dependency and creates a symlink at a path derived from that name. In local testing against pnpm v11.5.1, this caused pnpm to create a symlink outside the intended config dependency directory: This works with --ignore-scripts, so it does not rely on lifecycle script execution. Vulnerable behavior The vulnerable behavior appears to be that configDependencies keys from the env lockfile are trusted as package names and used in filesystem paths without rejecting traversal components. The relevant pattern is: If pkgName is attacker-controlled and contains .., then path.join(configModulesDir, pkgName) can resolve outside nodemodules/.pnpm-config. Impact A malicious project can cause pnpm to create symlinks outside the intended nodemodules/.pnpm-config directory during install. This gives an attacker a filesystem write primitive in the victim project directory, and potentially outside it with deeper traversal payloads, depending on path permissions and platform behavior. The issue is especially relevant because: The malicious input is committed in pnpm-lock.yaml. The issue is triggered during pnpm install. It works with --ignore-scripts. It occurs in the config dependency installation path, before ordinary dependency installation. The user only needs to install a malicious or compromised repository. Local proof of concept The following local-only PoC creates a temporary project, starts a local fake registry on 127.0.0.1, writes a malicious env-lockfile entry, runs pnpm, and checks whether pnpm created a symlink outside nodemodules/.pnpm-config. Command used: Observed output: pnpm output: The PoC then detected the escaped symlink: Malicious lockfile structure The malicious input is an env-lockfile configDependencies key containing traversal components: pnpm accepts the traversal-shaped name and reports it as installed: Security boundary violation The intended config dependency root was: But pnpm created: This demonstrates that a config dependency name from the lockfile can escape the directory where config dependencies should be linked. Suggested remediation Validate every configDependencies key loaded from the env lockfile before using it as a package name or path component. Recommended fixes: Reject env-lockfile configDependencies names that are not valid npm package names. Reject names containing absolute paths, . components, .. components, backslashes, or platform-specific path separators. Use containment-checked path joining before creating symlinks: resolve the final destination path, verify it remains inside nodemodules/.pnpm-config, reject if it escapes. Apply the same validation to config dependency subdependencies and optional dependency names read from the env lockfile. Intersect env-lockfile configDependencies with the effective pnpm-workspace.yaml configDependencies before installing, so extra lockfile-only entries are rejected. A safe destination check should enforce behavior equivalent to: Name validation should happen before this check, not instead of it.

Impact

Affected versions

Security releases

Remediation advice