pnpm EUVD-2026-39489

Requires three concrete conditions: (1) the install is run in NON-FROZEN mode - i.e., plain pnpm install WITHOUT --frozen-lockfile, so pnpm's resolution-repair path is allowed to run; (2) the attacker controls the content the registry returns for an already-locked (package name + version) pair - a compromised/hijacked registry, a malicious mirror, or MITM of a non-HTTPS registry - serving a tarball whose hash differs from the one in pnpm-lock.yaml; (3) the victim runs the install on a clean store/cache so the altered tarball is actually fetched. Limiting factors: it does NOT work when --frozen-lockfile (or CI frozen-by-default) is enforced, it requires user interaction (someone must run the install per UI:R), and it requires the attacker to already control registry responses rather than simply reaching the victim over the network - so it is not exploitable against a victim using a trusted, integrity-honored HTTPS registry.

Signals are mixed and should be read together rather than off the headline CVSS 8.1. The NVD vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N) scores network reach and no victim privileges, but it understates a critical precondition the description makes explicit: the attacker must already control what the registry serves (a compromised/hijacked registry, malicious mirror, or MITM of an HTTP registry) AND the victim must run a non-frozen pnpm install. That registry-control requirement is closer to AC:H than AC:L in practice. SSVC reinforces a measured priority: Exploitation=PoC (not active), Automatable=no, Technical Impact=partial - i.e., not a spray-and-pray automatable bug. EPSS 0.11% (1st percentile) and absence from CISA KEV agree it is not currently mass-exploited. Net: this is a meaningful supply-chain hardening fix and a real risk for anyone whose registry/mirror could be subverted, but it is a conditional, integrity-of-pipeline issue rather than a directly remotely-triggerable RCE against arbitrary internet hosts. Note conflict to verify: CVSS AC:L vs. description implying the attacker must first compromise registry content - treat real-world complexity as higher than the score suggests.

An attacker who has compromised an internal mirror, a self-hosted registry, or an HTTP registry path replaces the tarball and metadata for an already-pinned dependency (e.g., example-package@1.0.0) with malicious content carrying a new hash. A developer or CI job runs a normal pnpm install (non-frozen) on a clean store; pnpm flags the integrity mismatch but then 'repairs' the lockfile, installs the malicious v2 content, rewrites pnpm-lock.yaml to trust it, and exits 0. A working proof-of-concept reproduction is published in the advisory.