CVE-2026-55697

What it actually does

This flaw allows a repository-controlled pnpm workspace configuration to cause unintended code execution during pnpm command startup. In affected pnpm versions before 10.34.2 and 11.5.3, entries in pnpm-workspace.yaml configDependencies could be processed before normal command dispatch. If a repository declared pacquet or @pnpm/pacquet as a config dependency, pnpm incorrectly treated that as an install-engine opt-in, resolved a platform-specific @pacquet/<platform>-<arch>/pacquet binary under node_modules/.pnpm-config/<packageName>, and spawned that binary as the current developer or CI user. The result is arbitrary code execution in the context of the user or automation account running pnpm.

Why it matters to the business

A malicious or compromised source repository can execute code on developer workstations or CI runners when pnpm is run, potentially stealing source code, package registry tokens, cloud credentials, signing keys, or CI secrets. This can also enable tampering with builds and downstream software releases. The issue is not currently listed in CISA KEV, has no reported ransomware association, and has low EPSS at 0.00174, but the operational risk is meaningful for organizations that routinely run pnpm against third-party repositories, pull requests, forks, templates, or newly acquired codebases.

How an attack unfolds

An attacker first needs a way to influence a repository that a victim will run pnpm against, such as publishing a malicious template, submitting a pull request, compromising an existing project, or social-engineering a developer to clone and install a repository. The attacker adds or modifies pnpm-workspace.yaml so that configDependencies references pacquet or @pnpm/pacquet. In vulnerable pnpm versions, this repository-controlled declaration is processed before normal command dispatch and is interpreted as enabling the pacquet install engine. During pnpm execution, pnpm resolves the platform-specific pacquet package for the victim system and spawns the pacquet binary from node_modules/.pnpm-config. Any malicious code packaged in or reached through that binary executes with the privileges, environment variables, filesystem access, and network access of the developer shell or CI job.

How to fix it

Upgrade pnpm to a fixed release: 10.34.2 or later for the 10.x line, or 11.5.3 or later for the 11.x line. Update developer workstations, CI images, build containers, base images, and any Corepack-managed package manager definitions so they resolve only to fixed pnpm versions. Where possible, pin the package manager version in packageManager metadata and enforce it in CI. Review repositories for unexpected pnpm-workspace.yaml configDependencies entries, especially references to pacquet or @pnpm/pacquet. Do not run pnpm from untrusted repositories or pull requests with access to sensitive secrets. Isolate CI execution for external contributions, use least-privilege build tokens, restrict network egress where feasible, and rotate secrets if suspicious pacquet execution is found.

How to confirm the fix worked

Confirm that all interactive and automated pnpm executions use pnpm 10.34.2 or later, or 11.5.3 or later, by checking pnpm --version in developer environments, CI jobs, containers, and base images. Verify Corepack or packageManager pins do not install a vulnerable pnpm version. Scan repositories for pnpm-workspace.yaml files containing configDependencies entries that reference pacquet or @pnpm/pacquet. Re-run representative builds with process logging enabled and confirm pnpm does not spawn pacquet binaries from node_modules/.pnpm-config. For CI, validate that pull-request and fork builds cannot access production secrets or privileged publishing credentials.

Typical attack path

1. Attacker gains influence over a repository, pull request, fork, starter template, or dependency-development workflow that a victim will run pnpm against.
2. Attacker adds a pnpm-workspace.yaml configDependencies entry referencing pacquet or @pnpm/pacquet.
3. Victim runs an affected pnpm version before 10.34.2 or before 11.5.3 in that repository, commonly through pnpm install or a CI build step.
4. pnpm processes the repository-controlled config dependency before command dispatch and treats it as a pacquet install-engine opt-in.
5. pnpm resolves a platform-specific @pacquet/<platform>-<arch>/pacquet package under node_modules/.pnpm-config/<packageName>.
6. pnpm spawns the resolved pacquet binary as the current developer or CI user.
7. Attacker-controlled code harvests secrets, modifies source or build output, establishes persistence, or pivots using the privileges available to that user or CI runner.

How to detect it

To determine whether this was already exploited, review source-control history, CI logs, endpoint telemetry, and process execution data around pnpm install or build activity. Search repositories and pull requests for pnpm-workspace.yaml files with configDependencies entries referencing pacquet or @pnpm/pacquet. In CI logs, look for pnpm runs that created or used node_modules/.pnpm-config and downloaded or executed @pacquet/<platform>-<arch>/pacquet packages. In EDR, shell history, auditd, Sysmon, or process accounting, look for process trees where pnpm, node, npm, npx, corepack, or a CI runner spawned a pacquet executable from node_modules/.pnpm-config. Investigate any subsequent outbound network connections, credential-file access, package publishing, git modifications, or unexpected child processes from that pacquet process. On developer workstations and CI runners, inspect workspace directories for node_modules/.pnpm-config artifacts and correlate file creation times with pnpm execution times. Because the exact payload is attacker-controlled, absence of a universal malware hash does not rule out exploitation.

• configDependencies:
• pacquet:
• @pnpm/pacquet
• node_modules/.pnpm-config/
• node_modules/.pnpm-config/pacquet
• node_modules/.pnpm-config/@pnpm/pacquet
• @pacquet/linux-x64/pacquet
• @pacquet/linux-arm64/pacquet
• @pacquet/darwin-x64/pacquet
• @pacquet/darwin-arm64/pacquet
• @pacquet/win32-x64/pacquet
• @pacquet/win32-arm64/pacquet
• /node_modules/.pnpm-config/
• pnpm-workspace.yaml

What your security team should do

• Immediately inventory pnpm usage across CI images, developer tooling, build containers, and repositories.
• Prioritize upgrading pnpm to 10.34.2+ or 11.5.3+ everywhere it is executed.
• Search source repositories and recent pull requests for pnpm-workspace.yaml configDependencies entries referencing pacquet or @pnpm/pacquet.
• Hunt endpoint and CI telemetry for pnpm or node processes spawning pacquet binaries from node_modules/.pnpm-config.
• Treat any confirmed unexpected pacquet execution as potential code execution and investigate for credential theft, source modification, and build tampering.
• Rotate package registry tokens, CI secrets, signing keys, and cloud credentials exposed to affected builds if exploitation is suspected.
• Harden CI for untrusted code by disabling privileged secrets on forked pull requests, isolating runners, and limiting network egress.
• Add policy checks to block risky pnpm-workspace.yaml configDependencies changes unless explicitly reviewed.