AUR Builds Become the Payload Path

The compromise is in the build step, not the package name. A trusted-looking PKGBUILD can pull attacker code during a normal local build, so the user’s own workstation becomes the execution point and the compromise can outlive a package cleanup. The usual “check the package and remove it” response misses that the malicious code may already have run outside the package manager. This has widened from tampering with abandoned AUR recipes to active cleanup and continued seeding. Arch froze new AUR signups to slow abuse while more than 1,500 malicious packages were published, and the attackers shifted some installs from NPM-based paths to Bun-based ones. The malware has been tied to credential and secret theft, and on systems with elevated privileges it can try eBPF-based persistence and hiding. The practical break is that community-maintained build instructions now have to be treated like executable code. Any workstation that built an affected package should be assumed to have handled attacker-controlled logic, not just a bad artifact.

Part of the PlainSec briefing for 2026-06-15

Every edition of this story: AUR Builds Become the Payload Path

Sources