PyPI hijack: elementary-data turned into an infostealer at 1.1M downloads a month

An attacker pushed a malicious version of elementary-data — a Python package central to several open-source data-quality stacks, with 1.1 million downloads a month — and used it to harvest developer credentials, environment variables, and cryptocurrency wallets. The compromise reached PyPI before anyone caught it; the malicious release was live for hours; the back-of-envelope blast radius is large.

The mechanism wasn’t a clever supply-chain manoeuvre. It was a maintainer account. Someone with the right credentials pushed a release. PyPI, npm, RubyGems, Maven Central — every public registry runs this way. Once you have the maintainer token, you have a write path into every downstream build that pulls the package.

This pattern keeps happening because we treat package-registry credentials as if they were personal email accounts: long-lived, password-and-MFA, password-manager-stored, occasionally rotated. They’re not personal email. They’re production write paths. Treat them accordingly. PyPI now requires phishing-resistant MFA on the top 1% of projects by download volume, but the 99th-percentile package is still where most teams’ first dependency injection point lives.

Two controls actually close the gap. On the registry side, mandatory phishing-resistant MFA on every maintainer of every package with a non-trivial follower count, with hard expiry on tokens. On the consumer side, reproducible builds plus provenance attestation — sigstore, npm provenance, SLSA — so a downstream pipeline can refuse a package whose source repository doesn’t match the registry artefact. Neither of these is novel. They’re just not the default yet, and the gap between what’s available and what’s deployed is where these incidents live.

The deeper point. Public-package supply-chain attacks aren’t a developer-discipline problem. They’re a registry-trust problem. The fix lives at the registry, not in your requirements.txt review process.