Pnpm

Arbitrary file write via path traversal in pnpm prior to 10.34.4 and 11.7.0 lets a crafted lockfile place or overwrite files outside the intended hoisted node_modules directory when a victim installs dependencies. A malicious pnpm-lock.yaml can supply an alias containing traversal sequences (e.g. ../) to escape the module directory, or use reserved aliases like .bin or .pnpm to clobber pnpm-owned layout, enabling integrity compromise of the install tree. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the flaw is remotely deliverable through shared repositories or packages and requires only that a user run an install.

Arbitrary out-of-tree file/symlink write via path traversal in pnpm before 10.34.4 and 11.8.0 allows a malicious repository to escape node_modules/.pnpm-config by committing a crafted pnpm-lock.yaml whose env-lockfile configDependencies section carries a traversal-shaped package name. When a victim runs pnpm install, pnpm trusts that attacker-controlled name and creates a config-dependency symlink at the derived path, letting an attacker place symlinks outside the intended directory. No public exploit is identified at time of analysis, but exploitation only requires the victim to install dependencies from the poisoned repo (UI:R); CVSS is 8.2 (High) with a scope change.

Arbitrary file deletion in pnpm before 10.34.4 and 11.7.0 allows a malicious project to delete any file reachable by the user when they run 'pnpm patch-remove'. A crafted patch entry escapes the configured patches directory via path traversal (CWE-22), so cloning or installing an attacker-controlled repository and running the patch-remove command destroys files outside the project. No public exploit identified at time of analysis and it is not on CISA KEV; exploitation requires the victim to run the specific command against poisoned configuration.

Information disclosure in pnpm prior to 10.34.2 and 11.5.3 allows a malicious repository to exfiltrate victim environment secrets by expanding ${ENV_VAR} placeholders in .npmrc and pnpm-workspace.yaml into registry request destinations before lifecycle scripts run. Public proof-of-concept exploit exists, though no active exploitation has been confirmed.

Missing integrity verification in pnpm's GitHub codeload dependency resolution (versions prior to 10.33.4 and 11.0.7) enables a compromised or man-in-the-middle `codeload.github.com` server to deliver arbitrary malicious tarballs that pnpm installs without hash validation. Any developer project that sources dependencies from GitHub via pnpm is exposed when running `pnpm install` on affected versions, with potential for arbitrary code execution during the install lifecycle. No public exploit code exists and there is no CISA KEV listing, but the theoretical impact includes full developer workstation compromise and downstream supply chain contamination.

Credential leakage in pnpm package manager versions prior to 10.34.0 and 11.4.0 exposes a developer's unscoped npm authentication token to attacker-controlled registries. When a project-level .npmrc overrides the registry URL without supplying its own auth token, pnpm incorrectly inherits and forwards the user's globally-configured unscoped _authToken to that foreign registry as an Authorization header. No public exploit has been identified at time of analysis, though the real-world impact is severe - a captured npm token can enable supply chain attacks via malicious package publishing.

Path traversal in pnpm before 10.34.0 and 11.4.0 lets a malicious registry package smuggle '../' segments inside a transitive dependency alias, which pnpm then trusts as a filesystem path while linking dependency nodes. During a normal install - even with `pnpm install --ignore-scripts` - this allows a published package to replace paths inside the victim's project with symlinks pointing at attacker-controlled dependency directories, corrupting project integrity and enabling downstream code execution. No public exploit is identified at time of analysis; risk is amplified because the bug fires without lifecycle scripts, defeating the `--ignore-scripts` safety habit.

Arbitrary file write and deletion in pnpm package manager (versions prior to 10.34.0 and 11.4.0) lets a malicious contributor abuse the @pnpm/patch-package pipeline, which applies `.patch` files without validating the file paths in their `diff --git` headers. Because patch diff headers are opaque to most code reviewers, an attacker can slip `../../` traversal sequences into a pull request and, when a maintainer runs `pnpm install`, write attacker-controlled content to or delete arbitrary files with the privileges of the installing user. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; the moderate-to-high CVSS of 7.3 reflects high integrity and availability impact gated by required user interaction.

Arbitrary command execution in pnpm before 10.34.0 and 11.4.0 allows a malicious lockfile to run code on a developer's machine during `pnpm install`. Because pnpm passes the lockfile-controlled `resolution.commit` to `git fetch`/`git checkout` without a `--` separator or 40-hex-character validation, an attacker can substitute the expected commit hash with a Git option such as `--upload-pack=<command>`, which Git executes for SSH and local (file://) transports. Publicly available exploit code exists (POC), but there is no public exploit identified as actively exploited; EPSS is low (0.17%, 7th percentile), consistent with a developer-targeted supply-chain vector rather than mass internet scanning.

Lockfile integrity bypass in the pnpm package manager (versions below 10.34.0, and 11.0.0 through 11.4.0) lets a malicious or compromised registry override a package version's previously recorded hash. On a plain `pnpm install` in non-frozen mode, pnpm detects the tarball-vs-lockfile integrity mismatch, warns, then silently performs a 'resolution repair' that accepts the registry's new integrity, rewrites pnpm-lock.yaml, and installs the substituted content while exiting 0. Publicly available exploit code exists (a full reproduction scenario is published in the GitHub advisory), but there is no public exploit identified as used in active attacks; EPSS is low at 0.11%.

Integrity-check bypass in the pnpm package manager (versions before 10.34.0/10.34.1 and 11.0.0-11.3.x) lets tampered packages install silently because the tarball extraction worker skips hash verification whenever the lockfile resolution has no `integrity` field. An attacker who can both edit `pnpm-lock.yaml` to drop the `integrity:` line and cause the referenced registry URL to serve altered content can push a malicious package through `pnpm install --frozen-lockfile` without any integrity error - a fail-open gap that npm's `npm ci` does not share. Publicly available exploit code exists; EPSS is low (0.12%, 2nd percentile) and the issue is not in CISA KEV.

Path traversal in pnpm's `pnpm stage download` command (versions 11.3.0 through 11.5.2) lets a malicious or compromised registry overwrite arbitrary files reachable by the user running the command. The tool built a local tarball filename directly from registry-controlled package name and version fields, so a crafted manifest (e.g. a version like `1.0.0/../../evil`) escaped the intended download directory. This is fixed in 11.5.3; no public exploit identified at time of analysis, though the fixing PR (#12303) includes proof-of-traversal test cases.

Path traversal in pnpm's global package management flows allows deletion of the global bin directory or its parent when a malicious package with specially crafted bin keys is installed. Packages carrying ".", "..", or "" as bin object keys in their manifest bypass pnpm's bin-name guard; subsequent global remove, update, or add-replacement operations re-derive those names and pass them through path.join(globalBinDir, binName) into removeBin, resolving to the bin directory itself or its parent. No public exploit has been identified at time of analysis, but fixed versions 10.34.2 and 11.5.3 are available and should be applied immediately given the supply-chain delivery mechanism.

Arbitrary code execution in the pnpm package manager (versions prior to 10.34.2 and 11.5.3) lets a malicious repository hijack pnpm's automatic version-switching mechanism. By committing crafted package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml - including matching pnpm and @pnpm/exe versions plus package records and snapshots - an attacker bypasses fresh package-manager resolution and causes pnpm to install and execute attacker-selected bytes when a developer runs pnpm in the cloned repo. No public exploit identified at time of analysis; the high CVSS of 8.8 reflects full confidentiality, integrity, and availability impact, gated only by the user running pnpm against the poisoned repository.

Arbitrary command execution in pnpm before 10.34.2 and 11.5.3 allows a malicious repository to run attacker-chosen native binaries as the developer or CI user during a routine install. The flaw stems from pnpm processing configDependencies in pnpm-workspace.yaml before command dispatch: a repo could declare pacquet/@pnpm/pacquet as a config dependency, causing pnpm to resolve a platform-specific @pacquet/<platform>-<arch>/pacquet binary from node_modules/.pnpm-config and spawn it. Publicly available exploit code exists, though EPSS is low (0.12%, 2nd percentile) and it is not in CISA KEV.

Build-script approval bypass in the pnpm package manager (versions before 10.34.2, and 11.0.0 through 11.5.2) lets an attacker-controlled dependency source run lifecycle scripts that a user only approved for a different, legitimate source. The generic peer-suffix normalizer stripped parenthesized text from opaque locators (git, URL, tarball, file), so two distinct sources could normalize to the same allowBuilds key - meaning approval of foo@https://host/pkg.tgz also authorized foo@https://host/pkg.tgz(evil). Publicly available exploit code exists (SSVC: poc) and technical impact is total, though EPSS is low at 0.11% and it is not in CISA KEV.

pnpm versions before 10.28.2 fail to validate the `directories.bin` field during package processing, allowing malicious packages to use path traversal (e.g., `../../../../tmp`) to escape the package root and chmod 755 files at arbitrary locations on Unix-like systems. Public exploit code exists for this vulnerability. The issue affects Linux, macOS, and Node.js environments but not Windows due to platform-specific protections.

pnpm versions prior to 10.28.2 fail to properly constrain symlink resolution when installing file: and git: dependencies, allowing malicious packages to copy sensitive files from the host system into node_modules and leak credentials. This affects developers using local file dependencies and CI/CD pipelines installing git-based packages, with public exploit code available. The vulnerability enables theft of credentials from locations like ~/.ssh/id_rsa and ~/.npmrc by exploiting symlinks to absolute paths outside the package root.

Pnpm versions up to 10.28.1 contains a vulnerability that allows attackers to overwriting config files, scripts, or other sensitive files (CVSS 6.5).

Path traversal in pnpm's tarball extraction on Windows allows attackers to write files outside the intended package directory by exploiting incomplete path normalization that fails to block backslash-based traversal sequences. Public exploit code exists for this vulnerability, which affects Windows developers and CI/CD pipelines (GitHub Actions, Azure DevOps) and could result in overwriting sensitive configuration files like .npmrc or build configurations. A patch is available in pnpm version 10.28.1 and later.

Path traversal in pnpm's binary fetcher (versions prior to 10.28.1) allows attackers to write files outside the intended extraction directory through malicious ZIP entries or crafted prefix values, potentially overwriting critical configuration files and scripts on affected systems. All pnpm users installing packages with binary assets are vulnerable, particularly those in CI/CD pipelines or with custom Node.js binary configurations. Public exploit code exists for this medium-severity vulnerability.

Command injection in pnpm versions 6.25.0 through 10.26.2 allows attackers controlling environment variables to execute arbitrary commands via `tokenHelper` settings in `.npmrc`, potentially leading to RCE in build environments. Public proof-of-concept exploit exists, but no known active exploitation; EPSS score indicates low exploitation probability.

Arbitrary code execution in the pnpm package manager (versions 10.0.0 through 10.25) lets a git-hosted dependency run code on a developer or CI machine during pnpm install, bypassing the v10 default protection that disables dependency lifecycle scripts. Although v10 blocks postinstall via the onlyBuiltDependencies allowlist, git dependencies still run prepare, prepublish, and prepack scripts during the fetch phase, giving remote code execution without user approval. Publicly available exploit code exists (GitHub advisory GHSA-379q-355j-w6rj), but EPSS is low (0.11%) and the issue is not listed in CISA KEV; it is fixed in version 10.26.0.

Supply-chain integrity bypass in pnpm package manager (versions ≤10.26.2, per description; GHSA states <10.26.0) allows malicious package authors to serve different tarball content on each install because HTTP/HTTPS tarball and git-hosted tarball dependencies are recorded in the lockfile without integrity hashes. Publicly available exploit code exists in the GHSA-7vhp-vf5g-r2fw advisory PoC, though EPSS remains low at 0.01% and the issue is not on CISA KEV. Any project transitively depending on a package that uses an HTTP/git tarball is exposed, and a committed lockfile offers no protection.

pnpm is a package manager. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required. Public exploit code available and no vendor patch available.

The package manager pnpm prior to version 9.15.0 seems to mishandle overrides and global cache: Overrides from one workspace leak into npm metadata saved in global cache; npm metadata from global. Rated medium severity (CVSS 5.8), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.

pnpm is a package manager. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.

PNPM v6.15.1 and below was discovered to contain an untrusted search path which causes the application to behave in unexpected ways when users execute PNPM commands in a directory containing. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.