LONDON — When a developer on an Arch Linux machine ran a routine package update on June 11, they were not installing malware. They were installing a package they had used before, from a repository they trusted, maintained — apparently — by someone they had no reason to doubt. The build instructions looked normal. The package name had not changed. What had changed, invisibly, was who wrote those instructions.
That is the mechanism behind Atomic Arch, a supply chain campaign that has compromised more than 400 packages in the Arch User Repository — and, by updated estimates from Sonatype, potentially as many as 1,500 — since it was first detected on June 11, 2026. The malware it plants is a focused credential harvester: a Rust-written binary that targets SSH keys, browser sessions, GitHub and npm tokens, Slack and Discord data, HashiCorp Vault tokens, and cloud credentials, exfiltrating everything to a Tor-connected command-and-control server. On machines where it lands with root access, it can load an eBPF rootkit that hides its own processes from standard system tools.
The technical payload is almost secondary to what makes this campaign structurally distinct. Atomic Arch did not exploit a vulnerability in Arch Linux. It did not compromise a maintainer’s account. It exploited the AUR’s own process for transferring ownership of packages nobody is watching anymore — and that distinction matters more than the malware itself.
The AUR — Arch User Repository — is a community-maintained collection of build scripts for software not included in Arch’s official repositories. It is, by design, unvetted. Users are warned on the Arch wiki that packages have not been fully reviewed. That disclaimer has always been technically accurate. It has rarely mattered much in practice, because the AUR’s trust model ran on reputation: packages with long histories and familiar names felt safe, and for years, mostly were.
When a maintainer stops maintaining a package, it becomes orphaned. The AUR allows any community member to request ownership. The package keeps its name, its installation history, and the implied trust that comes from having been around for years. The new owner gets the ability to rewrite its build instructions — a file called PKGBUILD — and nobody who already has the package installed is necessarily going to notice that anything changed hands.
That is precisely what the attackers behind Atomic Arch exploited, according to Sonatype, which named the campaign and is tracking it as Sonatype-2026-003775 with a CVSS score of 8.7. Sonatype engineer Eyad Hasan first flagged the activity. Analysis confirmed the structure: adopt orphaned packages, modify their PKGBUILD files to add a post-install script, and have that script pull a malicious npm package — initially atomic-lockfile, then js-digest in a second wave — during the build process. The trusted package itself contains no malicious code. The malware arrives through a dependency the build process fetches silently.
Independent researcher Whanos reverse-engineered the payload — a Linux ELF binary called deps, bundled inside the atomic-lockfile npm package. It is a focused credential harvester designed specifically for developer workstations: the machines that tend to hold SSH keys to production servers, tokens that can publish packages to npm, API credentials for cloud infrastructure, and session cookies for the internal tools an engineering team relies on daily. Stolen files travel over HTTP to temp.sh; command and control runs through a Tor onion service via a local loopback proxy. The malware installs itself as a systemd service configured with automatic restart, surviving reboots even after the original package is removed.
The eBPF rootkit component attracted the most alarming early coverage, and a correction is worth making here: it is optional, not automatic. It only loads when the binary already has root access and the necessary Linux capability. It does not use eBPF to gain elevated privileges. When it does activate, BPF maps named hidden_pids, hidden_names, and hidden_inodes are pinned in the kernel, making the malware’s processes, file entries, and network sockets invisible to standard tools like ps and ss. The malware also kills attempts to attach a debugger. That changes the cleanup calculus significantly — a package manager removing the files it installed cannot prove the machine is clean after a rootkit-capable payload has had a chance to execute with elevated privileges.
Arch’s official guidance for affected users reflects that reality: if a flagged package ran, treat the host as compromised, rotate every credential the stealer could have reached — browser sessions, SSH keys, GitHub and npm tokens, Slack and Teams sessions, Vault tokens, Docker and Podman credentials, cloud access keys — and if the package ran as root, reinstall from trusted media. There is, as the Whanos analysis put it, no other way to trust the system.
The scope has proven difficult to pin down. Sonatype’s initial report covered more than 20 compromised packages. Within 24 hours, community tracking via the AUR git mirror and the aur-general mailing list pushed that number past 400. By June 12, Sonatype’s updated estimates placed the total potentially around 1,500 packages across multiple waves of activity, as a second set of accounts pushed js-digest using Bun rather than npm. Whether the second wave represents the same operators or a copycat exploiting the same adoption-process vulnerability is not yet established.
Arch maintainers are resetting malicious commits and banning the responsible accounts. Jonathan Grotelüschen, an Arch Linux package maintainer, posted to the aur-general list urging users to flag any suspect packages they encounter. A community-maintained detection script that checks installed foreign packages against the known-bad list is circulating via GitHub. No CVE has been assigned.
The campaign arrives in the middle of a sustained wave of supply chain attacks targeting developer infrastructure. The difference between Atomic Arch and most of them is instructive. Campaigns like the Shai-Hulud npm worm family, which has hit package registries repeatedly since late 2025, typically worked by compromising maintainer accounts or exploiting CI/CD credentials — attacks that required breaching something. Atomic Arch required nothing of the kind. It required patience and the ability to file a legitimate ownership request for a package nobody else was watching. That is a different category of threat, and it is why the AUR’s response — cleaning up the current wave — does not resolve the underlying structural problem.
A similar adoption-based attack hit an abandoned PDF-viewer package in the AUR in 2018. Atomic Arch is the 2026 version: scaled up, equipped with a sophisticated multi-stage payload, and timed during a period when developer workstations have become the primary target for campaigns aiming not just at individual machines but at the software those developers ship. What the AUR does next — whether it tightens the adoption process, adds monitoring for newly orphaned packages, or continues to rely on a warning label — is the question that remains open, and unanswered.
