pnpm: Project env lockfile can short-circuit package-manager resolution and execute lockfile-selected pnpm bytes

What happened?

<!-- maintainer-action:start --> ## Maintainer Action Plan This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the detailed exploit narrative below only if you want to replay the original path. - Advisory: `CAND-PNPM-063` / `GHSA-w466-c33r-3gjp` - Advisory URL: https://github.com/pnpm/pnpm/security/advisories/GHSA-w466-c33r-3gjp - Shared patch PR: https://github.com/pnpm/pnpm-ghsa-j2hc-m6cf-6jm8/pull/1 - Shared patch branch:

Key details

• pnpm stores package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml.
• Direct pnpm execution trusted an already resolved packageManagerDependencies entry when versions matched.
• A malicious repository could commit lockfile records that bypass fresh resolution and cause execution of attacker-selected bytes.
• The patch forces re-resolution of package-manager entries through trusted registries before installation and execution.
• switchCliVersion now calls resolvePackageManagerIntegrities with force: true and uses the returned refreshed lockfile.
• Impact allows arbitrary package-manager code execution with victim privileges in developer or CI environments.

Summarised by SecOraLens from GitHub Security Advisories. Always read the original source before acting. How SecOraLens verifies advisories.