TL;DR
- what: Attackers hijacked over 400 Arch User Repository packages by adopting orphaned projects and injecting malicious build scripts that deployed a Rust-based credential stealer with optional eBPF rootkit capabilities.
- impact: Any system that built affected AUR packages after June 11 is credential-compromised, with stolen browser cookies, SSH keys, GitHub/npm tokens, Slack/Discord sessions, Docker credentials, and VPN profiles exfiltrated to attacker infrastructure.
- fix: Check all AUR packages installed after June 11 against community lists, rotate all credentials if affected, hunt for systemd persistence and eBPF artifacts, and reinstall from trusted media if the payload ran as root.
- who: Arch Linux users who installed or updated AUR packages on or after June 11, 2026, particularly developers and teams with privileged access to code repositories and cloud infrastructure.
More than 400 packages in the Arch User Repository were compromised this week in a supply chain attack dubbed Atomic Arch. Attackers adopted orphaned packages, modified their build scripts to install credential-stealing malware, and deployed an eBPF rootkit on systems where the payload executed with root privileges. The campaign began June 11, 2026, and targets developer workstations and build systems with a Rust-based infostealer.
Attack Mechanics: Orphan Adoption and Spoofed Commits
The attack exploited AUR's trust model rather than a technical vulnerability. Attackers adopted packages whose maintainers had abandoned them—a routine and legitimate process—then edited PKGBUILD or .install scripts to execute malicious code during the build phase. They spoofed git commit metadata to make changes appear to originate from established maintainers. An Arch Linux Trusted User later confirmed the impersonated account was never actually compromised.
Modified build scripts called npm install atomic-lockfile or bun install js-digest during package compilation, pulling down malicious npm packages alongside legitimate dependencies for cover. The atomic-lockfile package version 1.4.2 contained a preinstall hook that executed a bundled Linux ELF binary named 'deps'. When users built the package using standard AUR tools, the malware executed automatically. Confirmed affected packages include alvr and premake-git, among hundreds of others.
⚠️ Critical Distinction — Official Arch Linux repositories were not affected. Only the community-maintained Arch User Repository (AUR) was compromised. However, the AUR is widely used by Arch users who build packages from source, making the blast radius significant.
Payload Analysis: Credential Harvesting at Scale
Security researcher Whanos reverse-engineered the deps binary and identified a Rust-based credential stealer targeting developer environments. The malware systematically collects cookies, tokens, and local storage from all Chromium-based browsers including Chrome, Edge, and Brave. It extracts session data from Electron applications such as Slack, Discord, and Microsoft Teams. The stealer specifically hunts for GitHub tokens, npm authentication, HashiCorp Vault credentials, and OpenAI API keys.
Additional targets include SSH private keys, known_hosts files, shell command histories, Docker and Podman credentials, and VPN configuration profiles. Exfiltrated data is transmitted via HTTP to temp.sh, while command-and-control communications route through a Tor onion service using a local loopback proxy. The malware establishes persistence through systemd services configured with Restart=always, ensuring it survives reboots.
- Root execution: copies itself to /var/lib/ and installs system-wide systemd unit under /etc/systemd/system/
- Non-root execution: uses home directory with per-user unit under ~/.config/systemd/user/
- Both modes: systemd service configured for automatic restart on failure
- Secondary payload: unanalyzed binary linked to monero-wallet-gui, flagged as possible cryptominer
The eBPF Rootkit: Conditional but Capable
Early reports overstated the rootkit's role. The eBPF component is optional and only activates when the binary executes with root privileges and the required capabilities. It does not facilitate privilege escalation. When it does load, however, it significantly complicates detection and forensics.
The rootkit uses pinned BPF maps named hidden_pids, hidden_names, and hidden_inodes to conceal the malware's processes, process names, and socket connections from standard monitoring tools like ps, netstat, and lsof. It actively interferes with debugging attempts by killing processes that try to attach debuggers. This capability transforms the incident response calculus: removing the AUR package through the package manager is insufficient once the payload has executed. Package managers can only remove files they know about—they cannot verify system integrity after a rootkit-capable binary has run.
⚠️ Reinstall Decision Point — If any flagged package executed with root privileges, assume the eBPF rootkit is present. Standard cleanup procedures cannot guarantee removal. Reinstall from trusted media or restore from pre-compromise backups.
Scope and the Second Wave
Initial reporting from Sonatype counted over 20 hijacked packages. Within 24 hours, community trackers and the Arch aur-general mailing list thread cataloged more than 400 compromised packages. One consolidated list compiled by grepping the AUR git mirror reached 408 packages, though the exact count continues to fluctuate as malicious commits are identified and reverted.
The atomic-lockfile npm package showed only 134 weekly downloads on Socket before removal from the registry, indicating the primary infection vector was AUR build processes rather than direct npm installations. A second attack wave used bun install js-digest, pushed through separate accounts that community researchers have linked to the same npm publisher behind atomic-lockfile. The js-digest payload is a different ELF binary by hash, also confirmed malicious by the community. The full extent of the second wave remains under investigation, with early estimates ranging from dozens to hundreds of additional affected packages.
Response and Remediation
Arch Linux maintainers are reverting malicious commits, banning attacker accounts, and coordinating with the community through the aur-general mailing list. The affected package list remains incomplete and should be treated as a moving target. Community members have developed detection scripts that compare installed foreign packages against known-compromised sets.
For potentially affected systems, immediate actions include checking all AUR packages installed or updated on or after June 11 against community-maintained lists. Search recent build history and package cache directories for the strings 'npm install atomic-lockfile', 'bun install js-digest', and the payload path 'src/hooks/deps'. Any match indicates compromise.
Credential Rotation and Forensic Sweep
If a flagged package executed, treat the host as credential-compromised. Rotate all credentials the stealer targets: browser sessions across all Chromium-based browsers, SSH private keys, GitHub personal access tokens, npm authentication tokens, HashiCorp Vault credentials, Slack and Discord sessions, Microsoft Teams tokens, Docker Hub and container registry credentials, and any cloud provider API keys stored locally.
Hunt for persistence artifacts by checking for unknown systemd services in both system-wide locations and per-user directories under ~/.config/systemd/user/. Inspect /var/lib/ for unexpected binaries. Examine /sys/fs/bpf/ for the BPF maps hidden_pids, hidden_names, and hidden_inodes—their presence confirms rootkit deployment. Review outbound network connections for Tor traffic and uploads to file-sharing services like temp.sh.
- Grep systemd unit files for services added after June 11 with Restart=always configuration
- Check /var/lib/ and home directories for binaries not installed through package managers
- Mount /sys/fs/bpf/ and list pinned maps; hidden_* entries indicate rootkit presence
- Review firewall and proxy logs for connections to .onion domains and upload services
- If rootkit artifacts are found, plan for system reinstall rather than attempted remediation
Strategic Implications
This attack demonstrates how trust mechanisms in community package ecosystems can be weaponized without exploiting technical vulnerabilities. The AUR's orphan adoption process is legitimate and necessary for repository health, but it creates an opportunity for attackers to inherit established trust relationships. Package names, commit histories, and user expectations remained intact while only the build instructions changed—a technique that bypasses many security intuitions.
The combination of a comprehensive credential stealer with an eBPF rootkit represents a significant escalation in supply chain attack sophistication. Most information stealers prioritize speed and simplicity over persistence and stealth. The inclusion of eBPF-based hiding mechanisms indicates attackers anticipated forensic investigation and built in active defense against detection. For organizations with developers using Arch Linux, this incident should trigger reviews of build environment isolation, credential storage practices, and the extent to which developer workstations are trusted in CI/CD pipelines and cloud infrastructure.
Originally published on RedEye Threat Intelligence.
Top comments (1)
The eBPF rootkit part is what makes this nastier than a typical supply chain attack. Most community detection advice boils down to "grep your installed packages against this list" or "check if these processes are running" — but that assumes the filesystem and process table are telling the truth, which is exactly what a kernel-level rootkit subverts. You'd need to do the integrity check from a live boot or a separate trusted system, not from the compromised host itself. It's a forensic trust hierarchy problem that doesn't get enough attention in incident response playbooks for package manager attacks.