Attackers took more than 400 packages from the Arch User Repository (AUR) this week and rewrote their build scripts to install on any machine they own.
The malware is a Rust binary designed to harvest developer secrets. If it stays rooted, it can also load the eBPF rootkit to hide itself. The AUR is the public package repository for Arch Linux, and is separate from the official Arch repositories, which have not been affected.
If you installed or updated an AUR package on or after June 11, check it against the current list of affected packages before trusting the host. The list is large, growing, and not yet complete.
This attack follows a trust model, not a software bug. Vulnerable packages retain their names, their histories, and the trust that comes with them. Only the building instructions have changed.
The trap rests in the recipe, leaving the package itself exactly the same as the software users intended to install. There is no exploit, no zero-day, and no sign of Arch systems being breached.
Attackers accept dumped packages, edit build files, and allow users to work on them. Sonatype, who named the campaign Atomic Arch, found them after orphaned projects: packages whose keepers had left, leaving them open for anyone to take.
They also tampered with git metadata to make the changes look like they came from a long-time maintainer, an account called Arch Linux Trusted User that was later confirmed not to have been compromised.
Once the package is accepted, PKGBUILD or its .install script is programmed to run npm install atomic-lockfile during the build, pulling the malicious npm package alongside a few legitimate ones for cover. That package, atomic-lockfile@1.4.2, contains a preinstallation hook that uses a Linux ELF compiler called deps. Build the package, and run the binary.
Verified examples reported on the Arch mailing list include the alvr and premake-git packages.
What malware does
Independent researcher Whanos has engineered a deps load reverser and describes a Rust-proofing hacker intended for developer workstations and building systems. It collects:
- Cookies, tokens, and local storage from Chromium-based browsers (Chrome, Edge, Brave, and more)
- Time data from Electron applications, including Slack, Discord, and Microsoft Teams
- GitHub, npm, and HashiCorp Vault tokens, as well as OpenAI/ChatGPT bearers and account metadata
- SSH keys, known_hosts, and shell history
- Docker and Podman details and VPN profiles
Hacked files are exported via HTTP to temp.sh. Command and control works through the Tor onion service via a local loopback proxy.
For persistence, install the system service with Restart=always. With root it copies itself under /var/lib/ and writes the unit under /etc/systemd/system/; as a standard user it uses the home directory and the unit for each user under ~/.config/systemd/user/. Either way, it wants to come back.
Early documentation oversold the eBPF rootkit. It’s optional, and only loads when the binary already has root and the correct power. It is not used to gain rights. When activated, it hides the malware’s processes, processor names, and socket inodes from standard tools, uses pinned BPF maps named hidden_pids, hidden_names, hide_inode, and kills attempts to attach the debugger.
That changes the cleaning advice. Extracting the AUR package is not enough once the upload has started. A package manager can remove files it knows about. You can’t prove that a machine is clean after a paid rootkit has had a chance to infect it.
The binary also includes a second file attached to the monero-wallet-gui analysis that flags it as a possible cryptominer, which is not analyzed. An eBPF rootkit tied to a smash-and-grab hacker is rare, and that’s why this one is more important than hacking.
Broad, and the second wave
Sonatype’s initial documentation listed more than 20 captive packages. In one day, community trackers and the general Arch aur-general thread had cataloged more than 400, with one master list assembled by mirroring the AUR git, putting it at about 408, with the combined lists climbing upwards.
The atomic-lockfile npm package itself showed only 134 weekly downloads on Socket before it was deregistered, so the real exposure is the AUR build method rather than the npm installation.
The second wave used the js-digest install bundle, pushed from a separate set of community tracker accounts that link to the npm publisher as an atomic-lock file. Its payload is a different type of binary, ELF is different with its hash, which is also marked as malicious by the community.
How far this wave has spread is yet to be calculated. An early split listed a few packages, while a later grep-based search of the AUR mirror returned very high numbers that likely included churn as commits were removed. Either way, it’s not a first wave footnote, so check both atomic-lockfile and js-digest.
What you have to do now
Arch maintainers are halting malicious activity, banning accounts, and asking users to continue reporting suspect packages to the mailing list.
Treat the published affected package list as incomplete. Finally:
- Check any AUR package installed or updated on or after June 11 against a list of public packages and identifiers, comparing your external packages to the known bad set. Grep’s recent build history and repositories for npm install atomic-lockfile, bun install js-digest, and the src/hooks/deps path.
- If a flagged package is active, treat the host as vulnerable. Rotate everything you steal: browser sessions, SSH keys, GitHub and npm tokens, Slack, Groups and Discord sessions, Vault tokens, Docker and Podman credentials, and any cloud keys.
- Hunt for persistence. Check for unknown system resources (both system units and ~/.config/systemd/user/) and unexpected files under /var/lib/. Check /sys/fs/bpf/ for hidden_pids, hidden_names, and hidden_inodes maps. Review outgoing connections to Tor and load services.
- If the package works as root, assume a rootkit is present and restore it to trusted media. There is no way to trust the system otherwise.
- To go further, read PKGBUILD and any .include hooks before you build, especially packages that are recently received or run suddenly after a long hiatus. If you don’t understand the build instructions, don’t install the package.
For detection, the SHA-256 of the main payload is 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b; the full pointer set, including onion host C2, is in ioctl.fail analysis.
A similar detection trick hit the PDF viewer package that was released in 2018; version 2026 has recently increased it, part of a wider attack that hijacks orphaned projects to gain trust instead of typing to deceive users. The affected list is not exhaustive, and no CVE is given; Sonatype tracks the campaign as Sonatype-2026-003775 (CVSS 8.7).
The attack worked because the AUR still trusts the package name and history of who maintains it now. A newly received package, or one that just explodes new installation hooks, is now suspect as a package from a stranger.
