A malicious repository can commit a pnpm-lock.yaml that contains pre-resolved dependencies for pnpm and @pnpm/exe. When pnpm later performs an automatic version switch, it trusts these pre-resolved entries and installs the associated package‑manager bytes without re‑resolving them. This enables an attacker to execute arbitrary code contained in the lockfile‑selected package‑manager implementation, effectively granting code execution privileges in environments where pnpm runs the install. The flaw arises from an improper trust boundary between the lockfile metadata and the package‑manager bootstrap process, leading to a critical code‑execution path within the dependency resolution workflow.

The vulnerability affects the pnpm package manager prior to version 10.34.2 and prior to version 11.5.3. Any project that uses a pnpm‑generated lockfile and allows automatic version switching is susceptible. The affected product is the pnpm command‑line tool from the pnpm team, which manages JavaScript package installations.

The CVSS score of 8.8 places this issue in the high‑severity category. No EPSS data is currently available, and the vulnerability is not listed in the CISA KEV catalog. The likely attack vector is local or remote (e.g., CI pipelines or developers pulling from a malicious repository) where the attacker can prepare a lockfile that bypasses the fresh package‑manager resolution. Once executed, the attacker could run arbitrary code with the privileges of the user running pnpm. Because the flaw requires only a crafted lockfile and no additional credentials, the potential for exploitation is significant for projects that repeatedly install dependencies from untrusted sources.