Leaked npm access token — supply-chain attack risk

An npm token grants publish access to every package the owner can publish. Leakage of a publisher's token is the classic supply-chain attack vector — the attacker publishes a malicious version of a popular package.

The next 60 seconds matter

The attacker publishes a poisoned patch version of one of the user's packages. Every downstream consumer installing the package on npm install pulls the poisoned code. This is how dozens of real supply-chain attacks have started.

  • Publish a poisoned version of every owned package
  • Access download statistics + dependent lists
  • Create new packages under the owned scope

Rotation playbook

  1. npmjs.com/settings/{user}/tokens → Revoke leaked token
  2. Review recent package publishes for any you did not authorize
  3. If a poisoned version was published: deprecate it immediately + publish a patch
  4. Notify GitHub / npm abuse + all dependents via GitHub Security Advisories

Prevent the next one

  • Use automation tokens (scope: publish) rather than long-lived personal tokens
  • Enable 2FA for publish on every package
  • Use npm's granular access tokens with per-package restrictions
  • Consider provenance attestations via Sigstore on every publish
Pattern we scan for
npm_{36 chars}