pnpm vulnerabilities

The package manager pnpm prior to version 9.15.0 mishandles overrides and global cache. Overrides from one workspace leak into npm metadata saved in global cache, potentially leading to unauthorized code execution in other workspaces.

In the pnpm package manager prior to versions 10.34.4 and 11.7.0, a crafted lockfile alias could be placed directly under a hoisted node_modules directory. Traversal aliases could escape that directory, while reserved aliases such as .bin or .pnpm could overwrite pnpm-owned layout.

pnpm before versions 10.34.4 and 11.8.0 accepts package names from the configDependencies section of pnpm-lock.yaml and uses them directly when creating config dependency symlinks under node_modules/.pnpm-config. A malicious repository can supply a crafted lock file containing a traversal-shaped config dependency name, leading to symlink creation outside the intended directory.

In pnpm prior to versions 10.34.4 and 11.7.0, a crafted patch entry could resolve outside the configured patches directory, allowing arbitrary file deletion via the pnpm patch-remove command.

The pnpm package manager from version 11.3.0 to 11.5.3 has a vulnerability where the `pnpm stage download` command derived a local filename from registry-controlled package name and version fields. A crafted manifest could escape the selected download directory and overwrite another reachable file.

In pnpm prior to versions 10.34.2 and 11.5.3, a vulnerability was discovered where manifest bin object keys such as "", ".", and ".." passed pnpm's bin-name guard. When a malicious package was installed globally, later global remove, update, or add-replacement flows could re-derive those names from the installed manifest and pass path.join(globalBinDir, binName) to removeBin. For "." this targets the global bin directory; for ".." this targets its parent.

pnpm package manager prior to versions 10.34.2 and 11.5.3 persists bootstrap metadata in the first YAML document of pnpm-lock.yaml. A malicious repository can bypass fresh package-manager resolution and cause pnpm to install and execute arbitrary code during automatic version switching.

pnpm prior to versions 10.34.2 and 11.5.3 allows installation of configDependencies declared in pnpm-workspace.yaml before command dispatch. A repository can declare pacquet or @pnpm/pacquet as a config dependency, and pnpm treats this repository-controlled dependency as an install-engine opt-in. During installation, pnpm resolves a platform-specific @pacquet/<platform>-<arch>/pacquet binary from node_modules/.pnpm-config/<packageName> and spawns it as the developer or CI user.

In pnpm prior to versions 10.34.2 and 11.5.3, the generic peer-suffix normalizer incorrectly stripped parenthesized text from git, URL, tarball, file, and other opaque locators. Approval for one source string could authorize a different attacker-controlled source whose locator normalized to the same value.

A vulnerability in pnpm package manager prior to versions 10.34.2 and 11.5.3 expands ${ENV_VAR} placeholders from repository-controlled .npmrc and pnpm-workspace.yaml files into registry request destinations and credentials. A malicious repository can send victim environment secrets to an attacker-selected registry before lifecycle scripts run.

In pnpm before versions 10.34.0 and 11.4.0, `pnpm install` in non-frozen mode can accept new remote package content after detecting an integrity mismatch with pnpm-lock.yaml. Even though the package is locked with an integrity value and the registry returns different data, pnpm performs a resolution repair, updates the lockfile, and installs the new content, exiting successfully.

In pnpm before versions 10.34.0 and 11.4.0, the tarball extraction worker skips integrity verification when the integrity field is missing from pnpm-lock.yaml. An attacker can remove this field and serve altered package content, allowing installation of modified packages without integrity errors.

pnpm before versions 10.34.0 and 11.4.0 can send user-level unscoped npm authentication credentials to a registry chosen by a repository-local .npmrc file. In the reproduced case, the user's npm config contains a default registry and an unscoped _authToken, while the repository only sets registry= to a different registry URL. During normal pnpm workflows, the user's credentials are bound to the repository-selected registry and sent as an Authorization header.

pnpm before versions 10.34.0 and 11.4.0 allows a transitive dependency alias from registry package metadata to contain path traversal segments. During install, pnpm uses that alias as a filesystem path when linking dependency nodes, enabling an attacker to replace paths in the current project with symlinks to attacker-controlled directories.

A vulnerability in pnpm package manager prior to versions 10.34.0 and 11.4.0 allows an attacker to write or delete arbitrary files on the filesystem during pnpm install. The issue stems from missing path validation in .patch files, enabling the use of ../ sequences to escape the package directory.

A vulnerability in pnpm package manager before versions 10.34.0 and 11.4.0 allows an attacker to inject Git options into the git fetch command via a malicious lockfile. Lack of validation of the commit value in the lockfile enables substitution of the --upload-pack option, which for SSH and local transports can lead to arbitrary command execution.

A vulnerability in pnpm package manager prior to versions 10.33.4 and 11.0.7 allows a malicious codeload.github.com server to serve arbitrary tarballs, which pnpm will install regardless of the lockfile. The lockfile does not store hashes for dependencies from this server, enabling package substitution.

pnpm is a package manager that has a Command Injection vulnerability in versions 6.25.0 through 10.26.2 when using environment variable substitution in .npmrc configuration files with tokenHelper settings. An attacker who can control environment variables during pnpm operations could achieve Remote Code Execution (RCE) in build environments.

The pnpm package manager versions 10.0.0 through 10.25 allow git-hosted dependencies to execute arbitrary code during pnpm install, bypassing the v10 security feature that disables dependency lifecycle scripts by default. Although pnpm v10 blocks postinstall scripts via the onlyBuiltDependencies mechanism, git dependencies can still execute prepare, prepublish, and prepack scripts during the fetch phase, enabling remote code execution without user consent.

pnpm versions 10.26.2 and below store HTTP tarball dependencies (and git-hosted tarballs) in the lockfile without integrity hashes. This allows the remote server to serve different content on each install, even when a lockfile is committed.

pnpm is a package manager that prior to version 10.0.0 used the md5 function for path shortening. In case of a collision, different libraries could share the same storage path, leading to version identification issues.

In pnpm, a package manager, it is possible to construct a tarball that appears safe when installed via npm but is malicious when installed via pnpm. This can lead to a safe package from npm being replaced with a malicious version when using pnpm.