# 400+ Arch Linux AUR Packages Hijacked in Supply Chain Attack: Credential Stealer and eBPF Rootkit Discovered
Attackers exploited trust in Arch User Repository, compromising build scripts across hundreds of packages. The campaign, dubbed "Atomic Arch," targeted abandoned projects and developer workstations with a sophisticated Rust-based infostealer paired with an optional rootkit.
On June 11, 2026, security researchers at Sonatype uncovered a massive supply chain attack against the Arch User Repository (AUR), with over 400 community-maintained Linux packages compromised. The attack bypassed Arch's official systems entirely, instead targeting the trust model itself. Attackers edited build instructions in abandoned packages to inject a credential-stealing malware that executes during package compilation. The payload, a Rust binary designed to harvest developer secrets, can pair with an eBPF rootkit for post-exploitation persistence when run with elevated privileges.
## The Threat
The attack is deceptively simple in execution but sophisticated in scope. Attackers identified Arch Linux packages whose original maintainers had abandoned them, then claimed ownership through the AUR's adoption process. Once in control, they modified the package's build scripts—specifically the PKGBUILD or .install files—to inject a malicious npm dependency called atomic-lockfile@1.4.2.
When developers or system administrators built these packages from source, the build process automatically pulled this backdoored npm module, which contained a preinstall hook that executed a bundled Linux ELF binary named deps. This single-stage injection triggered the entire attack chain.
The confirmed affected packages include alvr (a virtual reality streaming tool) and premake-git (a build system), but Sonatype's preliminary analysis identified at least 400 compromised entries, with the full scope still being assessed.
"The trap sat in the recipe, leaving the package itself looking exactly like the software users meant to install," according to Sonatype's research. No zero-day exploits, no system compromises at the Arch level—just a poisoned build process and user trust.
## Background and Context
The Arch User Repository represents a unique trust model in Linux packaging. Unlike Arch's official repositories, which are curated and signed by maintainers, the AUR is a community-driven collection where users can submit and maintain packages. Packages are built from source using PKGBUILD scripts, giving maintainers fine-grained control over compilation but also creating a vector for malicious tampering.
The repository's design assumes that package maintainers are trustworthy actors. Abandonware—packages whose original creators stopped maintaining—presents a gap in that assumption. The AUR allows trusted community members to adopt orphaned packages and continue development, a pragmatic approach that keeps useful software available. However, this process can be vulnerable to account takeovers or spoofing.
In this attack, adversaries exploited both mechanisms:
This approach is notably different from recent supply chain attacks on PyPI, npm, or Ruby Gems, which typically involve credential theft or social engineering. Atomic Arch relies on exploiting the repository's trust model rather than breaking into central infrastructure.
## Technical Details
The Infostealer Payload
Independent researcher Whanos reverse-engineered the deps binary and identified a Rust-based credential stealer optimized for developer workstations and build environments. The malware collects:
| Target | Details |
|--------|---------|
| Browser Data | Cookies, tokens, and local storage from Chromium-based browsers (Chrome, Edge, Brave, Vivaldi, and others) |
| Chat & Productivity | Session data from Electron apps including Slack, Discord, and Microsoft Teams |
| Developer Credentials | GitHub tokens, npm tokens, HashiCorp Vault credentials, OpenAI/ChatGPT bearer tokens |
| SSH & System | SSH keys, known_hosts files, shell command histories |
| Container & VPN | Docker and Podman credentials, VPN profiles and connection metadata |
Stolen data is exfiltrated over HTTP to temp.sh, while command and control operates through a Tor onion service accessed via a local loopback proxy, obfuscating the attacker's infrastructure from network monitoring.
Persistence and the eBPF Rootkit
The malware installs a systemd service with Restart=always, ensuring it survives reboots. When run as root, it copies itself to /var/lib/ and registers a system-wide unit under /etc/systemd/system/. Non-root execution uses the user's home directory and a per-user unit under ~/.config/systemd/user/.
The optional eBPF rootkit activates only when the binary already has root privileges and the appropriate kernel capability. Contrary to early reporting, it does not escalate privileges itself. Instead, it hides the malware's processes, process names, and socket inodes from standard forensic tools using pinned BPF maps (hidden_pids, hidden_names, hidden_inodes). It also kills attempts to attach debuggers, making analysis and cleanup significantly more difficult.
The combination of a modern rootkit with a smash-and-grab stealer is unusual, elevating the attack beyond typical supply chain compromises. Analysis also flagged a secondary payload tied to monero-wallet-gui, suggesting possible cryptomining capabilities, though this remains unconfirmed pending deeper investigation.
## Implications and Risk
Who Is Exposed
This attack specifically targets developers, DevOps engineers, and build system operators—high-value victims whose credentials unlock CI/CD pipelines, cloud infrastructure, and source code repositories. An attacker harvesting a GitHub token from a compromised AUR builder gains potential access to dozens of downstream projects. SSH keys stolen from developer machines could unlock internal infrastructure.
The attack is particularly dangerous because:
1. Build systems are trusted environments: Developers typically run package builds with elevated privileges or in semi-isolated environments, making the eBPF rootkit particularly effective.
2. Developers hold multiple secrets: A single compromised workstation yields credentials across GitHub, npm, Docker, Slack, AWS, and more—a gold mine for lateral movement.
3. Silent persistence: The rootkit-enabled variant can hide itself from standard detection tools, delaying discovery.
Detection and Remediation Challenges
Removing the AUR package via pacman is insufficient once the payload executes. A package manager only removes files it knows about. It cannot prove the system is clean after a rootkit-capable payload has run with elevated privileges. Organizations that installed or updated affected packages on or after June 11 should:
## Recommendations
For Arch Linux Users and Maintainers
fakeroot where possible.For All Organizations
---
## HackWire Analysis
This attack represents a maturation of supply chain tactics that should alarm both the Linux community and enterprises relying on open-source tooling. We've seen attacks on centralized registries before—but Atomic Arch sidesteps infrastructure security entirely by exploiting the repository's governance model.
What makes this significant is not just the scale (400+ packages) or the sophistication (eBPF rootkit), but the *targeting*. Developers are the easiest path to infrastructure. A single stolen GitHub token or SSH key from a compromised build machine can unlock CI/CD systems, internal Git repositories, cloud deployments, and staging environments. Attackers know this. The malware's credential-stealing focus is surgical—it's not spraying for user passwords, it's hunting for the keys that unlock the kingdom.
The spoofed git metadata and abandoned-package approach also highlights a cultural blind spot in open-source governance. Trusted User accounts are assumed to be secure, but the attack proved you don't need to compromise the account—you just need to look like it. This is a test of Arch's capacity to detect and respond to subtle metadata anomalies, something most package repositories struggle with.
Pattern recognition matters here: we've seen similar dynamics in npm (2021 discord.js-self takeover), Ruby Gems (rest-client compromise), and PyPI (multiple campaigns). The AUR's lower barrier to entry makes it more accessible to attackers, but also more difficult to police. Expect copycat attacks on other community repositories with similar trust models.
The eBPF rootkit is a tactical detail worth highlighting. It's not a game-changer—rootkit-capable malware has existed for decades—but pairing it with a smash-and-grab stealer instead of using it for privilege escalation suggests the attacker expects to land with root privileges already. This assumption is worth testing in your own environment: where do your build processes run, and what privileges do they hold?
For defenders: treat this as a wake-up call to isolate build environments, rotate all secrets from any machine that touched an AUR package between June 11 and today, and assume that developers' workstations may be compromised until proven otherwise.
— HackWire Editorial
---
## Related Coverage