400+ AUR Packages Hijacked to Deploy Credential Stealer and eBPF Rootkit

What Happened

Attackers this week compromised more than 400 packages in the Arch User Repository (AUR), rewriting their PKGBUILD scripts to silently install malware on any machine that compiled them. The payload is a Rust binary built specifically to harvest developer secrets — SSH keys, API tokens, shell history, and stored credentials. On systems where the build ran with elevated privileges, a second stage deploys an eBPF rootkit that operates at the kernel level and is exceptionally difficult to detect or remove with conventional tooling.

Why It Matters

AUR is the unofficial but widely-used community package repository for Arch Linux and its derivatives (Manjaro, EndeavourOS, etc.). Unlike the official Arch repos, AUR packages are not reviewed or cryptographically signed by Arch maintainers — trust lives entirely in whoever owns the maintainer account. Hijacking that account via credential stuffing or a reused password is all it takes to push malicious PKGBUILD code to every machine that subsequently runs yay -S <package> or a similar AUR helper.

The threat extends well beyond the compromised workstation. Developers typically hold SSH keys, cloud provider credentials, and API tokens that reach production infrastructure. A single stolen key from a laptop can become unauthorized access to an AWS account, a CI/CD pipeline, or a production database — and the attacker has it before the developer ever notices anything wrong.

The eBPF rootkit component raises the stakes further. Because eBPF runs inside the kernel, it can intercept system calls and conceal its own presence from userspace security tools. Standard antivirus and most EDR agents will not detect it from within the running OS.

What to Do

1. Identify your exposure. Check your pacman logs or AUR helper history (~/.cache/yay, etc.) for packages built in the past week. The full list of affected package names has not been published at time of writing — monitor The Hacker News for the IOC list as it becomes available.

2. Rotate all credentials immediately. If you built any AUR package during the affected window, treat the machine as fully compromised. Rotate SSH keys, revoke and reissue API tokens, and change passwords for anything stored in browser profiles, .env files, dotfiles, or shell history.

3. Audit for the rootkit from outside the OS. An eBPF rootkit cannot be reliably detected from within the compromised system. Boot from a live USB and inspect running processes, loaded kernel modules, and filesystem artifacts from a clean environment before trusting any output from the suspect machine.

4. Rebuild from clean media. For any machine you cannot fully audit externally, reinstall from scratch. Restore only configuration you have reviewed line-by-line from a known-clean backup.

5. Harden your AUR workflow going forward. Manually review PKGBUILD diffs before every build, consider pinning to known-good commits, and move security-critical tooling to fully verified package sources.