Over 400 Arch Linux AUR Packages Hijacked in 'Atomic Arch' Supply-Chain Attack

Around June 11, 2026, the Arch Linux community and multiple security firms disclosed a supply-chain attack on the Arch User Repository (AUR), the community-maintained collection of build scripts (PKGBUILDs) for software outside Arch's official repositories. Attackers used the AUR's legitimate package-adoption process to take over orphaned packages - abandoned projects that still carried trusted names and install histories - and then modified their build instructions. Supply-chain firm Sonatype named the campaign 'Atomic Arch.' Its first write-up counted roughly 20 hijacked packages, but within a day community trackers grepping the AUR git mirror had catalogued more than 400 (around 408), and consolidated lists climbed higher. Crucially, Arch's official repositories ([core], [extra], [multilib]) were not affected - those undergo stricter review.

The attackers modified each hijacked package's PKGBUILD or install hook to run npm install atomic-lockfile - a malicious npm package masquerading as a legitimate one (version 1.4.2) - during package build or install. A second wave used bun install js-digest from linked accounts. The npm package carried an ELF payload at src/hooks/deps, executed automatically via a preinstall lifecycle hook. Independent researcher Whanos analyzed the binary as a Rust-compiled credential stealer with, in their words, "optional root-only eBPF rootkit capabilities." It harvests browser cookies and session tokens, developer tool secrets, and SSH keys, and communicates with command-and-control over an encoded onion service via a local loopback proxy. When it runs with root - for example when a user built the package with sudo privileges available - it can load an eBPF rootkit to hide its processes, files, and sockets. A staged file tied to monero-wallet-gui was flagged as a possible, unanalyzed cryptominer.

The risk falls on Arch Linux and Arch-based distributions (such as EndeavourOS, and Manjaro when the AUR is used) where a user installed or updated an affected package on or after June 11, 2026. Because AUR helpers like yay and paru execute PKGBUILD logic locally, the payload runs on the building machine - so developer workstations and self-hosted CI/build runners are the primary exposure. Organizations with Arch-based CI/CD are a particular concern: build artifacts produced during the window could carry embedded malware downstream. Notably, the malicious atomic-lockfile npm package itself showed only ~134 weekly downloads before removal, so the real exposure is the AUR build path, not direct npm installs.

The Arch Linux security team and package maintainers responded through the aur-general mailing list, reverting the malicious PKGBUILD commits, permanently banning the accounts pushing them, and helping compile lists of affected packages. Maintainer Jonathan Groteluschen urged users to report any malicious package they find. Community members published detection scripts (for example, consolidated tooling that cross-references installed foreign packages against known-bad lists). Because the affected-package list is compiled from community analysis of the AUR git mirror, maintainers and researchers caution that it remains incomplete and still growing.

If you use the AUR, act on the assumption that any package installed or updated on or after June 11, 2026 may be affected. Run pacman -Qm to list foreign (AUR) packages and cross-reference them against the community affected-package lists and detection scripts. Grep recent build history and caches for npm install atomic-lockfile, bun install js-digest, and the payload path src/hooks/deps, and check for the eBPF rootkit artifact /sys/fs/bpf/hidden_* from a trusted environment. If a flagged package ran - especially with root - treat the host as fully compromised: rotate all credentials (SSH keys, GitHub/npm tokens, cloud and Vault keys, browser sessions) and rebuild from clean media, since an eBPF rootkit can survive ordinary cleanup. Going forward, review PKGBUILDs before installing, and be suspicious of a recently adopted package that suddenly adds npm/bun/pip install hooks unrelated to its function.

Almost nothing about this attack is Arch-specific. The weakness is the trust model of open package ecosystems: orphaned-but-trusted packages that can be adopted exist in npm, PyPI, crates.io, and elsewhere, and any pipeline that pulls dependencies without scrutiny inherits the same risk. Sonatype characterized 'Atomic Arch' as a deliberate strategy of hijacking orphaned packages with existing install bases to inherit trust rather than typosquatting. Expect continued cataloguing of affected packages, possible further waves using different toolchains to dodge detection signatures, and renewed pressure for structural fixes - stronger signing, provenance, reproducible builds, and scrutiny of package-adoption events.

Developer and CI credentials on affected Arch hosts may have been stolen, and hosts where the payload ran as root may carry an eBPF rootkit requiring a full rebuild. The blast radius is limited to AUR users but includes high-value developer and build systems.

Security: Affected hosts should be treated as fully compromised; rootkit persistence means a one-off scan is insufficient.

Privacy: Harvested credentials and session tokens could enable account takeover across connected services.

The 'Atomic Arch' campaign hijacked 400+ orphaned AUR packages by rewriting their build scripts to pull atomic-lockfile, delivering a Rust credential stealer with an optional eBPF rootkit on root hosts. Arch's official repositories were not affected, and maintainers reverted the commits and banned the accounts - but the affected-package list is incomplete.