400 Arch Packages Hijacked: How Attackers Inherited Trust in the AUR

There is a specific kind of supply-chain attack that never quite gets old: you don't need to create trust from scratch, you just wait for someone to abandon their project and then step into their shoes. That is exactly what happened to the Arch User Repository, where a threat actor has quietly adopted over 400 orphaned packages, modified their build scripts to pull in a malicious npm package called atomic-lockfile, and sent a credential-stealing rootkit down to whoever happens to run yay -S on those packages.

The story has two waves. The first, reported by Sonatype on June 11, targeted orphaned AUR projects whose maintainers had gone quiet — the attacker simply took ownership and changed the PKGBUILD to run npm install atomic-lockfile during the package install. That npm package bundled a native Linux binary with an eBPF rootkit (using libbpf to load, attach, and pin BPF maps) that can hide processes, files, and network interfaces, plus an infostealer that targets GitHub credentials, SSH keys, Vault tokens, browser cookies, Slack and Discord data, and more. Sonatype initially tracked roughly two dozen affected packages under the codename Atomic Arch. By the next day, a second wave had emerged — some packages now used Bun instead of npm, and the malicious payloads js-digest and lockfile-js joined the cast. Sonatype now estimates around 1,500 packages may be affected. The Arch Linux team, meanwhile, has locked down AUR account creation and package adoption to contain the bleed, and has removed the malicious commits from over 400 packages.

Source article image
Source image 1

What makes Atomic Arch worth paying attention to isn't just the scale — it's the mechanism. The attacker didn't modify the orphaned packages themselves; they modified the PKGBUILD to introduce a third-party dependency. The trusted package is just the delivery vehicle, the malicious code lives in atomic-lockfile, and by the time a user notices something is wrong, the eBPF rootkit has already done its job. If you use AUR packages, the practica

Source article image
Source image 2
l takeaway is simple but not always easy to follow: audit your PKGBUILD install scripts, especially for orphaned packages that suddenly get a new maintainer. The AUR has never been a vetted space, and with AUR account creation now locked, you might be seeing fewer hijacks for now — but the trust model hasn't fundamentally changed.

Sources

Comments

Popular posts from this blog

AI Is Starting to Feel Less Like a Gadget and More Like Infrastructure

When Two AI Bots Finally Learned to Talk in Discord

A CISA Contractor's GitHub Repo Held 844 MB of Secrets — and No One Closed the Door