CVE-2026-55698
Before the patch, direct pnpm execution trusted an already resolved packageManagerDependencies entry when the committed env lockfile contained matching pnpm and @pnpm/exe versions.
Does this matter?
High impact if exploited, but EPSS currently rates exploitation as unlikely (0.30%). Schedule it in the normal patch cycle and watch for a rise in EPSS or a public exploit.
Description
pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can persist package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml. Before the patch, direct pnpm execution trusted an already resolved packageManagerDependencies entry when the committed env lockfile contained matching pnpm and @pnpm/exe versions. A malicious repository could therefore commit package-manager lockfile package records and snapshots that bypassed fresh package-manager resolution, then cause pnpm to install and execute bytes selected by that committed lockfile state during automatic version switching. This vulnerability is fixed in 10.34.2 and 11.5.3.
- CVSS 3.1
- 8.8 HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
- EPSS
- 0.30% probability · 22th percentile
- CISA KEV
- Not listed
- Weakness
- CWE-345, CWE-494, CWE-829
- Affected
- pnpm/pnpm
- Source
- security-advisories@github.com
References
- https://github.com/pnpm/pnpm/security/advisories/GHSA-w466-c33r-3gjpExploit, Vendor Advisory
- https://github.com/pnpm/pnpm/security/advisories/GHSA-w466-c33r-3gjpExploit, Vendor Advisory
Source: NVD record, EPSS from FIRST.org, KEV from CISA. Refreshed daily.