Skip to content

Back to the catalog

Socket: pnpm 11.10 Hardens Registry Authentication to Block Token Redirection
socket.devarticle

Socket: pnpm 11.10 Hardens Registry Authentication to Block Token Redirection

pnpm 11.10 adds a new _auth setting that binds registry credentials to their registry URL and reads them only from environment variables or global config, never from project files, closing a path where a malicious pnpm-workspace.yaml or .npmrc could redirect a registry token to an attacker-controlled host. The release also restricts pnpm deploy/pack-app output paths to inside the project, sources macOS code-signing tools from outside the repo, fixes a prototype-pollution issue tied to a dependency named __proto__, stops forwarding upstream registry credentials to install-accelerator servers, and adds an install path for the upcoming Rust-based pnpm v12. It continues pnpm's ongoing supply-chain hardening trend after disabling automatic lifecycle scripts (v10) and adding minimum release age / exotic subdependency blocking (v11).

TL;DR pnpm 11.10 adds an _auth setting that ties registry tokens to their host, blocking malicious repo files from redirecting credentials, plus several other supply-chain hardening fixes.
Open original ↗
Document

What it is

pnpm 11.10, a supply-chain hardening release. The headline change is a new _auth setting for registry credentials, plus the operational context that it is the sanctioned fix for a private-registry authentication regression pnpm introduced in June.

How it works

_auth stores registry credentials as one structured value keyed by registry URL, so the credential and the host it belongs to travel together. pnpm reads _auth only from its global config or a pnpm_config__auth environment variable — never from a project's .npmrc or pnpm-workspace.yaml. Because a repo-controlled file can no longer supply or repoint the credential, a tampered project file cannot redirect a valid token to an attacker host.

Preconditions / Affected

The token-redirection risk requires an attacker who can control files in a repository you run pnpm against. Separately — and this is the operational catch the summary omits — teams who were legitimately expanding environment variables inside .npmrc for private registries had that broken by pnpm's June change (which stopped expanding env vars in credentials read from project files). If your private-registry auth broke around June, this is why, and _auth is the replacement path.

What to do

  • Migrate private-registry credentials out of project .npmrc env-var expansion and into _auth, set via pnpm global config or the pnpm_config__auth environment variable (the recommended form for CI).
  • Note the additional hardening if you use these commands: pnpm deploy and pnpm pack-app now reject output paths outside the project, and pack-app no longer looks outside the project for macOS code-signing tools — so a repo can't substitute its own signer. A __proto__ prototype-pollution issue was fixed, upstream registry credentials are no longer forwarded to install-accelerator servers, and a new Node.js release signing key was added so runtime downloads keep verifying.

To try the Rust rewrite (pnpm v12, still pre-release), install from the next-12 tag:

pnpm self-update next-12

v12 ships as a native binary with no Node.js launcher, avoiding Node's per-command startup cost; from v12 on, updates settle on the standard pnpm package now pointing at the Rust executable.

Caveats

pnpm v12 is explicitly pre-release. The page gives no CVE identifiers, no exact June release version, and no verbatim _auth config syntax beyond naming the setting and the pnpm_config__auth variable — you will need pnpm's docs for the precise value format.

Technologies named here

Techniques named here

  • Token redirection via malicious/compromised project files
  • Prototype Pollution
  • Output path traversal in build/deploy commands
  • Signer substitution in pack-app

Related in Supply Chain