The Atomic Arch Supply Chain Attack Compromised 400 Packages by Politely Adopting Them — The AUR’s Trust Model Just Graduated From ‘Use at Your Own Risk’ to ‘Your Risk Has Arrived’

🤚 The Open-Palm Package Heist

Security researchers at Sonatype have uncovered a supply chain attack against the Arch User Repository (AUR) that compromised over 400 community-maintained packages — and possibly as many as 1,500 — injecting them with a Rust-based credential stealer and an eBPF rootkit that hides itself from every monitoring tool your sysadmin has ever trusted.

The campaign, dubbed “Atomic Arch” by the researchers, is one of the largest attacks against the AUR in its history, and it was accomplished not by exploiting some exotic zero-day, but by doing the software equivalent of walking into an abandoned house and changing the locks: the attackers adopted orphaned packages through AUR’s standard adoption process.

That’s right. The repository has an official mechanism for claiming unmaintained packages, and the threat actors simply… used it. Politely. Repeatedly. Four hundred times.

👐 The Two-Handed Autopsy

The attack came in two waves. The first injected npm install atomic-lockfile into PKGBUILD files — the build scripts that AUR packages use to compile and install software. The second wave used bun install js-digest, because apparently one JavaScript package manager wasn’t enough to ruin your afternoon.

Both payloads deliver the same gift basket of misery:

  • A Rust-based credential stealer that targets browser data, Electron app sessions (Slack, Discord, Microsoft Teams), SSH keys, VPN configurations, Docker and Podman credentials, GitHub tokens, npm tokens, HashiCorp Vault secrets, shell histories, and basically anything that proves you are a developer
  • An optional eBPF rootkit that activates when the malware has root privileges — it hooks the getdents64() system call to hide its own processes from ps, ls, netstat, and lsof, meaning your standard troubleshooting toolkit is now actively lying to you
  • Systemd persistence, because the malware believes in job security
  • Exfiltration over Tor via multipart HTTP POST to a .onion C2 address, with possible Monero cryptomining staging, because why steal credentials when you can also steal electricity

Sonatype is tracking the campaign as Sonatype-2026-003775 with a CVSS score of 8.7. No CVE has been assigned, presumably because the CVE system was not designed for situations where the threat is “someone used the adopt-a-package button.”

🌿 The Gentle Awakening

The AUR has always operated on a social contract: packages are community-maintained, unvetted, and come with an implicit “you should probably read the PKGBUILD before installing this” disclaimer that approximately zero percent of users have ever followed.

This is not a failure of the AUR’s security model. This is the AUR’s security model. The repository explicitly warns that packages are user-submitted and unsupported. The official Arch Wiki tells you to inspect every PKGBUILD. The community has been saying “use at your own risk” for two decades, and the Atomic Arch campaign is what “your own risk” looks like when it arrives in a Rust binary with Tor connectivity.

The deeper irony is that the attack specifically targeted developers — the exact population that should, in theory, know better. But developers are also the population most likely to install aur/obscure-terminal-utility-that-saves-three-keystrokes without reading the build script, because they have things to ship.

👑 The Gold-Leaf Dependency Reckoning

This is now the third major supply chain attack we’ve covered this quarter, joining the Shai Hulud npm/PyPI worm and the Megalodon GitHub commit flood. Each one uses a slightly different mechanism — signed package poisoning, mass repository commits, orphaned package adoption — but they all exploit the same fundamental assumption: that the software you installed yesterday is the same software you’re running today.

The critical distinction here is that the official Arch Linux repositories are not affected. Only AUR packages — the community-maintained, explicitly-at-your-own-risk packages — were compromised. But telling an Arch user not to use the AUR is like telling a sommelier not to use a corkscrew. It’s technically possible, but you’ve just eliminated the reason they chose the profession.

If you’re running Arch and you’ve installed AUR packages recently, the community has already published detection tools on GitHub. Check your PKGBUILD files for references to atomic-lockfile or js-digest. Rotate your credentials. Inspect your systemd units. And maybe — just maybe — read the build script next time.

Though we both know you won’t.

“The attackers didn’t exploit a vulnerability. They filled out the adoption form, waited patiently, and inherited 400 packages like a well-mannered nephew at a reading of the will. The AUR’s trust model is working exactly as designed, which is the problem.” — The Slap of Wisdom Supply Chain Security Division, currently auditing its own dotfiles and finding three things it doesn’t recognize