Over 400 AUR Packages Backdoored With Rust-Based Credential Stealer
Attackers rewrote build scripts in Arch's community repo to drop a secret-harvesting binary, with an eBPF rootkit waiting if it gets root.
Key points
- More than 400 AUR packages were hijacked this week and their build scripts rewritten to install a Rust-based credential stealer at build time.
- Anyone who ran
makepkgor an AUR helper against an affected package executed the payload as part of the normal build process. - The stealer targets SSH keys, shell history, cloud credentials, and browser-stored tokens.
- If the build ran as root, the malware also loads an eBPF (extended Berkeley Packet Filter) rootkit to hide itself from standard Linux tooling.
- The AUR's trust model has always required users to read build scripts before running them.
What got hit and how
Someone spent the week poisoning the Arch User Repository. More than 400 packages were taken over and their PKGBUILD scripts rewritten to fetch and install a Rust-compiled credential stealer at build time. Anyone who ran makepkg, or an AUR helper like yay or paru, against an affected package executed the payload as part of the normal build process.
The AUR is community-maintained, and that distinction matters. It sits separately from the official, curated Arch repositories. AUR submissions are user-uploaded shell recipes, and the trust model has always been "read the PKGBUILD before you build." Almost nobody does.
What the payload actually does
The payload is a Rust binary aimed at developer secrets: SSH keys, shell history, cloud credential files, browser-stored tokens. Exfil happens over the network once collection finishes. If the build ran with root, which is not unusual for system-level packages needing privileged install steps, the malware additionally drops an eBPF component that functions as a rootkit, hiding itself from userland tooling. Defenders relying on ps or netstat to spot anomalies will not see what they expect. We first covered eBPF rootkits as an emerging post-exploitation pattern on 12 June 2026.
The scale here, 400-plus packages from what looks like a coordinated push, suggests either a batch compromise of maintainer accounts or an automated upload campaign using fresh accounts to trojanize popular packages. At time of writing, AUR maintainers had not published a post-mortem confirming the vector.
Should you worry?
If you have installed anything from the AUR in the last several days, assume credential exposure until proven otherwise. Supply-chain attacks targeting developer credentials have been a recurring pattern: our coverage of the Miasma campaign on 1 June 2026 showed the same harvest-and-exfil logic deployed through compromised npm packages.
What to do now
- Revoke SSH keys, cloud API tokens, and any credentials that lived on the build host, then rotate.
- On systems where AUR builds ran as root, treat the box as compromised. An eBPF rootkit is not something you clean in place; reinstall.
- Build AUR packages in a throwaway container or unprivileged user namespace, not on your daily driver.
The bigger picture
This is not a vulnerability in Arch or in pacman. It's an abuse of a trust model that was always documented as "you are the reviewer." The community-repo supply chain is one of the softest targets in Linux distribution, and Arch is not alone, as prior incidents in PyPI and npm show. What to watch next: whether the AUR maintainers identify a single account-compromise vector or confirm this was an automated campaign, because that distinction changes how hard the problem is to fix.
Read your PKGBUILDs.
