Here's a nightmare scenario for Arch Linux users. You install or update a package from the Arch User Repository, the community-driven collection that makes Arch so powerful. The package name is familiar. The maintainer history looks clean. You run the build.

Congratulations. You just executed a credential stealer on your own machine.

Attackers took over more than 400 packages in the AUR this week. They rewrote the build scripts to pull down malicious code during the installation process. The malware steals browser cookies, SSH keys, GitHub tokens, Discord sessions, and more. If it runs with root privileges, it can also load an eBPF rootkit to hide itself completely.

The official Arch repositories were not affected. This is an AUR-only problem. But for anyone who uses the AUR and millions of Arch users do this is a five-alarm fire.

No Bug, No Exploit, Just Broken Trust

The AUR credential stealer malware campaign is not a software vulnerability. There is no CVE. There is no patch. The attack worked because of how the AUR's trust model operates.

Here's what happened:
Attackers identified abandoned packages, projects whose maintainers had walked away. Anyone could adopt them. So the attackers did.
Once adopted, they edited the PKGBUILD (the build recipe) or the .install script. 

The changes looked legitimate. They even spoofed git commit metadata to make the edits appear to come from a long-standing maintainer. An Arch Linux Trusted User later confirmed that account was never compromised.

When a user built the compromised package, the build script ran npm install atomic-lockfile as part of the process. That npm package contained a preinstall hook that executed a bundled Linux ELF binary named deps.

Build the package. Run the malware. No further action required.

Which Packages Were Compromised?

The list is large, still growing, and not yet complete.
Sonatype, which named the campaign Atomic Arch, first counted more than 20 hijacked packages. Within a day, community trackers had cataloged over 400. One master list compiled by grepping the AUR git mirror landed around 408 packages. Consolidated lists have climbed higher.

Confirmed examples reported to the Arch mailing list include:
1. alvr
2. premake-git

A second wave used bun install js-digest, pushed from a separate set of accounts linked to the same npm publisher as atomic-lockfile. Its payload is a different malicious binary.
Check for both indicators.

What the Malware Does

Independent researcher Whanos reverse-engineered the deps payload. It is a Rust-based credential stealer aimed directly at developer workstations and build systems.

What it steals:
1. Cookies, tokens, and local storage from Chromium-based browsers (Chrome, Edge, Brave, and many more)
2. Session data from Electron apps including Slack, Discord, and Microsoft Teams
3. Token from GitHub, npm, and HashiCorp Vault
4. Metadata of the OpenAI and Chat GPT account, including any associated Bearer token
5. SSH Key; Known_hosts File(s); Shell History
6. Credentials for both Docker and Podman
7. VPN Profile

How it communicates with the malware: The files that were exfiltrated are sent via HTTP to a temp.sh web server. The malware receives commands using a Tor onion service along with a local loopback proxy, which lets the malware receive commands even if your network blocks direct connections to any of the Tor Services.

Persistence: The malware has created a systemd service with an associated Restart=always configuration option. If it has root privileges, it copies itself to /var/lib/ and writes a unit file to /etc/systemd/system/. As a normal user, it uses the home directory and a per-user unit in ~/.config/systemd/user/. Either way, it wants to survive reboots.

The eBPF Rootkit (Optional but Dangerous)

Early reports overstated the eBPF rootkit. It is optional, not automatic. It only loads when the binary already has root access and the appropriate capability. It does not help the malware gain privilege escalation.

But when it does activate, the rootkit hides:
1. The malware's own processes
2. Process names
3. Socket inodes

It uses pinned BPF maps named hidden_pids, hidden_names, and hidden_inodes. It also kills attempts to attach a debugger.

That changes the cleanup calculation. Removing the AUR package is not enough once the payload has run. A package manager can remove the files it knows about. It cannot prove the machine is clean after a rootkit-capable payload has executed.

The Possible Cryptominer

The binary also stages a second file tied to monero-wallet-gui. The analysis flags this as a possible, unanalyzed cryptominer. An eBPF rootkit bolted onto a smash-and-grab stealer is unusual. That is why this attack is worth more than a shrug.

Scope: Two Waves

Wave one: npm install atomic-lockfile. The npm package itself showed only 134 weekly downloads on Socket before it was pulled from the registry. The real exposure is the AUR build path, not direct npm installs.

Wave two: bun install js-digest. Pushed from separate accounts linked to the same npm publisher. Its payload is a different binary with a different hash. Early breakdowns listed a few dozen packages. Later grep-based searches returned much higher numbers.
Treat both waves as active threats.

What to Do Right Now

Arch maintainers are resetting malicious commits, banning the accounts, and asking users to keep reporting suspect packages.

On your end:

Check if you are affected.
Review any AUR package installed or updated on or after June 11. Compare against the community package lists and detection scripts. You need to search the latest build history and cache files for:
1. npm install atomic-lockfile
2. bun install js-digest
3. The payload path from src/hooks/deps

If you discover that a flagged package has executed, you must fully rotate your host device as if it has been breached, and take the following steps: 
1. Rotate your entire browser session (log out of all).
2. Rotate all of your SSH keys (generate a new one).
3. Rotate GitHub tokens and npm tokens.
4. Rotate your Slack, Teams and Discord session.
5. Rotate your Vault tokens.
6. Rotate your Docker and Podman credentials.
7. Rotate all cloud keys which may exist on the host.

Look for persistence and perform the following:
1. Search for unknown systemd services (including both system and user unit files).
2. Search for unknown files under /var/lib/ folder.
3. Examine /sys/fs/bpf/ for maps containing the hidden_pid, hidden_names and hidden_inodes.
4. Review the outbound connections to Tor and to upload service

If the package ran as root, reinstall.
Assume the rootkit is present. There is no way to trust the system otherwise. Reinstall from trusted media.

Going forward, read before you build.
Read the PKGBUILD and any .install hooks before you build, especially for packages recently adopted or suddenly active after long dormancy. If you do not understand the build instructions, do not install the package.

Detection Indicators

The main payload's SHA-256 hash:
6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b
The full indicator set, including the onion C2 host, is available in the ioctl.fail analysis.

History Repeats

The same adoption tactic hit an abandoned PDF-viewer package back in 2018. The 2026 version just scaled it up. This is part of a broader run of supply-chain attacks that hijack orphaned projects to inherit trust rather than typosquatting to trick users.

Sonatype tracks the campaign as Sonatype-2026-003775 with a CVSS score of 8.7. No CVE has been assigned.

The Bottom Line

The AUR credential stealer malware attack worked because the AUR still trusts a package's name and history over who is maintaining it right now.

A recently adopted package, or one that suddenly sprouts new install hooks, now deserves the same suspicion as a package from a stranger.

Check your builds. Rotate your credentials. And for the love of your SSH keys, read the PKGBUILD before you run it.

FAQ Section

What is the AUR credential stealer malware?

It's malicious code injected into AUR package build scripts that steals browser cookies, SSH keys, GitHub tokens, Discord sessions, and other credentials from developer workstations.

How many AUR packages were compromised?

More than 400 packages were hijacked in this campaign. The list is still growing and not yet complete.

How does the attack work?

Attackers adopted abandoned AUR packages, edited the PKGBUILD to run npm install atomic-lockfile (or bun install js-digest), and that npm package executed a credential-stealing binary during the build.

Does this affect the official Arch repositories?

No. Only the Arch User Repository (AUR) is affected. The official Arch Linux repositories were not compromised.

How do I know if I'm affected?

Check any AUR package installed or updated on or after June 11. Grep your build logs for atomic-lockfile or js-digest. Compare installed packages against community-compiled lists of known-bad packages.

How do I clean up if I ran a compromised package?

Rotate all credentials the stealer targets (browser sessions, SSH keys, tokens). Hunt for persistence (systemd services, files under /var/lib/). If the package ran as root, reinstall the operating system from trusted media.

Source: The Hacker News