By ByteBot
The Arch Linux DevOps team disabled all package adoptions in the AUR today, July 31, after attackers resumed the Atomic Arch supply chain campaign that compromised over 1,500 packages in June. The same attack method — adopting orphaned packages and injecting malware — bypassed June’s account restrictions in just 18 days. Named packages in today’s wave include i915-sriov-dkms, rtk-git, boringssl-git, warp-terminal-git, and others. If you’ve installed AUR packages recently, treat your credentials as compromised until proven otherwise.
The 18-Day Fix That Wasn’t
The original Atomic Arch campaign broke in June 2026. Arch Linux issued a warning on June 12 about a “high volume” of malicious adoptions, then suspended new account registrations entirely. That bought time, not a solution. On July 13, Arch reopened registrations with “minor restrictions on creating new accounts.” Eighteen days later, the attackers were back.
The core problem was never about who could create accounts. It was about what those accounts could do once created. The AUR’s adoption model lets any registered user claim orphaned packages — the more than 13,000 packages whose original maintainers have gone inactive — with no cryptographic verification tying the new maintainer to the original one. Attackers exploited exactly this. As the Cloud Security Alliance’s technical analysis noted: “Attackers were not building trust from scratch — they were acquiring projects that had already earned it.” A package with five years of clean history and thousands of installs is more dangerous in an attacker’s hands than a brand-new malicious one — because users already trust it.
An Attack Built for Developer Machines
The Atomic Arch payload is not opportunistic malware. It is a targeted, technically sophisticated implant designed for developer workstations and CI/CD pipelines. The delivery chain starts innocuously in the PKGBUILD — an unexpected npm install atomic-lockfile or bun install js-digest call that fetches a Rust-compiled ELF binary named deps. That binary is the credential stealer.
What makes this particularly dangerous is the accompanying eBPF rootkit. It hooks the getdents64() system call — the syscall underlying ls, find, and ps — and maintains three BPF maps at /sys/fs/bpf/: hidden_pids, hidden_names, and hidden_inodes. On an infected system, standard forensic tools become unreliable. The malware persists via a systemd service set to Restart=always and exfiltrates over a Tor onion C2 server, supplemented by uploads to temp.sh to blend with normal developer traffic.
The credential targets are a precise map of what developers store on their machines: SSH keys, GitHub and npm tokens, AWS/GCP/Azure access keys, Docker registry credentials, HashiCorp Vault secrets, OpenAI bearer tokens, and cryptocurrency wallets. A compromised developer machine in most teams means a compromised pipeline — that is the actual threat surface here, not just one person’s laptop.
Related: GitHub and PyPI Slow Down Your Dependencies to Stop Supply Chain Attacks
What Arch Linux Users Should Check Right Now
Start by auditing any AUR packages installed or updated in the last 60 days. If a package recently changed maintainer, treat it as suspect. You can check maintainer history on the Phoronix coverage for the named packages, or via the AUR web interface directly — look for adoptions from accounts with no package history, or packages that received updates after months of inactivity.
Before installing anything from the AUR, read the PKGBUILD. In yay, it prompts automatically; in paru, use paru --print. Watch for these patterns in build functions:
# Red flag: unexpected package manager calls in build functions
prepare() {
npm install atomic-lockfile # should not appear here
bun install js-digest # should not appear here
./deps --install # running a downloaded binary: stop
}
# Red flag: systemd service installed silently for persistence
package() {
install -Dm644 suspicious.service \
"$pkgdir/usr/lib/systemd/system/"
}
If you installed a compromised package, do not rotate credentials from the same machine — the eBPF rootkit makes forensic investigation unreliable on an infected host. Boot from a live environment or use a clean system to rotate SSH keys, GitHub tokens, cloud provider credentials, and API keys. Then audit CI/CD runners that pull from AUR during builds, as pipelines are a common downstream target. For additional context on auditing PKGBUILD scripts safely, FOSS Linux has a practical walkthrough.
Key Takeaways
- AUR package adoptions are fully disabled as of July 31 — the Arch team halted them after the second Atomic Arch wave bypassed June’s account restrictions in 18 days
- The malware deploys an eBPF rootkit that hides itself from
ls,ps, andfind— standard tools will not reveal an infection; investigate from a clean system - Targeted credentials include SSH keys, GitHub tokens, cloud provider keys, OpenAI API tokens, and Docker registry credentials — CI/CD pipelines are the real blast radius
- Rotate credentials from a clean system if you have installed AUR packages recently, especially packages that recently changed maintainers
- The structural fix — cryptographic continuity between original and new package maintainers — has not happened yet; treat the AUR as elevated-risk until it does
