CVE-2026-50017

What it actually does

Prior to pnpm 10.34.0 and 11.4.0, pnpm can incorrectly associate a user-level, unscoped npm authentication token with a registry URL defined by a repository-local .npmrc file. If a developer or build process has an unscoped _authToken in the user npm configuration and then runs normal pnpm operations in a repository that sets registry= to another endpoint, pnpm may send that credential in an Authorization header to the repository-selected registry. The vulnerability does not require code execution by the attacker, but it does require a user or automation process to interact with a repository whose local configuration points to an attacker-controlled or untrusted registry.

Why it matters to the business

This flaw can leak npm authentication tokens to an unintended registry, potentially allowing attackers to read private packages, publish malicious package versions, tamper with software supply chains, or pivot into CI/CD workflows that rely on npm credentials. The risk is highest for organizations with developers or build systems that use long-lived npm tokens, broad-scoped tokens, or unscoped credentials in user-level npm configuration. Although it is not currently listed in CISA KEV and EPSS is low, token exposure can have outsized operational impact because a single leaked publishing token may affect many downstream applications and consumers.

How an attack unfolds

An attacker prepares or compromises a source repository and adds a repository-local .npmrc file that sets registry= to a registry they control or can observe. The repository does not need to include its own token-bearing auth configuration. A developer, CI job, or other automation with a user-level unscoped npm _authToken then runs a normal pnpm command such as install, metadata resolution, or dependency retrieval inside that repository. Vulnerable pnpm versions bind the existing user-origin unscoped credential to the registry chosen by the repository-local .npmrc and send it as an Authorization header. The attacker captures the token from registry or proxy logs and can then attempt to use it against the legitimate npm registry or any registry where the token is valid. Depending on token permissions, the attacker may access private packages, publish malicious updates, or perform other package-management actions.

How to fix it

Upgrade pnpm to a fixed release: 10.34.0 or later for the 10.x line, or 11.4.0 or later for the 11.x line. Remove unscoped npm authentication tokens from user-level configuration wherever possible and replace them with registry-scoped tokens, for example tokens tied to a specific //registry.example.com/:_authToken entry. Prefer short-lived, least-privilege automation tokens over long-lived developer tokens. Review repositories for unexpected .npmrc files that override registry=, especially in third-party, forked, or newly onboarded repositories. Revoke and rotate any npm tokens that may have been used with vulnerable pnpm versions in repositories containing untrusted or unexpected registry configuration. Where feasible, restrict CI/CD network egress so package-manager credentials cannot be sent to arbitrary registries.

How to confirm the fix worked

Confirm that all developer workstations, CI images, build containers, and package-management runners use pnpm 10.34.0 or later, or 11.4.0 or later. Run pnpm --version in relevant environments and verify that pinned package-manager versions in Dockerfiles, CI configuration, corepack settings, and lockfiles are updated. Inspect user and global npm configuration for unscoped _authToken entries and confirm tokens are scoped to intended registry hosts. Test with a controlled repository-local .npmrc that sets registry= to a non-production test endpoint and verify that fixed pnpm versions do not send unrelated user-level credentials to that endpoint. Review npm token inventory and registry audit logs to ensure potentially exposed tokens were rotated and that no unexpected package reads, publishes, or token use occurred after exposure.

Typical attack path

1. Identify developers, CI jobs, or open-source maintainers likely to use pnpm with npm authentication configured.
2. Create, fork, or compromise a repository and add a repository-local .npmrc that sets registry= to an attacker-controlled or observable registry URL.
3. Induce a target user or automation workflow to run pnpm install or another pnpm metadata/install operation in that repository.
4. Receive an HTTP request from vulnerable pnpm that includes the victim's unscoped npm token in an Authorization header.
5. Use the captured token to query package access, read private packages, publish package versions, or perform other npm registry actions permitted by the token.
6. Optionally maintain access by publishing malicious package versions or by reusing the token until it is revoked or expires.

How to detect it

Investigate whether developers or CI jobs using vulnerable pnpm versions processed repositories with repository-local .npmrc files that changed registry=. Key log sources include outbound proxy logs, DNS logs, firewall egress logs, CI job logs, package registry access logs, npm organization audit logs, endpoint shell history, and repository history for .npmrc changes. Look for pnpm traffic to registries outside the approved registry list, especially requests with Authorization headers or requests made shortly after cloning or building an unfamiliar repository. On attacker-controlled registries, the exposed credential would appear as an Authorization header, commonly a bearer token. In enterprise telemetry, correlate pnpm user agents, install commands, or CI dependency-resolution steps with outbound connections to unusual package registry domains. Also review npm audit events for unexpected package publish operations, private package reads, token use from unfamiliar IP addresses, or token activity soon after a build or developer command interacted with a repository containing a registry override. If suspicious activity is found, assume the token was exposed, revoke it, rotate dependent secrets, and review package integrity for unauthorized publications.

• .npmrc
• registry=
• _authToken=
• Authorization: Bearer
• Authorization: Basic
• User-Agent: pnpm/
• pnpm install
• pnpm add
• pnpm fetch
• pnpm update
• //registry.npmjs.org/:_authToken=

What your security team should do

• Inventory pnpm usage across developer endpoints, CI runners, build containers, and release pipelines; prioritize systems that handle npm publish or private package access tokens.
• Upgrade pnpm to 10.34.0 or later, or 11.4.0 or later, and update pinned versions in CI images, Dockerfiles, corepack packageManager fields, and bootstrap scripts.
• Search user, global, and CI npm configuration for unscoped _authToken entries and replace them with registry-scoped, least-privilege tokens.
• Rotate npm tokens that were present on systems using vulnerable pnpm versions, especially if those systems processed third-party repositories or repositories with local .npmrc registry overrides.
• Review repositories for unexpected .npmrc files containing registry= directives that point to non-approved registries.
• Add egress monitoring or allowlisting for package-manager traffic from CI/CD environments to prevent npm credentials from being sent to untrusted registry hosts.
• Review npm registry audit logs for unusual token use, package downloads, metadata requests, or package publishing activity following interaction with suspicious repositories.