Arch Linux AUR hit by malware targeting developer secrets

One of the largest open-source package repositories just spent a weekend cleaning up after a malware campaign that did not break into anything. It did not need to.

Attackers seized control of more than 1,500 packages in the Arch User Repository, or AUR, the community-run software collection that sits alongside Arch Linux's official repositories, and quietly rewrote their build instructions to install a credential stealer on any machine that compiled them. By Monday, the project had taken the unusual step of freezing new account registration while it cleaned up.

The number kept moving. It started at around 400 packages, climbed past 1,500 over the weekend, and one tracking list named 1,579, which Arch itself described as “many, but not all” of those hit. Crucially, Arch's core distribution and its official repos were never affected.

An attack on trust, not a flaw

What makes this notable is how little hacking was involved. The AUR is user-submitted and explicitly unsupported: Arch tells people to read a package's build file before installing it, every time. There is no vetting, by design.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

The attackers exploited exactly that. They adopted “orphaned” packages, ones whose maintainers had walked away, inheriting the names, histories, and trust those packages had built up. Security firm Sonatype, which dubbed the campaign “Atomic Arch”, found them spoofing git commit data so the changes looked like they came from a long-standing maintainer.

That account, an Arch Trusted User later confirmed, was never actually compromised.

Only the build recipe changed. Edited scripts pulled in a malicious npm package, atomic-lockfile, whose install hook ran a hidden binary the moment the package was built. The software looked exactly like what users meant to install. It is the same logic behind the Miasma worm that hit 73 Microsoft GitHub repositories: compromise the trust, not the code.

A trap built for developers

The payload, a Rust binary reverse-engineered by the researcher Whanos, is built to rob developers specifically, which is the point. The people who build AUR packages are exactly the people whose machines hold the keys to everything else.

It harvests browser cookies and session tokens, logins from Slack, Discord and Microsoft Teams, GitHub and npm tokens, HashiCorp Vault and OpenAI credentials, SSH keys, Docker logins, and VPN profiles, then ships them out and phones home over Tor.

Those are the exact credentials used to seed the next supply-chain attack, the same pattern as last year's poisoned VS Code extension that cost GitHub thousands of repos.

Early coverage played up an eBPF “rootkit”, and that part is worth tempering. As The Hacker News notes, it is optional, only loads if the malware already has root, and is not used to gain access. When it does run it hides the malware and blocks debuggers, which matters for one reason: if a poisoned package ran with root on your machine, removing it is not enough. You reinstall.

The cost of an open door

None of this is new for Arch. A near-identical adoption trick hit an abandoned PDF-viewer package back in 2018, and in 2025 the project weathered both a fortnight-long denial-of-service attack and a set of compromised browser packages carrying a remote-access trojan.

It is also part of a broader 2026 shift. Attackers are increasingly hijacking orphaned, trusted projects rather than typosquatting new ones, a tactic that now threatens the AI coding agents being pointed at unfamiliar repositories too. With roughly 13,000 orphaned packages still sitting in the AUR, the attack surface is enormous.

Arch's maintainers are resetting the malicious commits and banning the accounts, and the advice to users is unchanged: read the build script before you build, and treat any recently adopted or suddenly active package with suspicion.

The harder problem is structural. A repository that trusts a package's name and history over whoever is maintaining it today has no patch for that, only a decision about how much longer the open door stays open.