Attackers seized control of more than 400 packages in the Arch User Repository (AUR) this week and altered their build scripts to deploy a credential-stealing malware on any system that compiled them.
The malicious code is a Rust binary designed to harvest developer secrets. When executed with root privileges, it can also load an eBPF rootkit to conceal itself. The AUR is Arch Linux's community-driven package repository, distinct from the official Arch repositories, which remained unaffected.
If you installed or updated an AUR package on or after June 11, verify it against the current list of compromised packages before trusting the host. The list of names is extensive, still expanding, and not yet finalized.
This attack targets the trust model rather than a software vulnerability. The compromised packages retained their names, histories, and associated trust. Only the build instructions were modified.
The trap was embedded in the recipe, leaving the package itself appearing exactly as the software users intended to install. No exploit, zero-day, or indication that Arch's own systems were compromised was involved.
The attackers took over abandoned packages, edited the build files, and allowed users to execute the payload on their behalf. Sonatype, which dubbed the campaign Atomic Arch, discovered them targeting orphaned projects: packages whose maintainers had abandoned them, leaving them open for adoption by anyone.
They also forged git commit metadata to make the changes appear to originate from a long-standing maintainer, an account that an Arch Linux Trusted User later confirmed was never compromised.
Once a package was adopted, its PKGBUILD or .install script was modified to execute npm install atomic-lockfile during the build process, pulling the malicious npm package alongside a couple of legitimate ones for concealment. That package, atomic-lockfile@1.4.2, includes a preinstall hook that runs a bundled Linux ELF named deps. Building the package triggers the binary execution.
Confirmed examples reported to the Arch mailing list include the alvr and premake-git packages.
What the malware does
Independent researcher Whanos reverse-engineered the deps payload and describes it as a Rust credential stealer targeting 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, along with OpenAI/ChatGPT bearer material and account metadata - SSH keys, known_hosts, and shell histories - Docker and Podman credentials and VPN profiles
Stolen files are transmitted over HTTP to temp.sh. Command and control operates through a Tor onion service via a local loopback proxy.
For persistence, it installs a systemd service with Restart=always. With root access, it copies itself under /var/lib/ and writes a unit under /etc/systemd/system/; as a normal user, it uses the home directory and a per-user unit under ~/.config/systemd/user/. Either way, it aims to persist.
Early reports overemphasized the eBPF rootkit. It is optional and only loads when the binary already has root and the appropriate capability. 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 named hidden_pids, hidden_names, and hidden_inodes, and it prevents attempts to attach a debugger.
This changes the cleanup guidance. Removing the AUR package is insufficient once the payload has executed. A package manager can remove the files it recognizes. It cannot verify the machine is clean after a rootkit-capable payload has had a chance to run.
The binary also stages a second file associated with monero-wallet-gui that analysis flags as a possible, unanalyzed cryptominer. An eBPF rootkit combined with a smash-and-grab stealer is unusual, and it is why this incident warrants more than a dismissive response.
Scope, and a second wave
Sonatype's initial write-up counted more than 20 hijacked packages. Within a day, community trackers and the Arch aur-general thread had cataloged over 400, with one master list compiled by grepping the AUR git mirror, putting it around 408, and consolidated lists climbing higher.
The atomic-lockfile npm package itself showed only 134 weekly downloads on Socket before it was removed from the registry, so the real exposure is through the AUR build path rather than npm installs.
A second wave used bun install js-digest, pushed from a separate set of accounts that community trackers link to the same npm publisher as atomic-lockfile. Its payload is a different binary, a separate ELF by its hash, that the community also flagged as malicious.
How far this wave has spread is still being counted. Early breakdowns listed a few dozen packages, while later grep-based searches of the AUR mirror returned much higher numbers that may include churn as commits are removed. Either way, it is not a footnote to the first wave, so check for both atomic-lockfile and js-digest.
What to do now
Arch maintainers are resetting the malicious commits, banning the accounts, and asking users to continue reporting suspicious packages in the mailing-list thread.
Treat the published affected-package list as incomplete. On your end:
- Check any AUR package installed or updated on or after June 11 against the community package lists and detection scripts, which compare your foreign packages against the known-bad set. Grep recent build history and caches for npm install atomic-lockfile, bun install js-digest, and the payload path src/hooks/deps. - If a flagged package executed, treat the host as credential-compromised. Rotate everything the stealer touches: browser sessions, SSH keys, GitHub and npm tokens, Slack, Teams and Discord sessions, Vault tokens, Docker and Podman credentials, and any cloud keys. - Hunt for persistence. Check for unknown systemd services (both system units and ~/.config/systemd/user/) and unexpected files under /var/lib/. Inspect /sys/fs/bpf/ for the maps hidden_pids, hidden_names, and hidden_inodes. Review outbound connections to Tor and to upload services. - If the package ran as root, assume the rootkit is present and reinstall from trusted media. There is no way to trust the system otherwise.
Going forward, 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.
For detection, the main payload's SHA-256 is 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b; the full indicator set, including the onion C2 host, is in the ioctl.fail analysis.
The same adoption tactic hit an abandoned PDF-viewer package back in 2018; the 2026 version just scaled it up, part of a broader run of supply-chain attacks that hijack orphaned projects to inherit trust rather than typosquatting to trick users. The affected list is still incomplete, and no CVE has been assigned; Sonatype tracks the campaign as Sonatype-2026-003775 (CVSS 8.7).
The attack succeeded because the AUR still trusts a package's name and history over who is maintaining it now. A recently adopted package, or one that suddenly sprouts new install hooks, now deserves the same suspicion as a package from a stranger.