VulnerabilityPublished 13 Aug 2026Updated 26 Oct 2026

CVE-2026-50017: Pnpm@10 · pnpm binds unscoped user-level npm auth credentials to a repository-selected registry

Affects pnpm@10Source GCVE Database

Not known to be exploited · CVSS 6.9 Medium : upgrade to 10.34.0 when convenient.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 4.0 base score

6.9Medium

How severe the flaw is on the 0–10 CVSS scale.

EPSS: 0.4% chance of exploitation in 30 days – higher than 37% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in 10.34.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Attack Vector: Network
Attack Complexity: Low
Attack Requirements: None
Privileges Required: None
User Interaction: Active
Vulnerable system confidentiality: High
Vulnerable system integrity: None
Vulnerable system availability: None
Subsequent system confidentiality: None
Subsequent system integrity: None
Subsequent system availability: None

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: Low: The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Attack Requirements: None: The successful attack does not depend on the deployment and execution conditions of the vulnerable system. The attacker can expect to be able to reach the vulnerability and execute the exploit under all or most instances of the vulnerability.
Privileges Required: None: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction: Active: Successful exploitation of this vulnerability requires a targeted user to perform specific, conscious interactions with the vulnerable system and the attacker’s payload, or the user’s interactions would actively subvert protection mechanisms which would lead to exploitation of the vulnerability.
Vulnerable system confidentiality: High: There is a total loss of confidentiality, resulting in all information within the Vulnerable System being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.
Vulnerable system integrity: None: There is no loss of integrity within the Vulnerable System.
Vulnerable system availability: None: There is no impact to availability within the Vulnerable System.
Subsequent system confidentiality: None: There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System.
Subsequent system integrity: None: There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System.
Subsequent system availability: None: There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.

Definitions: FIRST CVSS v4.0 specification.

Exploitation evidence

Disclosed: evidence found.
CVE published 13 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade pnpm@10 to 10.34.0.

Affected software

Product	Affected	Fixed in
Homebrewpnpm@10`pkg:brew/pnpm%4010`Other threats	Affected >=10.33.2 <10.34.0	Fixed in 10.34.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

## Summary pnpm can send user-level unscoped npm authentication credentials to a registry chosen by a repository-local `.npmrc` file. In the reproduced case, the user's npm config contains a default registry and an unscoped `_authToken`. The repository does not provide a token-bearing auth line. It only sets `registry=` to a different registry URL. During normal pnpm metadata/install workflows, pnpm binds the user-origin unscoped credential to the repository-selected registry and sends it as an `Authorization` header. This was reproduced with fake credentials and loopback registries only. No third-party registry or real token was used. ## Affected Behavior Observed Observed affected: - pnpm `10.33.2`: `pnpm install --ignore-scripts` sends the user-level unscoped `_authToken` to the repository-selected registry. - pnpm `11.1.3`: `pnpm install --ignore-scripts` sends the user-level unscoped `_authToken` to the repository-selected registry. - pnpm `11.2.1` (`next-11` dist tag at testing time): `pnpm install --ignore-scripts` sends the user-level unscoped `_authToken` to the repository-selected registry. - pnpm `11.1.3`: `pnpm view` also sends user-level unscoped `_authToken`, `_auth`, and `username` / `_password` credentials to the repository-selected registry in the local loopback replay. Control: - npm `10.9.7` rejects the same unscoped user `_authToken` configuration with `ERR_INVALID_AUTH` and does not send an `Authorization` header to the repository-selected registry. - URL-scoped registry token controls held in the local loopback replay: tokens scoped to the trusted registry URL were not sent to the attacker registry. ## Threat Model Victim: - developer or CI job with user-level npm registry credentials configured; - runs `pnpm install`, `pnpm view`, or an equivalent pnpm metadata/restore command in a repository. Attacker: - controls repository-local package manager configuration, such as `.npmrc`; - can set `registry=` to a registry endpoint they control; - does not need to provide a token-bearing auth line for the strong case. Boundary: Credentials from a higher-trust user configuration should not be rebound to a lower-trust repository-selected registry unless the credential is explicitly scoped to that registry. ## Minimal Reproduction The reproducer below starts two loopback HTTP registries: - a trusted registry URL used in the isolated user `.npmrc`; - an attacker registry URL used in the repository-local `.npmrc`. The isolated user `.npmrc` contains: ```ini registry=<trusted-loopback-registry> _authToken=PR166_FAKE_REGISTRY_TOKEN ``` The repository-local `.npmrc` contains: ```ini registry=<attacker-loopback-registry> ``` The repository `package.json` depends on a toy package served by the loopback registry. The script then runs: ```text pnpm install --ignore-scripts npm install --ignore-scripts ``` ## Expected Safe Behavior pnpm should not send the user-level unscoped `_authToken` to the repository-selected registry. A safe behavior would be to reject or ignore the unscoped credential in this lower-trust registry-rebinding situation and require the credential to be URL-scoped to the selected registry. ## Observed Behavior pnpm `10.33.2`, pnpm `11.1.3`, and pnpm `11.2.1` send: ```http Authorization: Bearer PR166_FAKE_REGISTRY_TOKEN ``` to the attacker loopback registry during install. npm `10.9.7` rejects the same config and sends no `Authorization` header. ## Security Impact This can disclose npm registry credentials from user-level configuration to a registry endpoint selected by an untrusted repository. The leak occurs before package lifecycle scripts run and does not depend on package code execution. ## Non-Claims This report does not claim: - remote code execution; - registry account compromise by itself; - leakage of URL-scoped tokens for a different registry; - npm CLI impact; - impact from a repository explicitly committing its own token-bearing auth line. ## Source-Level Notes In pnpm's config/auth-header flow, unscoped/default credentials are parsed from the merged auth config and stored as default credentials. The auth-header logic then maps those default credentials to the effective default registry. Because repository-local `.npmrc` can change the effective default registry, higher-trust default credentials can be applied to a lower-trust registry choice. ## Suggested Fix Direction The conservative fix direction is to reject or contain unscoped/default auth credentials when a lower-trust workspace/repository config changes the default registry. A compatibility-preserving fix could track the source layer of both the default registry and the default credentials, then only bind default credentials to a registry selected by the same or higher-trust source. A stricter npm-compatible fix would reject unscoped auth and require URL-scoped credentials. This needs maintainer semantic review and compatibility control because some legacy workflows may inte

References

Community reviews

Loading reviews…