If a package registry token leaked, revoke it, create a narrower replacement, list every release published since the leak, and look for versions you did not make. A token that can publish is a way to ship malware under your name, so treat the leak as a possible compromised release until shown otherwise.
Why registry tokens are special
A leaked cloud key exposes your cloud. A leaked publish token exposes everyone who installs your package. The right response checks both the token and what it may already have done.
Checklist
| Step | npm | PyPI |
|---|---|---|
| Revoke the token | Delete it with npm token commands or the website | Revoke it from your PyPI account |
| List recent releases | Compare version list and times with your records | Compare release history with your records |
| Look for odd versions | Anything you did not publish | Anything you did not upload |
| Check maintainers | Review owners with npm owner ls | Review project collaborators |
| Replace | Granular token, narrow scope, short expiry | Narrowest scope PyPI offers |
The npm docs say only granular tokens are supported now, legacy tokens were removed in November 2025, you set an expiration when you create a token, and tokens lose access automatically if the owner loses access to the package or organization. Choose the narrowest scope and the shortest expiry that works.
Steps
- Revoke the leaked token first. Do not wait.
- Compare the registry's release list with your own release records, for the time since the token was created, not only since you noticed the leak.
- If you find a release you did not make, treat it as a compromised package: report malware to the registry, publish a clean higher version and warn users. See the maintainer first 24 hours guide.
- Find how it leaked: committed file, CI log, shared document. Remove it there and check history, see leaked secret in git history.
- Replace with a scoped token, and prefer trusted publishing where your registry supports it.
- Review other tokens in the same place the leak came from.
Check use
Registry audit views vary. Where a registry does not show token use, rely on the release history and your own CI logs, and say what you could not see.
Reduce the next leak
Keep tokens out of source files and shared documents, scope each token to one project, and give each a short expiry. Where the registry supports trusted publishing from CI, prefer it over stored tokens, since there is then no long lived secret to leak. Run secret scanning on repositories and CI logs, and treat any hit as a reason to check the release list, not only to rotate.
Quick check
The token was only exposed for an hour, do I still need to check releases?
Yes. A publish takes seconds. Check the release list for the whole life of the token.
Is a read only token a concern?
Less so, but it can expose private packages. Revoke and replace it too.
Safeguard's SBOM and dependency scanning can help show which of your projects depend on your own published packages. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
