Atomic Arch Hijacks 1,500 AUR Packages: Rotate Credentials

Between June 9 and 12, attackers hijacked more than 1,500 packages in the Arch User Repository (AUR) using AUR’s own orphan adoption process as the entry point. The campaign, dubbed “Atomic Arch” by Sonatype researchers, planted a Rust-based credential stealer and eBPF rootkit inside packages that had accumulated years of install trust. If you’re running Arch Linux — or Arch-based CI runners — and updated packages this past week, treat your machine as compromised until you check otherwise.

How the Attack Worked: Turning AUR’s Good Samaritan Rule Against Itself

AUR allows any logged-in user to adopt “orphaned” packages — ones whose original maintainers have gone inactive. The mechanism exists for a good reason: it keeps useful software alive instead of letting it rot. Attackers targeted exactly this trust. They systematically adopted roughly 1,500 orphaned packages, each with real install bases and legitimate histories, then modified the PKGBUILD installation scripts to run npm install atomic-lockfile minimist chalk as a post-install step.

The approach is designed to evade casual review. As Sonatype noted, “the trusted packages themselves do not contain the malicious code” — the malware is pulled at install time from an external npm package. AUR helpers like yay and paru execute these scripts without sandbox isolation, so once you hit install, the binary runs. By June 12, the attackers had adapted to a second wave using Bun as the runtime and renamed packages (js-digest, lockfile-js), suggesting active iteration as the first wave was being blocked.

Related: 10,000 Malicious GitHub Repos Are Pushing Trojans Now

What the AUR Supply Chain Attack Stole

The “atomic-lockfile” binary is a Rust-built infostealer that went after developer credentials comprehensively. The Hacker News investigation confirmed it targeted GitHub and GitLab tokens, npm authentication tokens, HashiCorp Vault tokens, OpenAI API keys, SSH private keys and known_hosts files, shell history files, Docker and Podman credentials, VPN profiles, browser-saved passwords and session cookies from all Chromium-based browsers (Chrome, Edge, Brave), and session data from Electron apps including Slack, Discord, Microsoft Teams, and Telegram.

On systems where the malware executed with elevated privileges, it went further: it deployed an eBPF rootkit with hooks into the getdents64() kernel syscall, hiding processes, files, and network connections from standard security tooling. Data structures for hidden_pids, hidden_names, and hidden_inodes were identified in the binary. The rootkit also includes PTRACE anti-analysis detection. Standard security scans will not find this component. If the rootkit ran on your system, simply removing the package is not sufficient — a full system rebuild from clean media is required.

Check If You’re Affected: Run This Now

The community assembled a detection tool within 24 hours of disclosure. The lenucksi/aur-malware-check repository on GitHub consolidates detection logic from multiple contributors: it cross-references your installed packages against ~1,600 known-compromised packages, scans pacman.log for installs in the June 9-12 window, checks npm and bun caches for malicious packages, and scans /sys/fs/bpf/ for eBPF rootkit traces.

git clone https://github.com/lenucksi/aur-malware-check
cd aur-malware-check
./aur_check-v2.sh --full

If the script flags any packages, take the Sonatype guidance seriously: “Removing the package alone may not be sufficient if the second-stage payload has already executed.” For any system where the malware ran with root access, rebuild from clean installation media. For systems where it ran as a regular user, prioritize credential rotation — but schedule a rebuild when practical, given the rootkit risk.

Credentials to Rotate and Where AUR Goes From Here

Rotate in this order: SSH keys first (immediate lateral access risk), then GitHub and GitLab tokens, npm tokens, cloud provider API keys (AWS, GCP, Azure IAM), HashiCorp Vault token revocation, browser-saved credentials via your password manager, and communication platform sessions (sign out all Slack, Discord, and Teams sessions, then re-authenticate). According to StepSecurity’s analysis, CI runners on Arch are particularly high-risk because they typically run with elevated privileges and carry accumulated stored credentials from pipeline executions.

Arch Linux suspended new AUR account registrations while reverting malicious commits and banning the involved accounts. The community debate that follows is harder to resolve: AUR’s orphan adoption mechanism is genuinely useful and has no clean replacement. Proposed fixes include mandatory 2FA for package committers, probationary periods before newly adopted packages receive direct commit access, and rate limits on bulk orphan adoption requests. None are implemented yet. The CVSS score for this campaign is 8.7 — high severity — and the trust model that enabled it remains largely unchanged.

Key Takeaways

• Run aur-malware-check immediately if you’re on Arch Linux or use Arch-based CI runners — the critical window to audit is June 9-12, 2026.
• If flagged and the malware ran with elevated privileges, a full system rebuild from clean media is required; the eBPF rootkit cannot be reliably removed by package uninstallation alone.
• Rotate SSH keys, GitHub tokens, npm tokens, cloud credentials, and communication platform sessions in that priority order.
• AUR’s orphan adoption mechanism enabled this attack at scale — 1,500 packages in under 72 hours — and structural fixes to the trust model are still under debate.