pnpm, a JavaScript package manager, has a defect in versions prior to 10.34.0 and 11.4.0 that permits a package to be silently replaced when the integrity hash recorded in pnpm-lock.yaml no longer matches the tarball obtained from the registry. When an integrity mismatch is detected in non‑frozen mode, pnpm automatically performs a resolution repair, updates the lockfile with a new integrity value, installs the new content, and exits successfully, thereby bypassing the intended hard stop. This flaw enables a malicious party to substitute a trusted package with compromised code, compromising the supply chain integrity of the application that relies on pnpm. The weakness involves improper integrity enforcement (CWE-345) and improper handling of external data (CWE-494).

pnpm version 10.33.x and earlier as well as any 11.x release before 11.4.0 are vulnerable. Systems that use pnpm install in non‑frozen mode and rely on the lockfile integrity check are affected.

The vulnerability has a CVSS score of 6.8, indicating moderate severity. The EPSS score is less than 1%, and it is not listed in the CISA KEV catalog, suggesting no widespread exploitation has been reported. Based on the description, it is inferred that the attack vector requires an attacker who controls or compromises the package registry to deliver altered metadata and tarball content for a package name and version that is already locked. Because pnpm automatically updates the lockfile, the compromise would be stealthy unless detected through other monitoring mechanisms.