Attackers go after maintainers because one publishing account reaches every project that installs the package. Compromising a person is cheaper than compromising many codebases. Common routes are phishing, reused passwords, stolen tokens and pressure on an overworked volunteer, so account controls matter more than code review here.
What a maintainer takeover is
A maintainer takeover is when someone other than the legitimate owner gains the ability to publish or approve releases for a package. The code in the repository may look untouched. The malicious change may exist only in the published artifact, or arrive as a small commit that nobody questions.
Routes into a maintainer account
| Route | How it works | Main control |
|---|---|---|
| Phishing | A fake login page captures a password and code | Security key or passkey |
| Password reuse | A password leaked elsewhere works here | Unique passwords, two-factor authentication |
| Stolen token | A token in a log, file or laptop is replayed | Short-lived or narrowly scoped tokens |
| Account recovery | An old email or phone is used to reset access | Review recovery options regularly |
| Social pressure | A new helper earns trust, then gains rights | Two-person review, access reviews |
None of these needs a software flaw. They are account problems.
Why the damage spreads
Package managers resolve versions automatically. A malicious new version published under a trusted name can be installed by anyone whose range allows it. The consumer never sees a pull request, an approval or a name they do not recognise.
The npm documentation says that publishing requires either two-factor authentication on the account or a granular access token with the bypass option enabled, and describes how granular tokens can be limited by package, scope and expiry. Those settings exist because stolen tokens are a known way to publish as someone else.
What maintainers can do
- Enable two-factor authentication using a security key or passkey where the registry supports it. GitHub's documentation lists security keys and passkeys among its options.
- Keep tokens narrow: one package or scope, an expiry date, and no bypass setting unless a job truly needs it.
- Prefer trusted publishing from CI, which exchanges short-lived identity tokens instead of storing a long-lived one.
- Require review on release branches, so one stolen account cannot both change and ship code.
- Remove access when someone leaves the project, and review the list each quarter.
What consumers can do
You cannot fix a maintainer's account, but you can limit your exposure. Commit lockfiles, review dependency changes in pull requests, and consider a short waiting period for brand new versions. Our guide to dependency cooldown periods covers the trade-offs.
Where Safeguard fits
Safeguard's dependency scanning and monitoring can flag when a package you use changes in ways that deserve review, and policies can gate a pull request that adds a risky dependency. It does not replace account security on the publisher side.
Quick check
Does two-factor authentication stop a takeover?
It stops many of them, especially with a security key or passkey. A stolen token that bypasses two-factor authentication, or a coerced maintainer, can still get through.
Is a popular package safer because many people review it?
Not automatically. Popularity raises the reward for an attacker. Look at how releases are made and who can publish.
Sources
- npm Docs: About two-factor authentication
- npm Docs: About access tokens
- GitHub Docs: About two-factor authentication
Last reviewed: 19 October 2026.
