CVE-2026-55698

What it actually does

CVE-2026-55698 is a supply-chain execution flaw in pnpm’s automatic package-manager version switching logic. Prior to pnpm 10.34.2 and 11.5.3, pnpm could persist package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml and later trust already resolved packageManagerDependencies entries when the committed environment lockfile contained matching pnpm and @pnpm/exe versions. A malicious repository can commit crafted lockfile package records and snapshots so that, when a user or CI job runs pnpm with automatic version switching enabled, pnpm bypasses fresh package-manager resolution and installs/executes attacker-selected package-manager bytes from the committed lockfile state. The vulnerability requires user interaction in the form of running pnpm against a malicious or compromised repository, but no authentication to the victim environment is required by the attacker.

Why it matters to the business

Successful exploitation can compromise developer workstations or CI/CD runners that build or install dependencies from a malicious repository. Because package-manager execution happens early in the build/install workflow, an attacker may be able to steal source code, dependency tokens, npm credentials, CI secrets, signing keys, cloud credentials, or modify build outputs before release. This creates a material software supply-chain risk: compromise may propagate from a single repository checkout into build pipelines and downstream artifacts. The issue is high severity, but current public exploitation signals are low: it is not listed in CISA KEV, is not flagged as ransomware-used, and has a low EPSS score of 0.00265 as of the provided data.

How an attack unfolds

An attacker prepares or compromises a repository that uses pnpm and commits a crafted pnpm-lock.yaml containing package-manager bootstrap metadata and malicious package-manager dependency records/snapshots. The committed metadata is arranged so the repository appears to require matching pnpm and @pnpm/exe versions. When a developer, automation job, or CI runner clones the repository and directly runs pnpm, vulnerable pnpm versions may trust the committed packageManagerDependencies state rather than performing a clean package-manager resolution. During automatic version switching, pnpm then installs and executes the package-manager bytes selected by the attacker-controlled lockfile state. Once code execution occurs in the context of the developer shell or CI job, the attacker’s payload can read environment variables, access repository files, exfiltrate tokens, alter dependencies, modify generated artifacts, or establish further persistence depending on host and pipeline permissions.

How to fix it

Upgrade pnpm to a fixed version: 10.34.2 or later for the 10.x line, or 11.5.3 or later for the 11.x line. Ensure both developer workstations and CI/CD images use patched pnpm versions; updating only local machines is insufficient if build runners still use vulnerable versions. Regenerate or review lockfiles for repositories that may have accepted untrusted changes to pnpm-lock.yaml, especially changes affecting packageManagerDependencies, pnpm, @pnpm/exe, package-manager bootstrap metadata, or unusual package records/snapshots. Treat pnpm-lock.yaml changes from untrusted contributors as security-sensitive. Where immediate upgrade is not possible, avoid running pnpm directly on untrusted repositories, disable or tightly control automatic package-manager version switching where feasible, use isolated/ephemeral build containers with no long-lived secrets, and require code review for lockfile changes before CI execution with privileged credentials.

How to confirm the fix worked

Confirm the installed pnpm version is 10.34.2 or later, or 11.5.3 or later, by running `pnpm --version` in developer images, CI runners, container images, and build environments. Validate that repository workflows and CI jobs are not pinning older pnpm versions through Corepack, package-manager settings, custom install scripts, base images, or cached toolchains. Review recent commits for pnpm-lock.yaml changes that add or modify packageManagerDependencies, pnpm/@pnpm/exe entries, package-manager snapshots, or multiple YAML documents. Perform a clean dependency install using the patched pnpm version from a clean cache and verify no unexpected package-manager binary is fetched or executed. For high-risk repositories, regenerate pnpm-lock.yaml with a patched pnpm release and compare changes before accepting the updated lockfile.

Typical attack path

1. Create or compromise a source repository that will be opened or built by a target developer or CI system.
2. Commit a crafted pnpm-lock.yaml with package-manager bootstrap metadata in the first YAML document.
3. Include attacker-controlled package-manager lockfile records and snapshots that satisfy expected pnpm and @pnpm/exe version checks.
4. Persuade a victim or automated workflow to run pnpm in the repository, or wait for an existing CI pipeline to process the repository.
5. Vulnerable pnpm trusts the committed packageManagerDependencies state and skips fresh package-manager resolution.
6. pnpm automatic version switching installs and executes attacker-selected package-manager bytes.
7. The attacker’s code runs with the privileges and network access of the developer account or CI runner.
8. The payload steals secrets, modifies build outputs, tampers with dependencies, or performs additional actions in the software delivery environment.

How to detect it

Investigate whether vulnerable pnpm versions executed against untrusted or recently changed repositories. Primary sources include source-control history, pull request diffs, CI job logs, build runner shell history, endpoint process telemetry, package-manager/cache directories, and network egress logs. Look for pnpm-lock.yaml commits that modify the first YAML document, add packageManagerDependencies, reference pnpm or @pnpm/exe as lockfile-resolved packages, or introduce unusual tarball URLs/integrity values for package-manager packages. In CI logs, look for automatic package-manager switching, unexpected downloads of pnpm or @pnpm/exe, installs from nonstandard registries, or lifecycle activity immediately after pnpm startup. On endpoints and runners, look for pnpm/node processes spawning shells, curl, wget, PowerShell, Python, or other interpreters during install/bootstrap. Review environment-variable access and outbound connections after the first pnpm execution in suspect repositories. If a suspicious lockfile was used, preserve the repository state, pnpm cache, CI logs, runner filesystem, and process/network telemetry before cleanup.

• packageManagerDependencies
• @pnpm/exe
• pnpm-lock.yaml
• lockfileVersion:
• pnpm --version
• corepack pnpm
• Preparing pnpm@
• PNPM_HOME
• node_modules/.pnpm/@pnpm+exe
• node_modules/.pnpm/pnpm
• ~/.local/share/pnpm
• ~/.cache/pnpm
• ~/.pnpm-store
• pnpm store path
• pnpm install
• pnpm fetch
• pnpm/action-setup

What your security team should do

• Patch pnpm across all CI/CD runners, developer base images, build containers, and workstation provisioning scripts to 10.34.2+ or 11.5.3+ as the top priority.
• Inventory repositories and pipelines that use pnpm and identify any that run installs automatically on pull requests, forks, or untrusted branches.
• Block or require security review for pull requests that modify pnpm-lock.yaml, especially sections involving packageManagerDependencies, pnpm, @pnpm/exe, package-manager bootstrap metadata, or snapshots.
• Run CI jobs for untrusted code in isolated ephemeral environments without production credentials, publishing tokens, signing keys, or broad cloud permissions.
• Search recent repository history and CI logs for suspicious lockfile changes followed by unusual network activity, secret access, or unexpected package-manager downloads.
• Clear pnpm/Corepack/tool caches on CI runners after patching to prevent reuse of previously fetched untrusted package-manager artifacts.
• Add dependency workflow guardrails: least-privilege CI tokens, read-only pull-request builds, egress monitoring, artifact integrity checks, and mandatory review for lockfiles.
• Because the CVE is not currently in KEV and EPSS is low, prioritize by exposure: internet-facing CI for external contributions and repositories handling release artifacts should be remediated first.