CVE-2026-50573

While it is unclear whether this should be classified as a vulnerability, it is being reported through this channel because the current behavior may represent an unsafe default. ## Summary `pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in `pnpm-lock.yaml`. When a package is already locked with an `integrity` value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain `pnpm install` then performs a resolution repair, accepts the registry's new integrity, updates the lockfile, installs the new content, and exits successfully. This means the lockfile integrity check does not act as a hard stop by default. ## Reproduction Scenario 1. Run a local npm-compatible registry. 2. Publish or serve `[email protected]` with tarball content `v1`. 3. Install it with pnpm: ```bash pnpm add [email protected] --registry=http://127.0.0.1:48741 ``` 4. Confirm `pnpm-lock.yaml` contains the `v1` integrity: ```yaml packages: [email protected]: resolution: integrity: sha512-...v1... ``` 5. Change the registry metadata and tarball for the same `[email protected]` to content `v2`. 6. On a clean store/cache, run: ```bash pnpm install --registry=http://127.0.0.1:48741 ``` ## Observed Behavior pnpm detects the checksum mismatch: ```text WARN Got unexpected checksum for "http://127.0.0.1:48741/example-package/-/example-package-1.0.0.tgz". Wanted "sha512-...v1..." Got "sha512-...v2...". ERR_PNPM_TARBALL_INTEGRITY The lockfile is broken! Resolution step will be performed to fix it. ``` However, the install still succeeds: ```text INSTALL_RC=0 INSTALLED=v2-replaced ``` The lockfile is then rewritten to trust the new remote integrity: ```yaml packages: [email protected]: resolution: integrity: sha512-...v2... ``` ## Ex