More than 400 packages in the Arch User Repository were quietly altered so their build scripts would fetch and run a Rust credential stealer, a campaign Sonatype has named "Atomic Arch" and that community trackers placed at roughly 408 affected packages.
AUR trust model and how attackers abused abandoned packages
The attackers did not exploit a software bug in Arch itself. Instead they adopted orphaned packages, kept package names and histories intact, and edited PKGBUILD or .install hooks so that building the package executed malicious code. The Arch User Repository (AUR) is separate from the official Arch repositories, which were not affected. Sonatype and community trackers say the campaign targeted packages whose maintainers had walked away, and that the attackers spoofed git commit metadata to make changes look like they came from a long‑standing maintainer — an account an Arch Linux Trusted User later confirmed was never actually compromised.
What the malware does: a Rust stealer and an optional eBPF rootkit
Independent researcher Whanos reversed the main payload, a Rust binary designed to harvest developer secrets. The stealer collects cookies, tokens and local storage from Chromium‑based browsers; session data from Electron apps including Slack, Discord and Microsoft Teams; GitHub, npm and HashiCorp Vault tokens plus OpenAI/ChatGPT bearer material and related account metadata; SSH keys, known_hosts and shell histories; Docker and Podman credentials; and VPN profiles. Stolen files are uploaded over HTTP to temp.sh, while command‑and‑control traffic runs through a Tor onion service reached via a local loopback proxy.
For persistence the binary installs a systemd service with Restart=always. As root it copies itself under /var/lib/ and writes a unit under /etc/systemd/system/; as an unprivileged user it uses the home directory and a per‑user unit under ~/.config/systemd/user/. When run with root and with the right capability the malware can also load an eBPF rootkit that hides the stealer'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 kills attempts to attach a debugger. Analysts stress the eBPF component is optional and is not used to escalate privileges — but once present it substantially changes cleanup requirements.
Scale, the second wave, and notable indicators
Sonatype's initial writeup counted more than 20 hijacked packages; within a day greps of the AUR git mirror and community trackers found hundreds, with one master list around 408 entries and consolidated lists climbing higher. Confirmed affected packages reported to the Arch mailing list include alvr and premake‑git. The npm package used in the first wave was atomic‑lockfile@1.4.2; its preinstall hook runs a bundled Linux ELF named deps that functions as the stealer. atomic‑lockfile showed only 134 weekly downloads on Socket before it was pulled, underlining that exposure came through the AUR build path rather than npm downloads. A second wave fetched js‑digest using bun install and delivered a different ELF payload; community trackers link both npm packages to the same publisher.
Analysts published a detection hash for the main payload: SHA‑256 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b. The full indicator set, including the onion C2 host, is available in the ioctl.fail analysis. Sonatype tracks the campaign as Sonatype‑2026‑003775 (CVSS 8.7). No CVE has been assigned.
Practical detection and remediation steps for affected hosts
- Check any AUR package installed or updated on or after June 11 against community affected‑package lists and detection scripts. Grep build histories and caches for "npm install atomic-lockfile", "bun install js-digest", and the payload path "src/hooks/deps".
- If a flagged package ran, treat the host as credential‑compromised. Rotate browser sessions; SSH keys; GitHub, npm and Vault tokens; Slack, Teams and Discord sessions; Docker and Podman credentials; and any cloud keys the stealer could reach.
- Hunt for persistence: look for unknown systemd services (system units and ~/.config/systemd/user/) and unexpected files under /var/lib/. Inspect /sys/fs/bpf/ for maps named hidden_pids, hidden_names and hidden_inodes, and review outbound connections to Tor and to upload services such as temp.sh.
- If the package ran as root, assume the rootkit can be present and reinstall from trusted media; a package manager alone cannot prove the system is clean after a rootkit‑capable payload executed.
- Before building AUR packages going forward, read PKGBUILD and any .install hooks — especially for packages that were recently adopted or that have gone from long dormancy to sudden activity. If you do not understand a build script, do not build the package.
What this means for Arch maintainers, developers, and end users
Arch maintainers are resetting malicious commits, banning the offending accounts, and asking the community to keep reporting suspect packages to the aur‑general mailing list. Developers and build‑system operators should audit any build caches or runners used since June 11 and rotate secrets accessible from developer workstations and CI. End users who built or updated AUR packages in that window must check the public lists and detection scripts; if a malicious hook ran they should follow the remediation guidance above rather than assume simple removal is sufficient.
The campaign succeeds by inheriting trust, not by breaking archive security: the compromised packages kept their names and histories while only the build instructions changed. Community triage and careful review of build hooks are the immediate, practical defenses — and the full extent of the affected list is still being compiled.
