pnpm CVE-2026-101043

Exploitation requires: (1) the victim runs an affected pnpm version (>=11.0.0,<11.11.0 or >=10.7.0,<10.34.5 - the flaw was introduced in 10.7.0 with env-var expansion in setting names/values); (2) the victim clones/opens a repository whose attacker-controlled pnpm-workspace.yaml defines httpProxy, httpsProxy, or noProxy containing ${VAR} placeholders; (3) the victim runs a pnpm command such as pnpm install; and (4) the target environment actually holds secrets (e.g. NPM_TOKEN, GITHUB_TOKEN) in process environment variables. No pre-existing access to the victim's store, global config, lockfile, node_modules, or environment is needed, and no lifecycle script execution is required since exfiltration happens during config loading. The key limiting factor is user interaction (UI:P/UI:R): a victim must voluntarily clone the repo and invoke pnpm in a secret-bearing context - it is not remotely triggerable against a server and not automatable at scale.

This is a genuine, non-hypothetical priority despite the absence of KEV/EPSS signals. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N, base 8.3) is internally consistent with the description: network vector, low complexity, no privileges, but passive user interaction (the victim must clone the repo and run a pnpm command). The high confidentiality impact (VC:H) plus subsequent-system scope change (SC:H) correctly captures that repository-controlled input causes the victim's process-environment secrets (NPM_TOKEN, GITHUB_TOKEN) to be exfiltrated to an attacker host - a clean CWE-201 (sensitive information sent to unauthorized actor) rather than an integrity/availability issue, so VI/VA/SI/SA:N is appropriate. No EPSS score, no KEV listing, and no standalone exploit flag were provided; however the GHSA advisory itself embeds a working proof-of-concept pnpm-workspace.yaml, so publicly available exploit code exists. The realistic weighting is high: this is a supply-chain trust-boundary bypass (author a manifest → read a victim's secrets) that fires during config loading BEFORE any lifecycle script, defeating script-sandboxing mitigations, and it triggers on the extremely common pnpm install action. The main risk-limiter is UI:P/UI:R - it is not wormable/automatable against servers; it requires a victim to clone and run pnpm in a secret-bearing environment (developer workstation or CI).

An attacker publishes a public repo, fork, or supply-chain pull request whose pnpm-workspace.yaml sets httpProxy to a host embedding ${NPM_TOKEN} or ${GITHUB_TOKEN} in its hostname or userinfo. A developer or CI job clones the repo and runs pnpm install; during config loading pnpm expands the environment placeholder and routes install traffic - and the corresponding DNS lookups - through the attacker-controlled proxy, delivering the secret. A copy-paste proof-of-concept manifest is published in the GHSA advisory.