CVE-2026-55698: pnpm Package Manager Supply-Chain Attack via Lockfile Injection

Technical summary

The vulnerability exists in how pnpm handles bootstrap metadata persisted in the first YAML document of pnpm-lock.yaml. When pnpm performs automatic version switching, it references the packageManagerDependencies entry from the committed lockfile. Prior to the fix, if this entry contained versions matching the resolved pnpm and @pnpm/exe already present, pnpm would trust those cached package records and snapshots without re-validating or freshly resolving them from upstream sources. This bypasses the normal package integrity checks and allows an attacker who controls the repository to specify arbitrary package snapshots that pnpm will install and execute. The flaw affects both the 10.x and 11.x release lines, with fixes available in 10.34.2 and 11.5.3.

Business impact

Development teams using pnpm are at risk of supply-chain compromise if they clone repositories controlled or influenced by attackers. Since pnpm is commonly used in continuous integration, local development, and automated build pipelines, a successful attack could result in arbitrary code execution with the privileges of the developer or CI/CD system. This could lead to theft of secrets, modification of source code, injection of malicious dependencies into built artifacts, or lateral movement within development infrastructure. Organizations should prioritize patching across all development machines and CI/CD environments where pnpm is used.

Affected systems

The vulnerability affects pnpm versions prior to 10.34.2 (affecting all 10.x versions up to 10.34.1) and prior to 11.5.3 (affecting all 11.x versions up to 11.5.2). Any development environment, CI/CD pipeline, or automated build system running these versions is potentially at risk if it clones and executes pnpm commands on untrusted or compromised repositories. Organizations should inventory all installations of pnpm, including those managed via Node Version Managers (nvm, fnm, volta) or installed globally via npm, and verify they are running patched versions.

Exploitability

Exploitation requires user interaction: a developer must clone a malicious repository and execute pnpm commands (such as pnpm install or pnpm run). The attack does not require authentication, elevated privileges, or network-based exploitation—it operates at the package-manager level during normal workflow. The attack surface is particularly broad because developers routinely work with multiple open-source and third-party repositories. While the CVSS score of 8.8 reflects the severity, real-world exploitation likelihood depends on how often developers interact with untrusted code repositories, though this is common in development environments.

Remediation

Organizations should immediately update pnpm to version 10.34.2 or later for the 10.x line, or version 11.5.3 or later for the 11.x line. The patched versions include proper re-validation and fresh resolution of package-manager dependencies, preventing the bypass of integrity checks. After patching, clear any cached pnpm metadata by deleting .pnpm-store or equivalent cache directories if necessary, and verify that CI/CD pipelines and development machines are running the updated version before resuming work with potentially sensitive repositories.

Patch guidance

Patching should be prioritized across all three layers: (1) Local development machines—update pnpm globally or per-project via package.json/pnpm-workspace.yaml; (2) CI/CD systems—update pnpm in Docker images, GitHub Actions workflows, and build agent configurations; (3) Version managers—if using nvm, fnm, or volta, ensure those tools can access and install the patched versions. Verify the patch is applied by running `pnpm --version` and confirming it returns 10.34.2+ or 11.5.3+. Test patches in a non-production CI/CD environment first to ensure compatibility with existing workflows and lockfile formats.

Detection guidance

Monitor for indicators of compromise: (1) Review pnpm-lock.yaml files in version control for suspicious or unexpected packageManagerDependencies entries, particularly those referencing unknown or unusual snapshot checksums; (2) Audit execution logs in CI/CD systems for unexpected pnpm version switches or installations of unexpected binaries; (3) Check for unauthorized changes to .pnpm-store or node_modules directories, especially binaries; (4) Correlate the timing of repository clones and pnpm executions with any observed data exfiltration, credential access, or code modifications. Organizations without detailed audit logs should implement enhanced logging of pnpm operations in development and CI/CD environments.

Why prioritize this

This vulnerability should be patched urgently due to its high severity (CVSS 8.8), wide distribution of pnpm in development ecosystems, and the risk of supply-chain compromise. Unlike many vulnerabilities that require special conditions or advanced exploitation, this one can be triggered by a developer's normal workflow of cloning a repository and running standard package-manager commands. The impact—arbitrary code execution in development and CI/CD environments—creates a direct path to compromise of source code, secrets, and build artifacts. While not yet on CISA's KEV list, the vulnerability's ease of exploitation and potential for widespread impact warrant treatment as a critical priority.

Risk score, explained

The CVSS 3.1 score of 8.8 (HIGH severity) reflects: Attack Vector = Network (the malicious lockfile is distributed via repository clone), Attack Complexity = Low (no special conditions required), Privileges Required = None (attacker need not authenticate), User Interaction = Required (a developer must execute pnpm), Scope = Unchanged (impact is limited to the user's environment), and the Confidentiality, Integrity, and Availability impacts are all High (arbitrary code execution with full system access). The score appropriately captures the risk of supply-chain compromise through a commonly-used development tool, though real-world impact varies based on how widely pnpm is deployed within an organization and how frequently developers interact with untrusted repositories.

Frequently asked questions