ForumsResourcesArch Linux AUR Supply Chain Attack: 400+ Packages Serving eBPF Rootkits

Arch Linux AUR Supply Chain Attack: 400+ Packages Serving eBPF Rootkits

SecArch_Diana 6/12/2026 USER

Heads up, everyone. It looks like the Arch User Repository took a massive hit this week. We're talking over 400 packages effectively hijacked to push a Rust-based infostealer. If you maintain Arch boxes, especially for dev work, you need to audit your builds immediately.

The mechanics are nasty: attackers modified the PKGBUILD scripts to execute a Rust binary during the build process. It specifically targets developer credentials (Git, AWS, etc.). If the user happened to run the build with sudo—which, sadly, is common practice for AUR helpers or lazy users—the malware drops an eBPF rootkit to hook into the kernel and hide its tracks.

Since AUR is a community repo, we need to be vigilant about PKGBUILD diffs. If you're using an AUR helper, ensure it actually shows you the diff before building.

For those hunting on your endpoints, you might want to flag suspicious builds. Here is a basic KQL query to look for makepkg spawning network connections (which generally shouldn't happen during a standard local build):

DeviceProcessEvents
| where FileName in ("makepkg", "pacman", "yay", "paru")
| join kind=inner DeviceNetworkEvents on DeviceId, InitiatingProcessId
| project Timestamp, DeviceName, FileName, RemoteUrl, RemotePort

Has anyone started auditing their build logs yet? What's your strategy for vetting AUR packages in a dev environment? Are we looking at containerizing all AUR builds from now on?

NE
NetGuard_Mike6/12/2026

This is exactly why I strictly enforce makepkg as a standard user, never root. However, this eBPF angle is scary because it bypasses standard userland hooks once it's loaded. I'm currently recommending my team switch to distrobox or toolbox for building AUR packages to strictly isolate the build environment from the host kernel.

DN
DNS_Security_Rita6/12/2026

Detection is going to be a nightmare here. eBPF runs effectively at Ring 0, so standard rootkit scanners might miss it if the BPF program hides the /proc entries correctly. We should be looking for the loading of eBPF programs via the bpf() syscall audit logs on critical servers.

# Check audit logs for bpf syscalls from non-root users
ausearch -m bpf -ts recent
PH
PhishFighter_Amy6/12/2026

Supply chain attacks are the gift that keeps on giving. It targets the implicit trust developers have with the repo. The fact that it's a Rust binary is also notable—static analysis is harder, and it runs everywhere without dependencies. I'm seeing reports that the malware specifically looks for .aws and .ssh directories. Time to rotate those keys if you've updated anything this week.

Verified Access Required

To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.

Request Access

Thread Stats

Created6/12/2026
Last Active6/12/2026
Replies3
Views25