pnpm CVE-2026-55698

Exploitation requires that the victim run pnpm directly inside an attacker-controlled repository whose committed pnpm-lock.yaml has been crafted to persist package-manager bootstrap metadata (packageManagerDependencies) in its first YAML document, with the committed env lockfile containing matching pnpm and @pnpm/exe versions so that automatic package-manager version switching is triggered and fresh resolution is bypassed. The decisive limiting factor is required user interaction (UI:R): the developer must clone/open the malicious repo and invoke pnpm, so there is no purely remote, hands-off exploitation. Exploitation is further bounded to pnpm versions before 10.34.2 / 11.5.3 and to workflows that use direct pnpm execution with automatic version switching enabled; environments that pin pnpm explicitly and never auto-switch based on the repo lockfile are not exposed to this specific path.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 8.8) indicates a low-complexity, unauthenticated, network-reachable attack whose only significant constraint is required user interaction (UI:R) - a developer must run pnpm inside the malicious repository. This profile is typical and realistic for supply-chain/developer-tooling vulnerabilities where 'opening and building a cloned repo' is routine. No EPSS score, KEV listing, or SSVC decision data was provided, and no POC is referenced, so there is no public exploit identified at time of analysis; this lowers immediate mass-exploitation likelihood but does not reduce the technical severity, since the exploit primitive (committed lockfile state → arbitrary code execution) is conceptually simple and well-suited to targeted attacks via malicious or compromised repositories. The main signal tension to flag: the CVSS network vector plus high triple-impact looks alarming, but exploitation is fundamentally a social/supply-chain delivery problem (victim must clone and run pnpm on attacker-controlled content), so treat this as a high-priority patch for developer and CI environments rather than an internet-facing remote-exploit emergency.

An attacker publishes a tempting open-source repository (or submits a pull request) whose committed pnpm-lock.yaml carries crafted package-manager bootstrap metadata with matching pnpm and @pnpm/exe versions and attacker-chosen package records/snapshots. A developer clones the repo and runs a normal pnpm command, triggering automatic version switching; pnpm trusts the committed lockfile state, skips fresh resolution, and installs and executes the attacker-selected bytes on the developer's machine. No public exploit code is referenced, but the attack requires no authentication and only low complexity once the victim runs pnpm (UI:R).