Single maintainer account gates publishes to millions. One compromise ships to every downstream.
Package registries are the load-bearing infrastructure of every software stack, and their security model reduces to a single bet: that the person who owns the maintainer account is still the person.
When that bet loses, the next publish ships to millions of downstreams with the legitimate maintainer's signature. Nobody signed for the attacker's code. Everybody signed for the maintainer.
Modern software composition works by trust delegation. You trust npm, or PyPI, or Maven, or crates.io, to serve the package you asked for. npm trusts the maintainer account to publish what they intend to publish. The maintainer account trusts its owner (a person with a password, a phone, an email inbox) to be the only one issuing publish commands.
The chain has no compensating controls at the pointy end. An attacker who gets into the maintainer's session, via phishing, credential stuffing, a token leaked in a log, a supply-chain attack on the maintainer's own stack, or social-engineering a reset, gets the publish capability wholesale. npm does not know the attacker is not the maintainer. The maintainer's GitHub does not know. The CI pipeline that installs the package does not know. Every downstream package-lock pins to the version number and the registry-computed integrity hash, both of which the attacker's publish satisfied correctly. The integrity hash is the hash of the attacker's tarball, computed and attested by the registry, delivered to every consumer who installs that version.
The blast radius is the maintainer's download count. Popular libraries multiply that by transitive inclusion. A utility three levels deep in your dependency tree carries its maintainer's publish authority into your build with the same weight as a package you chose directly. You do not see the three-levels-deep maintainer in your dependency audit. Your build sees them every time it installs.
Axios, Sapphire Sleet, and 70 Million Weekly Installs. North Korean crew Sapphire Sleet reached an axios maintainer account and pushed a malicious version to a package with 70 million weekly downloads. The publish was signed. The integrity hash was valid. The version looked like a normal point release. Consumers on floating dependency ranges pulled it in on the next install. Detection came through community observation, not through the registry's own controls, because the registry's controls had nothing to flag.
Shai-Hulud: The First npm Worm. A maintainer-account compromise that propagated maintainer-account compromises. The malicious package harvested npm tokens from every developer environment it installed into, then used those tokens to publish infected versions of packages those developers maintained. One compromise became a network of compromises, one per developer who installed the first one. The worm's propagation speed was limited only by CI cadence.
xrpl.js: The Official Package Was the Threat. The xrpl.js maintainer account was compromised and used to publish a harvester that exfiltrated wallet seed phrases from anyone who installed the package. The takedown was hours behind the publish. In those hours, the package was installed into dev environments, CI runs, and test harnesses across every team using the XRP Ledger library. Each install that touched a wallet credential was a fresh theft.
Not every malicious package is maintainer-account-compromise. Typosquatting packages, packages published by bad-faith contributors to begin with, packages that earned trust for six months and then turned hostile, these are all supply-chain attacks, but they are not this pattern. Maintainer-account-compromise requires that a legitimate maintainer's legitimate account was used to publish illegitimate code. The account's legitimacy is exactly what makes the publish dangerous.
Not every stolen developer credential. An attacker who steals a developer's AWS keys and deploys malware to that developer's servers is credential theft. It becomes maintainer-account-compromise only when the stolen credentials ratify actions against the credential-holder's downstream dependents. A maintainer's account has downstream dependents by the million. A developer's AWS account usually does not.
Not registry-side compromise. If npm itself were breached and the registry started serving attacker content, that would be registry compromise. Maintainer-account-compromise works even when the registry is functioning exactly as designed. The registry correctly delivered the package the maintainer published. The problem is who the maintainer was at the moment of publish.
Know your transitive maintainer set. The first-party dependencies you chose are a tiny fraction of who has publish authority over your build. Tools that enumerate maintainers across your dependency tree exist; run them, treat the output as a list of people whose account compromise would be yours.
Pin by integrity hash, then watch for integrity-hash changes across versions. A maintainer-account compromise produces a new hash for a new version. Your build happily accepts it. The defense is cross-version comparison: does this new point release deviate from the prior release in a way the published changelog cannot explain? The answer requires effort the typical build pipeline does not spend.
Rate maintainers by blast radius, not by personal trust. Single-maintainer projects at high download count are structurally more dangerous than multi-maintainer projects at low count. This is not about the person, it is about the graph. Prefer dependencies with multiple publish-authorized maintainers and mandatory review on publish.
Lag your floating versions deliberately. If your lockfile pins to versions that are 72 hours old, most in-the-wild maintainer-account-compromise publishes get detected by the community and yanked before they reach you. The cost is 72 hours of lag on legitimate updates. The benefit is a wide class of attacks that expires before it reaches your pipeline.
Treat npm tokens, PyPI tokens, and crates.io tokens the way you would treat an AWS root key, because they are the same kind of authority. A leaked token in a shell history or a CI log is the start of a revocation-gap whose downstream is everyone who installs that maintainer's packages.
Trust Inversion. The parent pattern. Maintainer-account-compromise is trust-inversion at the package registry layer, where the inverted trust mechanism is the "this publish came from the maintainer" assumption. Every maintainer-account-compromise is a trust inversion. The reverse is not true, many trust-inversions happen at layers above or below the registry.
Revocation Gap. Maintainer-account-compromise operates through revocation gaps at two scales. The maintainer's stolen credentials remain valid from compromise to revocation at the registry. Each consumer's installation of the malicious package carries its own revocation gap for any credentials harvested during execution. The pattern is nested, and the nesting is why incidents keep escalating.
Self Propagating Supply Chain. The worm form of this pattern. When a maintainer-account-compromise produces code that compromises more maintainer accounts, the pattern becomes autocatalytic. Shai-Hulud is the exemplar. The distinction matters operationally: a one-off maintainer compromise is an incident. A self-propagating one is an outbreak.
The registry is not the attack surface. The maintainer's inbox is.