By ByteBot
On June 11, a single attacker—operating under the username “arojas”—adopted 408 orphaned packages in the Arch User Repository and injected them with a Linux credential stealer called “deps.” The malware ships with an optional eBPF rootkit that hides itself at the kernel level, making standard detection tools unreliable on compromised root systems. If you have installed or updated AUR packages in the last 48 hours, assume your system may be compromised until you can verify otherwise.
The campaign, dubbed “Atomic Arch” by Sonatype researchers, is not a generic grab-whatever-you-can malware run. The payload is purpose-built for developer workstations. It targets SSH keys, GitHub tokens, npm credentials, Docker and Podman auth, HashiCorp Vault tokens, browser session data, Slack, Discord, Microsoft Teams, Telegram, VPN config files, and shell histories. An attacker with those credentials does not need to hack your servers directly—they can walk through the front door as you.
How Attackers Hijacked 408 AUR Packages
The AUR allows any user to adopt orphaned packages—ones whose original maintainer has abandoned them. The process requires minimal vetting. Arojas used this mechanism to take control of 408 packages at scale, likely via automated tooling that identified and requested ownership of abandoned AUR entries.
Once in control, the attacker modified each PKGBUILD to add a post-install step executing npm install atomic-lockfile minimist chalk. When a user installed the package, their system fetched the malicious atomic-lockfile npm package and ran its preinstall script, which dropped and executed the “deps” binary. The alvr package—an OpenXR runtime for VR streaming that has no legitimate reason to use npm—was one confirmed example. According to Sonatype’s Atomic Arch analysis, any AUR package that recently added npm commands to non-npm software is a red flag worth investigating immediately.
Related: npm’s Phantom Gyp Worm Proves Signed Packages Aren’t Safe
What the AUR Malware Steals—and Where It Sends It
Binary analysis confirms a comprehensive credential harvesting operation. The “deps” payload targets browser and Electron app data (cookies, saved passwords, session tokens), GitHub credentials, npm and package manager auth tokens, HashiCorp Vault tokens, Docker and Podman authentication, SSH private keys, VPN configuration files, and full shell history. Slack, Discord, Microsoft Teams, and Telegram session data are also in scope.
Exfiltration happens over Tor, communicating with a .onion C2 address via multipart HTTP POST uploads—meaning data leaves your system quietly in the background. A developer’s compromised credentials become a second-order supply chain attack: stolen npm tokens can publish backdoored packages under your name; stolen GitHub tokens can inject code into your repositories before your team notices. The full scope of the Arch Linux AUR malware campaign is still being assessed by security researchers.
The eBPF Rootkit Makes Detection Harder Than Usual
Most AUR malware incidents are detectable with basic tools. This one is not—at least not on a root-compromised system. If the “deps” binary ran with root privileges, it deploys an eBPF rootkit that hooks getdents64(), the system call used to enumerate directory entries. The result: ps aux, ls, netstat, and lsof can all return incomplete output. The rootkit hides selected PIDs from /proc, conceals filenames from directory listings, and masks socket inodes from /proc/net/tcp. Anti-debugging hooks on PTRACE_ATTACH further complicate forensic analysis.
Sonatype’s recommendation is unambiguous: “Affected hosts should be treated as compromised. Removing the package alone may not be sufficient.” On a root-compromised system, do not trust your standard toolchain’s output. Specialized eBPF detection tools or a full system reinstall are the only reliable responses. For a technical breakdown of the rootkit internals, the preliminary malware analysis at ioctl.fail is the most detailed public resource available.
How to Check Your AUR Packages Now
The community is still compiling the complete list of 408 affected packages, but you can identify recently installed AUR packages and cross-reference against known-compromised names. To check which foreign (AUR) packages were recently installed or updated on your system:
pacman -Qqm | while read pkg; do
pacman -Qi "$pkg" | grep -E "^(Name|Install Date)" | paste - -
done | sort -k4Compare the install dates against June 11, 2026. Any AUR package installed or updated on or after that date warrants a full PKGBUILD diff review. If the PKGBUILD includes npm, pip, or cargo commands that have no clear relationship to the software’s function—that package is suspect. The Hacker News discussion thread contains community-maintained detection scripts and the evolving list of confirmed package names. If you find a match, do not just uninstall—rotate every credential on that machine: SSH keys, GitHub tokens, npm auth, Docker credentials, and anything stored in your shell history.
Key Takeaways
- 408 AUR packages were compromised on June 11; the “deps” malware targets developer credentials across SSH, GitHub, npm, Docker, Vault, browsers, and shell history
- The attack exploits AUR’s orphaned package adoption policy—a systemic weakness that enabled mass compromise with minimal effort from a single attacker
- An eBPF rootkit deploys when run as root, making standard tools like ps, ls, and netstat unreliable for detection on compromised systems
- Any AUR package that recently added npm commands to non-npm software is the key injection indicator to watch for
- Removing the package is not sufficient: treat affected systems as fully compromised, rotate all credentials, and consider a fresh install for root-compromised machines
