Maintainer Account Takeover Attacks: Hijacking Trust in Open Source

A maintainer account takeover is a supply-chain attack in which an adversary gains control of a legitimate package maintainer's registry account and uses it to publish malicious versions of packages the maintainer owns. It is one of the most damaging attacks in the ecosystem precisely because the malicious release carries a valid pedigree: it is signed and published by the real account, it inherits the package's existing reputation and download volume, and it flows into every project that trusts that dependency. There is no typo for a developer to notice and no unfamiliar name to raise suspicion. When the account behind a package with millions of weekly downloads falls, the attacker inherits that reach instantly, which is why account takeover consistently produces the widest-blast-radius incidents in npm and PyPI history.

How maintainer account takeover works

Attackers get into maintainer accounts through a handful of well-worn routes. Phishing is the most productive: a convincing email that appears to come from the registry, directing the maintainer to a lookalike domain that harvests their username, password, and a live one-time code. Credential reuse is a close second, where a password exposed in an unrelated breach still works on the registry because the maintainer never changed it and had no second factor. Other routes include stealing publish tokens from a .npmrc file, a CI log, or a compromised laptop, and, over a longer horizon, social-engineering a handoff of maintainer rights.

Once inside, the attack is fast and quiet. The adversary publishes a new version, often a patch-level bump that looks routine, containing a payload in an install script or an exported function:

{
  "name": "popular-lib",
  "version": "3.4.1",
  "scripts": {
    "postinstall": "node ./.cache/setup.js"
  }
}

Because the version is legitimate in every mechanical sense, it propagates through auto-upgrades and fresh installs within minutes. Many campaigns keep the malicious release live for only a short window before deleting it, betting that enough CI systems and developers pull it during that window to make the attack worthwhile.

Real-world account takeover incidents

The eslint-scope incident of July 12, 2018 is an early, clarifying example. An ESLint maintainer had reused their npm password on other sites and had no two-factor authentication enabled. An attacker used those credentials to publish eslint-scope@3.7.2, which downloaded and ran code from Pastebin that exfiltrated the contents of the victim's .npmrc file — precisely the tokens needed to compromise still more accounts. npm responded by revoking all tokens issued before a cutoff time, a purge affecting thousands of accounts.

In October 2021, ua-parser-js, a library with millions of weekly downloads, was compromised the same way: the maintainer's account was hijacked and malicious versions were published that dropped a cryptocurrency miner and a password-stealing trojan through install scripts. The scale of the download base made this a global event within hours.

The pattern remains devastatingly effective. On September 8, 2025, the maintainer behind chalk, debug, and roughly eighteen other utilities — collectively over two billion downloads per week — was phished through a fake two-factor-reset email sent from the lookalike domain npmjs.help, registered just three days earlier. The attacker captured the credentials and a live one-time code, took over the account, and published malicious versions that hooked browser wallet and network APIs to reroute cryptocurrency transactions to attacker addresses. The malicious releases were live for roughly two hours before clean versions replaced them, but that window still reached an enormous number of installs.

How to detect and defend against account takeover

For maintainers, the controls are foundational account hygiene:

• Enforce phishing-resistant MFA. Hardware security keys or passkeys defeat the credential-plus-one-time-code phishing that took down the chalk and debug accounts.
• Use short-lived, scoped publish tokens. Prefer OIDC-based trusted publishing over long-lived tokens stored in .npmrc or CI, so a stolen secret expires quickly and grants little.
• Never reuse passwords. The eslint-scope compromise came down to a reused password with no second factor.

For consumers of packages, the defense assumes any maintainer can be compromised:

• Pin exact versions and adopt an update-delay window. Do not auto-adopt brand-new releases; a short cooling-off period lets a takeover be caught and the release yanked first.
• Alert on maintainer and behavior changes. A new publisher, a new install script, or new network activity between versions of a trusted package is a high-signal warning.
• Verify provenance where available. Build provenance attestations tie an artifact to its source repository and CI, which a hastily published malicious version often lacks.

How Safeguard helps

Account takeover is fundamentally a trust problem: the credentials are valid, so identity checks pass. Safeguard defends the consuming side by treating every new release as suspect until its behavior is verified. Griffin AI compares each version against the last and flags exactly the signals these attacks produce — a new or unexpected publisher, an added install script, obfuscated code, and new outbound network or wallet-API calls — so a routine-looking patch bump that suddenly exfiltrates environment variables is caught before it merges. Safeguard's continuously ingested SBOM means you know within minutes which projects pulled a compromised version, turning "are we exposed?" from a frantic manual audit into an instant query. Reachability-aware software composition analysis prioritizes the cases where the compromised code actually executes, and automated fix pull requests roll you back to a safe, pinned version across affected repositories. If you are comparing supply-chain platforms on how they handle sudden malicious releases, our comparison page lays out the differences.

The maintainer's account is the master key to a package's reputation. Harden the accounts you control, and assume the ones you depend on can fall at any moment.

Frequently Asked Questions

Why is account takeover more dangerous than typosquatting? Typosquatting relies on a victim making a mistake and installing a package with an unfamiliar, misspelled name. Account takeover ships malicious code through the genuine, trusted package a developer already uses, so it inherits that package's full reputation and download base without needing anyone to slip up. The blast radius is correspondingly larger.

How do attackers usually take over a maintainer account? Phishing is the leading method, typically a fake registry email pointing to a lookalike domain that captures the password and a live one-time code, as in the 2025 chalk and debug compromise. Credential reuse from unrelated breaches and stolen publish tokens from CI logs or laptops are also common routes.

Can two-factor authentication stop these attacks? Basic one-time-code MFA can still be phished in real time, which is what happened with the chalk and debug accounts. Phishing-resistant methods like hardware security keys or passkeys, combined with short-lived OIDC-based publishing tokens instead of long-lived stored secrets, close that gap far more effectively.

How quickly do I need to respond to a compromised dependency? Fast, because many takeover campaigns keep the malicious version live for only an hour or two before deleting it to evade analysis. You need to know immediately which of your projects pulled the bad version, roll them back to a pinned safe release, and rotate any credentials the malicious code could have reached during its execution.

Start tracking your dependency risk at app.safeguard.sh/register, and find integration guides at docs.safeguard.sh.