The Arch Linux AUR Supply Chain Attack: 1,579 Packages, a Rust Credential Stealer, and an eBPF Rootkit

On the evening of June 11, 2026, the Arch Linux community discovered one of the largest supply chain attacks in the history of Linux distributions. Attackers compromised packages in the Arch User Repository (AUR) — starting with 400, climbing to 900 by morning, and reaching 1,579 packages by evening. They adopted orphaned packages, rewrote the PKGBUILD build instructions, and slipped in a Rust-based malware that harvested developer credentials, SSH keys, and browser sessions. When run with sufficient privileges, the payload loaded an eBPF rootkit to hide itself from standard system tools.

This post walks through exactly how the attack worked, why it succeeded, where the AUR's security model broke down, and — most importantly — what you as a regular Linux user should do right now.

Anatomy of the Attack: Why the AUR Security Model Failed

The AUR is Arch Linux's unofficial, community-maintained package repository. Unlike the official [core] and [extra] repositories, packages can be submitted, maintained, and modified by any user. To install one, you run makepkg, which executes the recipe declared in the PKGBUILD file and produces a binary on your system.

The attackers went straight for the heart of this model:

Adopting orphaned packages: Thousands of AUR packages become "orphaned" when their original maintainer loses interest. These packages can be adopted by anyone willing to file the request. The attackers bulk-adopted these abandoned projects.
Spoofed git commit metadata: The malicious changes appeared to come from a long-standing, trusted maintainer. An Arch Linux Trusted User later confirmed that none of these accounts were actually compromised — fake commit metadata was enough.
Modifying PKGBUILD and .install scripts: The package name, history, version number, comments — all unchanged. Only the build instructions were modified. When a user typed pacman -U package-1.2.3.pkg.tar.zst or yay -S package, they unknowingly ran the malicious code.
A second channel via npm: The first wave called npm install atomic-lockfile, while the second wave used bun install js-digest. Both packages downloaded a Linux ELF binary (deps) and ran it in their preinstall hook.

The result: the package itself wasn't malicious — it became malicious during the build step. This is a new evolution in modern supply chain attacks. Typosquatting and fake domains are no longer enough; attackers now inherit the trust of legitimate projects.

What the Malware Does: A Technical Breakdown

According to independent researcher Whanos's reverse-engineering work published on ioctl.fail, the deps payload is a Rust binary. It collects:

Cookies, tokens, and local storage from Chromium-based browsers (Chrome, Edge, Brave, Vivaldi, etc.)
Session data from Electron applications (Slack, Discord, Microsoft Teams)
GitHub, npm, and HashiCorp Vault tokens, plus OpenAI/ChatGPT bearer tokens
SSH keys, known_hosts, and shell history
Docker and Podman credentials, VPN profiles

Stolen files are exfiltrated over HTTP to temp.sh. Command and control (C2) runs through a Tor onion service via a loopback proxy. Even if your Tor traffic is analyzed, the C2 endpoint is .onion — only the onion address is visible.

Persistence Mechanism

When run with root privileges, the binary copies itself under /var/lib/ and writes a systemd unit under /etc/systemd/system/. When run as a regular user, it uses the home directory and a per-user unit under ~/.config/systemd/user/. Either way, Restart=always ensures it comes back at every boot.

The eBPF Rootkit: The Worrying Part

eBPF (extended Berkeley Packet Filter) is a Linux kernel sandbox mechanism that has powered networking and observability workloads since the 4.x kernel series. It has also become the favorite tool of rootkit authors in recent years — because it runs inside the kernel, classical user-space detection tools can't see it.

The eBPF rootkit in this attack is optional — it loads only when the binary has root and the right capabilities. When it does load, it does the following:

Hides the malware's own processes, process names, and socket inodes from standard tools (ps, ss, lsof)
Pins BPF maps named hidden_pids, hidden_names, and hidden_inodes
Kills attempts to attach a debugger

This changes the cleanup advice entirely: simply removing the malicious AUR package is not enough. A package manager can remove the files it knows about. It cannot prove a system is clean after a rootkit-capable payload has had a chance to execute.

Why Did the Attack Succeed?

Several structural factors converged:

1. The AUR Trust Model Doesn't Ask "Who"

AUR trusts a package's name and history, not who is currently maintaining it. When a package has been maintained by a trusted developer for 10 years and then becomes orphaned, whoever adopts it inherits the same level of trust. This is a structural problem common to all community repositories (AUR, Ubuntu PPA, Fedora COPR, openSUSE Build Service, Homebrew).

2. Nobody Reads Build Scripts

Most Arch users type yay -S package-name, scroll past the output, and hit Enter. The attackers know this — adding npm install atomic-lockfile to a PKGBUILD looks perfectly natural and goes unnoticed.

3. Multi-Stage Payload

The malware runs in two stages: first an npm package is downloaded (looking harmless), then a preinstall hook triggers the Linux binary. This bypasses simple static analysis tools like grep.

4. eBPF's Double-Edged Nature

eBPF is fantastic for kernel observability (used by Cilium, Falco, Pixie). But the same power is gold for attackers who want to hide at the kernel level. The community has not yet established clear detection standards for eBPF-based attacks.

What You Should Do Now: A Step-by-Step Guide

This attack targeted Arch Linux specifically, but the logic applies to every community repository. Ubuntu PPA, Fedora COPR, openSUSE Build Service, Homebrew — they all share similar trust models. The steps below apply regardless of which distribution you use:

1. Audit Your Installed Packages

If you've installed or updated any AUR package since June 11, 2026, check the affected package list on Arch's aur-general mailing list and md.archlinux.org immediately:

# List locally installed AUR (foreign) packages
pacman -Qem | sort

# Scan local cache
grep -r "atomic-lockfile\|js-digest" ~/.cache/yay/ 2>/dev/null
grep -r "src/hooks/deps" ~/.cache/yay/ 2>/dev/null

If you find a flagged package, or any reference to atomic-lockfile or js-digest, check all systemd units at both system and user level:

# Unknown systemd services
systemctl list-unit-files --state=enabled | grep -v "^UNIT"

# User-level units
ls -la ~/.config/systemd/user/

# Suspicious binaries under /var/lib/
find /var/lib -type f -executable -newer /tmp -mtime -7

2. Check for an eBPF Rootkit

If an affected package ran as root, the eBPF rootkit may be loaded. To check:

# List pinned BPF maps
ls -la /sys/fs/bpf/

# List BPF programs
bpftool prog list 2>/dev/null

# Look for suspicious map names
bpftool map list 2>/dev/null | grep -i "hidden"

If you see hidden_pids, hidden_names, or hidden_inodes, the rootkit is present. At that point, your only trustworthy option is a clean reinstall from trusted media.

3. Rotate Every Credential

Renew everything the stealer touches. It's tedious but necessary:

Browser sessions: Log out of everything (Google, GitHub, GitLab, banking)
SSH keys: Delete everything under ~/.ssh/ and regenerate. Reset known_hosts.
GitHub / GitLab tokens: Revoke every deployment key and PAT on your repositories.
npm token: Run npm token revoke to revoke all tokens.
HashiCorp Vault, Docker, Podman credentials: Issue fresh ones.
Slack, Teams, Discord: Terminate all active sessions.
Cloud provider keys (AWS, GCP, Azure): Rotate IAM credentials.

4. Going Forward: Supply Chain Hygiene

This won't be the last attack. Expect more in the coming years. To protect yourself:

Always read build scripts. PKGBUILD, debian/rules, rpm.spec — always read the recipe first. If you don't understand a line, don't install.
Be suspicious of recently adopted or long-dormant packages. If a package that hasn't seen an update in 3 years suddenly publishes a new version, double-check the build instructions.
Use the diff view of AUR helpers. yay and paru have a -G (GetPkgbuild) flag that lets you inspect a package before building:
```
yay -G package-name
cd package-name
# Inspect PKGBUILD
# Build once you're confident
makepkg -si
```
Verify signatures. Check GPG keys. Verify which maintainer uses which key.
Sandbox your builds. Run package builds in bubblewrap or firejail for isolation.
Avoid AUR on critical workstations. For servers and CI/CD, stick to official repositories. AUR is an acceptable risk for personal use but too risky for production.

Lessons for the Linux Community

This attack shows, once again, the limits of the community repository security model. A similar incident hit a PDF viewer package back in 2018; the 2026 version simply scaled it up.

The required changes are clear:

Mandatory grace period on maintainer changes: After a package changes maintainer, distribution should be paused for a fixed period (e.g., 30 days).
Automatic build instruction change detection: New curl, wget, npm install, pip install calls in PKGBUILD should be automatically flagged.
Mandatory sandbox builds: AUR packages should be built in sandboxed environments so the payload infects an isolated container, not the user's system.
Trust score system: Show a trust score based on the maintainer's account age, activity history, and 2FA status.

The Arch community is currently cleaning up commits and banning accounts, but these are reactive measures. Moving to a proactive security model will be the most important agenda for Arch — and for every other community repository — in the coming years.

Conclusion: Security Is a Practice, Not a Product

This attack isn't extraordinary in isolation — it's a masterful combination of known vectors (orphaned package adoption, malicious build script, multi-stage payload, eBPF rootkit). What's extraordinary is the scale: 1,579 packages, two simultaneous waves, professional-grade OPSEC (Tor C2, fake metadata, immutable BPF maps).

If you use the AUR, the most important lesson from this incident is: the Linux advice to "only install from official repos" is no longer enough. Community repositories will always require some level of trust, and that trust means understanding the ecosystem, reading build instructions, and staying skeptical.

Cybersecurity is ultimately a practice, not a product. Today it was 1,579 AUR packages; tomorrow another attack will hit another repository. The prepared win.

Sources: