Over 400 Arch Linux AUR Packages Poisoned with eBPF Rootkit in Coordinated Maintainer Compromise

A coordinated supply chain attack against the Arch Linux User Repository (AUR) has compromised more than 400 packages, poisoning them with preinstall scripts that deliver a credential-stealing infostealer and — in a significant escalation — an eBPF kernel rootkit capable of surviving package removal. The attack exploited AUR’s community-maintained model, with the threat actor spoofing the identities of established maintainers to push malicious package versions.

What Happened

AUR packages depend on community contributors to maintain and update PKGBUILD files — shell scripts that define how packages are downloaded, built, and installed. The attacker targeted this trust model, registering accounts that impersonated longstanding trusted maintainers and submitting updated PKGBUILD files that added malicious preinstall() hooks to legitimate packages.

Those hooks pull a secondary stage from a public npm package (atomic-lockfile), which decodes to an ELF Linux binary. Depending on whether the target system meets attacker-defined criteria — kernel version, presence of development tooling, privilege level — the binary deploys either the infostealer alone or both the infostealer and the eBPF rootkit component.

The eBPF rootkit hooks kernel functions to hide network connections and processes, and can survive pacman -R removal attempts because it persists in kernel space rather than on the filesystem as a conventional binary.

What Gets Stolen

The infostealer component is designed specifically for developer environments:

• GitHub personal access tokens and SSH private keys
• Cloud provider credentials — AWS ~/.aws/credentials, GCP service account JSON files, Azure CLI tokens
• HashiCorp Vault tokens stored in the default paths
• Slack, Discord, Teams, and Telegram session cookies and local databases
• Browser credential stores (Chrome, Firefox, Brave profile directories)
• npm authentication tokens (~/.npmrc) and PyPI credentials

The credential profile corresponds to the access level needed to inject further malicious packages, pivot into CI/CD pipelines, or exfiltrate proprietary source code. The attack is architecturally similar to TeamPCP’s supply chain campaign earlier this year, which similarly targeted developer tool distribution channels.

Why AUR Is Particularly Exposed

Unlike the official Arch Linux repositories, AUR packages are not reviewed or signed by the Arch Linux distribution team. The AUR model places full trust on the registered maintainer of each package. Maintainer identity is verified only at account registration, not at each package update — meaning a compromised or spoofed maintainer account can push malicious builds indefinitely until discovered.

The Arch Linux project has historically acknowledged this limitation and strongly advises users to inspect PKGBUILD files before building. In practice, most developers use AUR helpers (yay, paru) that automate package installation without prompting for manual review.

The volume of this attack — 400+ packages — suggests either automated PKGBUILD manipulation or a long-running, low-volume poisoning campaign. Arch Linux security maintainers were notified on 12 June; affected package versions are being removed and maintainer accounts suspended.

Recommended Actions

• Audit recently installed AUR packages — run pacman -Q and cross-reference against the disclosed list of compromised packages (being published by the Arch Linux security team). Pay particular attention to packages installed or updated between 1 June and 16 June.
• Rotate all developer credentials immediately on any Arch Linux system that installed AUR packages during the affected window — GitHub tokens, SSH keys, cloud IAM credentials, npm tokens, and vault secrets.
• Check for eBPF persistence — the rootkit hides processes and network connections. Run bpftool prog list to enumerate loaded eBPF programmes and look for anomalous entries. On compromised systems, assume that rebooting into a clean kernel and reinstalling from official repos is required.
• Review CI/CD pipeline credentials — if the compromised system had access to CI/CD secrets or deployment credentials, treat those as exposed and rotate them regardless of whether evidence of exfiltration exists.
• Consider limiting AUR usage in production or developer environments to a curated allowlist, and deploy AUR helper configurations that require explicit PKGBUILD review before building.
• Monitor npm for the atomic-lockfile package — it has been reported to the npm security team; track whether it reappears under alternative names.