This Month, the Arch Linux community discovered that more than four hundred packages in the Arch User Repository had been quietly hijacked. The attackers did not exploit a bug in any software. They exploited something harder to patch: the trust that builds up around a package's name and history.
What happened
The Arch User Repository, commonly known as the AUR, is a community driven collection of build scripts maintained separately from Arch's official repositories. Anyone can adopt an abandoned package whose original maintainer has stopped updating it. That openness is exactly what this campaign relied on.
Researchers at Sonatype, who named the operation Atomic Arch, found that attackers were systematically adopting orphaned AUR packages, the ones whose maintainers had simply walked away. Once in control, they edited the PKGBUILD or install scripts to quietly run a command during the build process: npm install atomic-lockfile. That single line pulled in a malicious npm package alongside a couple of legitimate ones included for cover. The npm package carried a preinstall hook that dropped a bundled Linux binary named deps, and simply building the AUR package was enough to trigger it.
To make the changes look legitimate, the attackers also spoofed git commit metadata so it appeared the edits came from a long standing maintainer. An Arch Linux Trusted User later confirmed that maintainer's account had never actually been compromised. The packages kept their familiar names and commit histories. Only the build instructions underneath had changed.
What the malware actually does
Independent researcher Whanos reverse engineered the deps payload and identified it as a Rust based credential stealer built for developer machines and build systems. Once running, it can pull cookies, session tokens, and local storage from Chromium based browsers including Chrome, Edge, and Brave. It also lifts session data from Electron apps such as Slack, Discord, and Microsoft Teams. On top of that it harvests GitHub, npm, and HashiCorp Vault tokens, OpenAI and ChatGPT bearer credentials, SSH keys and known hosts files, shell history, Docker and Podman credentials, and VPN profiles.
The stolen data is exfiltrated over HTTP to the file sharing service temp.sh, while command and control traffic runs through a Tor onion service via a local loopback proxy. For persistence, the malware installs a systemd service set to restart automatically. If it landed with root access, it copies itself into /var/lib/ and installs a system level unit. Without root, it falls back to the user's home directory and a per user systemd unit.
There is also an optional eBPF rootkit component, though early reporting overstated its role. It does not grant any privilege escalation and only activates if the binary already has root and the right capability. When it does load, it uses pinned BPF maps to hide the malware's processes, names, and socket inodes from standard monitoring tools, and it actively blocks debugger attachment. A second, unanalyzed binary tied to a fake monero wallet GUI package was also found staged alongside the stealer, suspected to be a cryptominer.
This combination matters for remediation. A package manager can remove the files it installed, but it cannot prove a machine is clean once a rootkit capable payload has had the chance to run.
Scope and a second wave
Sonatype's initial report counted just over twenty compromised packages. Within a day, community trackers and the Arch mailing list had cataloged more than four hundred, with one list built by scanning the AUR git mirror directly landing around four hundred and eight, and later consolidated counts climbing even higher. Notably, the malicious atomic-lockfile npm package itself had only around one hundred and thirty four weekly downloads before it was pulled from the registry, meaning the AUR build process, not direct npm installation, was the real distribution channel.
A second, separate wave surfaced using the command bun install js-digest, traced to a different set of npm accounts that community researchers link to the same publisher behind atomic-lockfile. Its payload is a distinct binary by hash, also confirmed malicious. The full extent of this second wave is still being measured, since grep based searches of the AUR mirror return different totals depending on how much commit churn is included, but it is not a minor footnote to the first wave. Anyone checking their system should look for both atomic-lockfile and js-digest.
What to do if you use the AUR
Arch maintainers are resetting the malicious commits and banning the implicated accounts, and they are asking the community to keep reporting suspicious packages through the mailing list thread. For anyone who has built or updated an AUR package since June 11, the published list of affected packages should be treated as incomplete rather than authoritative.
Practical steps worth taking include checking recently built or updated AUR packages against community maintained detection lists and scripts, and searching build history and caches for references to npm install atomic-lockfile, bun install js-digest, or the payload path src/hooks/deps. If any flagged package was built on your system, the safest assumption is that the host is credential compromised. That means rotating browser sessions, SSH keys, GitHub and npm tokens, Slack, Teams, and Discord sessions, Vault tokens, Docker and Podman credentials, and any cloud access keys.
It is also worth hunting for persistence mechanisms directly, including unrecognized systemd services both at the system level and under a user's own systemd config directory, unexpected files under /var/lib/, and the presence of pinned BPF maps named hidden_pids, hidden_names, and hidden_inodes under /sys/fs/bpf/. Reviewing outbound network connections for Tor traffic or uploads to temp.sh is another useful signal. If a compromised package was built as root, the recommendation is to treat the rootkit as present and reinstall the system from trusted media, since there is no reliable way to confirm a clean state otherwise.
For detection purposes, the primary payload's SHA two fifty six hash is 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b, and a fuller set of indicators, including the onion command and control address, has been published in the ioctl.fail writeup.
The bigger lesson
This is not the first time an abandoned package has been weaponized this way. A similar tactic was used against an abandoned PDF viewer package back in 2018. What makes the 2026 version notable is the scale and the layered payload, combining credential theft with an optional kernel level hiding mechanism rather than relying on typosquatting or tricking users into installing the wrong thing entirely.
Sonatype is tracking the campaign as Sonatype 2026 003775 with a CVSS score of 8.7, though no CVE has been assigned since this is fundamentally a trust and process failure rather than a software vulnerability. The real takeaway for anyone using community package repositories is that a name and a commit history are not proof of safety. A package that has recently changed hands, or one that has suddenly become active again after long dormancy, deserves the same scrutiny you would give to software from a complete stranger. Reading the PKGBUILD and any install hooks before building is no longer optional diligence. It is the only line of defense the trust model has left.
Top comments (0)