CVE-2026-101043 in pnpm
Summary
by MITRE • 09/27/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in pnpm versions prior to 11.11.0 for the v11 branch and prior to 10.34.5 for the v10 branch constitutes a critical configuration injection flaw rooted in improper handling of environment variable expansion within workspace configurations. Specifically, the issue affects how pnpm processes the httpProxy, httpsProxy, and noProxy settings found in the project-level pnpm-workspace.yaml file. When a developer clones a malicious repository containing this crafted manifest and executes standard package management commands such as pnpm install, the tool inadvertently expands environment variable placeholders formatted as ${VAR} within these proxy configuration fields. This behavior is inconsistent with how other sensitive configuration keys like registry or namedRegistries are handled, which correctly suppress placeholder expansion for untrusted manifests to prevent similar attacks. The omission of proxy settings from this protective key set creates a direct vector for information disclosure and traffic manipulation.
From an operational perspective, the impact of this vulnerability allows an attacker who controls the source repository's pnpm-workspace.yaml file to exfiltrate sensitive environment secrets stored on the victim machine. By embedding specific variable references such as NPM_TOKEN or GITHUB_TOKEN into the proxy hostname or userinfo fields, the attacker forces pnpm to resolve these variables during the configuration loading phase. This process occurs before any lifecycle scripts are executed, meaning the exposure happens at a very early stage of the installation pipeline. The resolved values containing secrets are then embedded into HTTP request headers destined for an attacker-controlled proxy server. Consequently, not only is the traffic routed through the malicious infrastructure, but DNS lookups associated with these requests may also be intercepted or manipulated, further compromising network integrity and confidentiality.
This vulnerability aligns closely with CWE-78 Improper Neutralization of Special Elements used in an OS Command known as OS Command Injection, specifically manifesting here as configuration injection leading to data exfiltration. It is also categorized under CWE-200 Exposure of Sensitive Information to an Unauthorized Actor due to the leakage of authentication tokens and credentials via network requests. In terms of adversary tactics, this exploit maps directly to ATT&CK technique T1537.001 Deceptive Client Config Files using Workspace Configuration files. The attacker leverages a trusted configuration file format to trick the build tool into performing actions that facilitate data theft without requiring user interaction beyond cloning and installing packages.
Mitigation for this vulnerability requires immediate upgrading of pnpm to version 11.11.0 or later, which includes fixes ensuring that proxy settings are treated with the same security rigor as registry configurations when processing untrusted manifests. Organizations relying on these older versions should implement strict controls over who can modify repository configuration files and consider using isolated environments for installing packages from untrusted sources until upgrades are applied. Additionally, developers should audit their CI/CD pipelines to ensure that pnpm installations do not inadvertently expose internal secrets through network logs or proxy configurations when pulling dependencies from external repositories.