Hackers seized more than 400 packages in the Arch Linux AUR this week and rewrote their build scripts to install a credential stealer on any machine that built them.
See also: CVE-2026-23111: A character in the Linux kernel allows root access
The malware is a Rust binary designed to collect developer secrets. When installed with root privileges, it can also load an eBPF rootkit to hide itself. The AUR is the Arch Linux and is separate from the official Arch repositories, which were not affected.
If you installed or updated an AUR package after June 11, check it against the current lists of affected packages before trusting the computer. The list of names is large, constantly growing, and not yet complete.
This attack targets the trust model, not a software bug. The compromised packages retained their names, history, and the trust that came with them. Only the build instructions changed. The trick was in the recipe, leaving the package looking exactly like the software users intended to install. No exploit, no zero-day, and no indication that Arch's systems themselves were compromised.
The attackers adopted abandoned packages, edited the build files, and let users execute the payload for them. Sonatype, which dubbed the campaign Atomic Arch, found them targeting orphaned projects: packages whose maintainers had retired, leaving them open for anyone to adopt.
They also tampered with the git commit metadata to make the changes appear to come from a long-time maintainer, an account that an Arch Linux later confirmed had not been compromised.
Once a package was adopted, its PKGBUILD or .install script was edited to run npm install atomic-lockfile during build, pulling in the malicious npm package along with some legitimate ones for cover. This package, atomic-lockfile@1.4.2 , contains a preinstall hook that runs a Linux ELF build named deps. Confirmed examples reported on the Arch mailing list include the alvr and premake-git packages.
See also: VerdantBamboo: New BSD variant of BRICKSTORM for Linux systems
Independent researcher Whanos analyzed the deps payload and describes a Rust credential stealer that targets developer workstations and build systems. It collects:
- Cookies, tokens, and local storage from Chromium-based browsers (Chrome, Edge, Brave, and many others)
- Session data from Electron applications, including Slack, Discord, and Microsoft Teams
- GitHub, npm, and HashiCorp Vault tokens, as well as OpenAI/ChatGPT account hardware and metadata – SSH keys, known_hosts, and shell histories
- Docker and Podman credentials and VPN profiles
The stolen files are sent via HTTP to temp.sh. Command and control is performed via a Tor onion service via a local loopback proxy.
For persistence, it installs a systemd service with Restart=always. As root, it copies itself to /var/lib/ and writes a unit to /etc/systemd/system/; as a normal user, it uses the home directory and a per-user unit in ~/.config/systemd/user/ .
Early reports have overestimated the eBPF rootkit. It is optional and is only loaded when the binary already has root privileges and the correct capability. It is not used to gain privileges. When enabled, it hides its own processes, process names, and socket inodes from standard tools, using pinned BPF maps named hidden_pids, hidden_names , and hidden_inodes, and kills attempts to connect a debugger.
This changes the cleanup advice. Removing the AUR package once the payload has been executed is not enough. A package manager can remove files it knows about. It cannot prove that the machine is clean after a rootkit-capable payload has had a chance to execute.
See also: CVE-2026-23111: A character in the Linux kernel allows root access
The binary also prepares a second file associated with monero-wallet-gui that the analysis flags as a possible, unanalyzed cryptominer. An eBPF rootkit attached to a smash-and-grab thief is unusual, and that's why this deserves more than a simple sigh.
