| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm 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. The repository does not provide a token-bearing auth line. It only sets registry= to a different registry URL. During normal pnpm metadata/install workflows, pnpm binds the user-origin unscoped credential to the repository-selected registry and sends it as an Authorization header. This vulnerability is fixed in 10.34.0 and 11.4.0. |
| pnpm is a package manager. Prior to 10.33.4 and 11.0.7, a malicious codeload.github.com server can serve whatever tarball it wants and pnpm will install it regardless of the lockfile. The lockfile does not store the hash of the dependencies from https://codeload.github.com. This means that if this server was compromised or a person's machine configuration was compromised, pnpm would download and install these dependencies. This vulnerability is fixed in 10.33.4 and 11.0.7. |
| pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm's tarball extraction worker skips integrity verification when the integrity field is absent from the lockfile resolution. If an attacker can both modify pnpm-lock.yaml to remove the integrity: field and cause the referenced registry URL to serve altered package content, pnpm install --frozen-lockfile can install the altered package without an integrity error. npm's npm ci enforces integrity by default; pnpm's behavior of silently skipping verification is a pnpm-specific fail-open gap. This vulnerability is fixed in 10.34.0 and 11.4.0. |
| pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can persist package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml. Before the patch, direct pnpm execution trusted an already resolved packageManagerDependencies entry when the committed env lockfile contained matching pnpm and @pnpm/exe versions. A malicious repository could therefore commit package-manager lockfile package records and snapshots that bypassed fresh package-manager resolution, then cause pnpm to install and execute bytes selected by that committed lockfile state during automatic version switching. This vulnerability is fixed in 10.34.2 and 11.5.3. |
| pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can install configDependencies declared in pnpm-workspace.yaml before command dispatch. Before the patch, a repository could declare pacquet or @pnpm/pacquet as a config dependency and pnpm treated that repository-controlled dependency as an install-engine opt-in. During install, pnpm resolved a platform-specific @pacquet/<platform>-<arch>/pacquet binary from node_modules/.pnpm-config/<packageName> and spawned it as the developer or CI user. This vulnerability is fixed in 10.34.2 and 11.5.3. |
| pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm and pacquet expanded ${ENV_VAR} placeholders from repository-controlled .npmrc and pnpm-workspace.yaml into registry request destinations and registry credentials. A malicious repository could cause dependency resolution to send victim environment secrets to an attacker-selected registry before lifecycle scripts run. This vulnerability is fixed in 10.34.2 and 11.5.3. |
| pnpm is a package manager. Prior to 10.34.2 and 11.5.3, the generic peer-suffix normalizer also stripped parenthesized text from git, URL, tarball, file, and other opaque locators. Approval for one source string could therefore authorize a different attacker-controlled source whose locator normalized to the same value. This vulnerability is fixed in 10.34.2 and 11.5.3. |
| pnpm is a package manager. Prior to 10.34.2 and 11.5.3, 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. This vulnerability is fixed in 10.34.2 and 11.5.3. |
| pnpm is a package manager. From 11.3.0 until 11.5.3, `pnpm stage download` 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. The merged fix validates both fields, derives one safe filename, and verifies the final destination before writing. This vulnerability is fixed in 11.5.3. |
| pnpm is a package manager. Prior to 10.34.0 and 11.4.0, `pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in pnpm-lock.yaml. When a package is already locked with an integrity value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain pnpm install then performs a resolution repair, accepts the registry's new integrity, updates the lockfile, installs the new content, and exits successfully. This means the lockfile integrity check does not act as a hard stop by default. This vulnerability is fixed in 10.34.0 and 11.4.0. |
| pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm passes the lockfile-controlled git resolution.commit value to git fetch without a -- separator or commit-format validation. For git dependencies fetched through the shallow-fetch path, a malicious lockfile can replace the expected 40-character commit hash with a Git option such as --upload-pack=<command>. For SSH and local transports, --upload-pack can execute the supplied command. HTTPS transports ignore --upload-pack, so the practical attack surface is primarily SSH or local git dependencies. This vulnerability is fixed in 10.34.0 and 11.4.0. |
| pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm's patch application pipeline (@pnpm/patch-package) performs no path validation on file paths extracted from .patch files. An attacker who contributes a malicious patch file via a pull request can write attacker-controlled content to or delete arbitrary files on the filesystem during pnpm install, as the user running the install. The diff --git header paths containing ../../ sequences traverse out of the package directory, and the traversal is difficult to catch in code review because patch file diff headers are opaque to most reviewers. This vulnerability is fixed in 10.34.0 and 11.4.0. |
| pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm allows a transitive dependency alias from registry package metadata to contain path traversal segments. During install, pnpm later uses that alias as a filesystem path when linking dependency nodes. As a result, a registry package can cause `pnpm install --ignore-scripts` to replace paths in the current project with symlinks to attacker-controlled dependency package directories. This vulnerability is fixed in 10.34.0 and 11.4.0. |
| pnpm is a package manager. Prior to version 10.28.1, a path traversal vulnerability in pnpm's tarball extraction allows malicious packages to write files outside the package directory on Windows. The path normalization only checks for `./` but not `.\`. On Windows, backslashes are directory separators, enabling path traversal. This vulnerability is Windows-only. This issue impacts Windows pnpm users and Windows CI/CD pipelines (GitHub Actions Windows runners, Azure DevOps). It can lead to overwriting `.npmrc`, build configs, or other files. Version 10.28.1 contains a patch. |
| pnpm is a package manager. Prior to version 10.28.1, a path traversal vulnerability in pnpm's binary fetcher allows malicious packages to write files outside the intended extraction directory. The vulnerability has two attack vectors: (1) Malicious ZIP entries containing `../` or absolute paths that escape the extraction root via AdmZip's `extractAllTo`, and (2) The `BinaryResolution.prefix` field is concatenated into the extraction path without validation, allowing a crafted prefix like `../../evil` to redirect extracted files outside `targetDir`. The issue impacts all pnpm users who install packages with binary assets, users who configure custom Node.js binary locations and CI/CD pipelines that auto-install binary dependencies. It can lead to overwriting config files, scripts, or other sensitive files leading to RCE. Version 10.28.1 contains a patch. |
| pnpm is a package manager. Prior to version 10.28.1, a path traversal vulnerability in pnpm's bin linking allows malicious npm packages to create executable shims or symlinks outside of `node_modules/.bin`. Bin names starting with `@` bypass validation, and after scope normalization, path traversal sequences like `../../` remain intact. This issue affects all pnpm users who install npm packages and CI/CD pipelines using pnpm. It can lead to overwriting config files, scripts, or other sensitive files. Version 10.28.1 contains a patch. |
| pnpm is a package manager. Prior to version 10.28.2, when pnpm installs a `file:` (directory) or `git:` dependency, it follows symlinks and reads their target contents without constraining them to the package root. A malicious package containing a symlink to an absolute path (e.g., `/etc/passwd`, `~/.ssh/id_rsa`) causes pnpm to copy that file's contents into `node_modules`, leaking local data. The vulnerability only affects `file:` and `git:` dependencies. Registry packages (npm) have symlinks stripped during publish and are NOT affected. The issue impacts developers installing local/file dependencies andCI/CD pipelines installing git dependencies. It can lead to credential theft via symlinks to `~/.aws/credentials`, `~/.npmrc`, `~/.ssh/id_rsa`. Version 10.28.2 contains a patch. |
| pnpm is a package manager. Prior to version 10.28.2, when pnpm processes a package's `directories.bin` field, it uses `path.join()` without validating the result stays within the package root. A malicious npm package can specify `"directories": {"bin": "../../../../tmp"}` to escape the package directory, causing pnpm to chmod 755 files at arbitrary locations. This issue only affects Unix/Linux/macOS. Windows is not affected (`fixBin` gated by `EXECUTABLE_SHEBANG_SUPPORTED`). Version 10.28.2 contains a patch. |
| pnpm is a package manager. 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. An attacker who publishes a package with an HTTP tarball dependency can serve different code to different users or CI/CD environments. The attack requires the victim to install a package that has an HTTP/git tarball in its dependency tree. The victim's lockfile provides no protection. This issue is fixed in version 10.26.0. |
| pnpm is a package manager. Versions 10.0.0 through 10.25 allow git-hosted dependencies to execute arbitrary code during pnpm install, circumventing the v10 security feature "Dependency lifecycle scripts execution disabled by default". While 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 or approval. This issue is fixed in version 10.26.0. |
