A phished or stolen maintainer account is a direct path to publishing malicious package versions. Reduce the risk by using FIDO based 2FA, avoiding long lived publish tokens, and moving builds to trusted publishing so no registry token has to be stored.
Why maintainer accounts are the target
Publishing rights are trust. Whoever controls the account can ship a new version that downstream projects pull in automatically. GitHub said it was notified on 14 September 2025 of the Shai-Hulud attack, described as a self-replicating worm that spread in the npm ecosystem through compromised maintainer accounts, and that it removed more than 500 compromised packages. GitHub's post does not say how those accounts were compromised, so this article makes no claim about it.
What GitHub said it would change
In a post dated 22 September 2025, GitHub described changes to npm authentication and publishing that it said would come in the near future, gradually, with no specific dates:
- Local publishing with required 2FA. Planned steps include removing the option to bypass 2FA for local publishing and deprecating TOTP in favor of FIDO based 2FA.
- Granular tokens with a seven day lifetime. Planned steps include deprecating classic tokens, shortening expiry for granular tokens that can publish, and disallowing tokens by default for publishing.
- Trusted publishing. GitHub says it removes the need to securely manage an API token in the build system. npm added it in July 2025, and eligible providers are planned to expand.
These were plans at the time of writing. Check the current npm documentation for what is live.
What maintainers can do now
- Use a security key or passkey for your registry account, not SMS or a code app where you have the choice. See which MFA to use.
- Remove old tokens. Replace long lived publish tokens with short lived, narrowly scoped ones.
- Prefer trusted publishing from CI so there is no token to steal from a repo secret or a laptop.
- Limit who can publish. Fewer owners means fewer accounts to phish.
- Watch for fake security alerts that ask you to authorize apps or log in via a link. See the OAuth example.
What consumers can do
You cannot control another maintainer's habits, but you can control how fast a bad release reaches you. Pin versions, use a lockfile, and review dependency updates before they merge. Safeguard's SBOM and dependency scanning can flag known compromised or vulnerable packages in your tree, and there is a free scan at https://gold.safeguard.sh/scan.
Why short lived credentials win
A long lived token is a standing invitation. If it leaks through a phished laptop, a repository secret or a log file, it works until someone notices. A token that expires in days limits the window, and a build that proves its identity at publish time leaves nothing to leak. This is the same principle behind any secrets hygiene: reduce how long a stolen credential stays useful. Review your own release process against it, including who can trigger a publish and from which branch.
Quick check
Does 2FA alone prevent account takeover?
It prevents many takeovers, but a relayed sign-in can defeat codes. FIDO based methods resist that.
Why prefer trusted publishing?
Because the build proves its identity to the registry, so you do not store a long lived token that could be stolen.
Sources
Last reviewed: 19 October 2026.
