Attackers this week took over more than 400 packages in the Arch User Repository (AUR) and rewrote their build scripts to install a credential stealer on any machine that builds them.
The malware is a Rust binary designed to learn developer secrets. When it descends with root, it may also load an EBPF rootkit to disguise itself. AUR is Arch Linux’s community package archive, and is separate from the official Arch repositories, which were not affected.
If you installed or updated an AUR package on or after June 11th, check it against the current affected-packages lists before trusting the host. The list of names is large, still growing, and not yet complete.
This attack is based on the trust model, not on any software flaw. The compromised packages preserved their names, their history, and the trust that came with them. Only the manufacturing instructions changed.
The recipe was spoofed, making the package look exactly like the software users were supposed to install. No exploits, no zero-days, and no indication that Arch’s own systems were breached.
Attackers adopted abandoned packages, edited build files, and let users run payloads for them. Sonatype, which named the campaign Atomic Ark, found them going after orphan projects: packages that had lost their maintainers, leaving them open for anyone to adopt.
They also fudged the Git commit metadata to make the changes look like they came from a longtime maintainer, an account later confirmed by an Arch Linux Trusted user that had never been compromised.
Once the package was adopted, its PKGBUILD or .install script was edited to run npm installatomic-lockfile during the build, pulling the malicious npm package in with some legitimate packages for cover. That package, atomic-lockfile@1.4.2, contains a preinstall hook that runs a bundled Linux ELF called deps. Build the package, and the binary runs.
Confirmed examples reported on the Arch mailing list include the ALVR and premake-git packages.
what does malware do
Independent researcher Whannos reverse-engineered the DIPS payload and described a Rust credential stealer aimed at 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 apps including Slack, Discord, and Microsoft Teams
- GitHub, npm, and HashiCorp Vault tokens, as well as OpenAI/ChatGPT bearer content and account metadata
- SSH keys, known_hosts and shell history
- Docker and Podman credentials and VPN profiles
Stolen files are moved over HTTP to temp.sh. Command and control runs through the Tor Onion service via a local loopback proxy.
For persistence, it installs a systemd service with Restart=always. With root it copies itself under /var/lib/ and writes a unit under /etc/systemd/system/; As a normal user it uses the home directory and per-user unit under ~/.config/systemd/user/. Either way, it wants to come back.
Early articles oversold the eBPF rootkit. This is optional, and is only loaded if the binary already has root and the correct capabilities. It is not used to gain privileges. When activated, it hides the malware’s own processes, process names, and socket inodes from standard tools using pinned BPF maps called hidden_pids, hidden_names, and hidden_inodes, and it kills attempts to attach the debugger.
This changes the cleaning advice. Deleting the AUR package after the payload is running is not enough. A package manager can remove files it knows about. It cannot prove that the machine is clean once it has had a chance to execute a rootkit-enabled payload.
The binary also phases out a second file associated with monero-wallet-gui that the analysis flags as a potential, unanalyzed cryptominer. The EBPF rootkit mounted on a smash-and-grab stealer is unusual, and that’s why it’s worth more than a shrug.
scope, and second wave
Sonatype’s first article counted more than 20 hijacked packages. Within a day, community trackers and the arch-and-gen thread had listed over 400, with a master list compiled holding the AUR git mirror putting it at around 408, and consolidated lists climbing up.
The atomic-lockfile npm package showed only 134 weekly downloads on the socket before being removed from the registry, so the real exposure is the AUR build path rather than the npm install.
A second wave used bun install js-digest, pushed from a different set of accounts that community trackers link to the same npm publisher as atomic-lockfile. Its payload is a different binary, with a different ELF by its hash, which the community has also flagged as malicious.
How far this wave has spread is still being calculated. The initial breakdown listed a few dozen packages, while later grep-based searches of the AUR mirror returned much higher numbers that may include churn when commits are deleted. Either way, this is not a footnote of the first wave, so check both atomic-lockfile and js-digest.
What do we do now
Ark maintainers are resetting malicious commits, banning accounts, and asking users to keep reporting suspicious packages in the mailing-list thread.
Consider the published affected-packages list to be incomplete. From your side:
- Check any AUR packages installed or updated on or after June 11 against community package lists and detection scripts that compare your foreign packages against the known-bad set. Recent build history of grep and cache for npm install atomic-lockfile, bun install js-digest and payload path src/hooks/deps.
- If a flagged package runs, consider the host as credential-compromised. Shred everything the thief touches: browser sessions, SSH keys, GitHub and npm tokens, Slack, Teams and Discord sessions, Vault tokens, Docker and Podman credentials, and any cloud keys.
- Look for perseverance. Check for unknown systemd services (both on systemd and ~/.config/systemd/user/) and unexpected files under /var/lib/. Inspect /sys/fs/bpf/ for maps hidden_pids, hidden_names, and hidden_inodes. Review Tor’s outbound connections and upload services.
- If the package runs as root, assume the rootkit is present and reinstall from trusted media. Otherwise there is no way to trust the system.
- Moving forward, read the PKGBUILD and any .install hooks before building, especially for packages recently adopted or suddenly activated after long inactivity. If you do not understand the build instructions, do not install the package.
To find out, the SHA-256 of the main payload is 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b; The entire indicator set including the Onion C2 host is in the ioctl.fail analysis.
The same adoption strategy influenced an abandoned PDF-viewer package in 2018; The 2026 version has escalated this further, part of a broader wave of supply-chain attacks that hijack orphan projects to gain trust rather than typosquatte users to deceive them. The affected list is still incomplete, and no CVEs have been specified; Sonatype tracks the campaign as Sonatype-2026-003775 (CVSS 8.7).
The attack was effective because AUR still trusts the package name and history to determine who is now maintaining it. A recently adopted package, or one that suddenly sprouts new install hooks, now deserves the same suspicion as a stranger’s package.
