400+ Arch Linux AUR Packages Deliver eBPF Rootkit and Infostealer

More than 400 packages in the Arch User Repository have been compromised to distribute a Linux rootkit and credential-stealing malware, marking one of the most extensive supply chain attacks ever to hit the AUR ecosystem.

Security researchers identified the campaign—dubbed "Atomic Arch"—on June 11, 2026. The attackers claimed ownership of orphaned packages through AUR's standard adoption process, then modified PKGBUILD scripts to fetch and execute malicious npm packages during installation.

How the Attack Works

The compromise follows a pattern similar to the npm supply chain attacks we've covered before, but with a Linux-specific twist. Threat actors systematically targeted packages that previous maintainers had abandoned. Once they gained control, they injected preinstall or post-install hooks that silently downloaded two rogue npm packages: atomic-lockfile and js-digest.

These packages deploy a Rust-compiled binary named "deps" with dual functionality. The primary payload functions as an infostealer targeting:

• GitHub credentials and SSH private keys
• HashiCorp Vault tokens
• Browser cookies and session data
• Slack, Discord, Microsoft Teams, and Telegram credentials
• Docker/Podman configurations
• npm tokens and shell histories

The eBPF Rootkit Component

What makes this attack particularly dangerous is the optional rootkit. When the malware lands on a system with root privileges, it loads an eBPF (extended Berkeley Packet Filter) module that operates at kernel level. This component hides the malware's processes, files, and network sockets from standard tools like ps, ls, and netstat.

The rootkit activates conditionally—only when the binary already has root access and the required capabilities. This selective deployment makes forensic analysis difficult because the malware behaves differently depending on privilege level.

Scale of the Compromise

Initial reports identified 400 compromised packages, but later estimates suggest up to 1,600 packages may be affected. The attack primarily targeted development and build environments, making it especially damaging for developers who often have elevated access to production systems and sensitive repositories.

Stolen credentials from developer machines can cascade into much larger breaches. A compromised npm token or GitHub credential can give attackers access to publish malicious updates to legitimate packages, extending the supply chain attack further.

Why AUR Is a Target

The AUR differs from Arch Linux's official repositories. It's a community-driven collection where users submit and maintain packages. Unlike official packages, AUR entries aren't reviewed by Arch maintainers—users install them at their own risk using helper tools like yay or paru.

This trust model creates opportunities for attackers. When a maintainer abandons a package, anyone can request ownership. The Arch community has discussed strengthening adoption policies before, but the decentralized nature of AUR makes comprehensive vetting difficult.

Detection and Response

Community researchers have published detection scripts on GitHub under aur-malware-check. The scripts scan for the presence of atomic-lockfile artifacts and suspicious PKGBUILD modifications.

But here's the uncomfortable reality: removing the AUR package doesn't clean an already-compromised system. Once a rootkit-capable payload has executed with root privileges, the only reliable remediation is a complete reinstallation.

Organizations running Arch Linux in production should:

1. Audit installed AUR packages against the published affected lists
2. Run community detection scripts to identify compromise markers
3. Rotate all credentials stored on potentially affected machines
4. Consider the machine compromised if indicators are present—don't try to clean a rootkit

The broader lesson applies beyond Arch. Community package repositories across every ecosystem—npm, PyPI, AUR, the JetBrains Marketplace—face the same fundamental challenge: balancing openness with security. Until repositories implement stronger vetting for maintainer changes, supply chain attacks will keep working.