CVE-2026-55700

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.

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.