What began as a troubling but seemingly contained breach has spiraled into one of the largest and most damaging attacks ever recorded against the Arch User Repository (AUR). The campaign, dubbed “Atomic Arch” by researchers at software supply chain firm Sonatype, has now compromised over 1,500 community-maintained packages — and just when maintainers thought they had it under control, a new, more sophisticated wave of obfuscated malware has been discovered.
How It Started: Hijacking Orphaned Packages
The attack was first identified on June 11, 2026, when Sonatype researcher Eyad Hasan flagged suspicious behavior in the AUR. The method was clever and deliberate. Attackers systematically sought out orphaned AUR packages — software projects abandoned by their original maintainers — and claimed ownership through the AUR’s own standard adoption process. Because an adopted package retains its original name and trusted history, users had no immediate reason to be suspicious.
Once in control, the threat actors modified the packages’ PKGBUILD scripts — the build instruction files that AUR helpers like yay and paru execute during installation. The malicious change was a post-install hook that silently ran:
npm install atomic-lockfile minimist chalk
That command pulled down a rogue npm package called atomic-lockfile, which carried a preinstall hook deploying a bundled Linux ELF binary named deps. The result: anyone who installed or updated an affected package unknowingly executed malware on their own system.
A Sophisticated Rust-Based Credential Stealer
Independent researcher Whanos reverse-engineered the deps payload and found it to be a stripped, Rust-compiled credential stealer built specifically for developer workstations and build environments. The malware searched aggressively for high-value data, including browser cookies, authentication tokens, and local storage databases from Chromium-based browsers such as Chrome, Brave, and Edge; session data from Electron applications including Slack, Discord, and Microsoft Teams; GitHub Personal Access Tokens, npm credentials, and HashiCorp Vault tokens; OpenAI and ChatGPT bearer tokens and account metadata; SSH keys, known hosts files, and shell history; and Docker and Podman authentication credentials.
Stolen data was exfiltrated in two ways — uploaded via HTTP to the file-sharing service temp.sh, and sent to a command-and-control server running as a Tor hidden service. When executed with root privileges, the malware could also deploy an eBPF rootkit capable of hiding processes, files, and network connections, making detection and cleanup significantly harder. Researchers also found references to /usr/bin/monero-wallet-gui within the binary, suggesting a potential cryptomining second stage was planned. Sonatype is tracking the campaign as Sonatype-2026-003775 with a CVSS score of 8.7.
Confirmed compromised packages in the initial wave included alvr and premake-git, among many others.
The Package Count Explodes
Early estimates from Sonatype put the number of affected packages at around 20. Community investigations quickly revised that figure upward — to over 400, then past 900, and ultimately to more than 1,500 packages as deeper audits were conducted. The attacker accounts involved in the first wave were identified as krisztinavarga, franziskaweber, tobiaswesterburg, ellenmyklebust, and arojas — the latter impersonating a legitimate existing maintainer.
Arch Linux maintainers responded swiftly once the issue was surfaced on the AUR mailing list, reverting malicious PKGBUILD commits, banning the offending accounts, and publishing a checklist of affected packages. Critically, Arch Linux’s official repositories — [core], [extra], and [multilib] — were confirmed to be entirely unaffected, as these are subject to far stricter review processes.
Wave Two: Switching to Bun to Evade Detection
On June 12, 2026, a second wave emerged. Rather than using npm, attackers switched to Bun — an alternative JavaScript runtime and package manager — to install a different malicious package called js-digest. Community trackers linked this second wave’s npm publisher account (herbsobering) to the same actor behind atomic-lockfile. The payload delivered was a different ELF binary with a distinct hash, but with the same credential-stealing and rootkit capabilities.
The tool switch was not accidental. Any detection rule written to flag npm install atomic-lockfile would not catch a Bun-based install command at all. Researchers also noted striking similarities to a separate npm campaign called IronWorm, which also deployed a Rust-based eBPF rootkit, exfiltrated data to temp.sh, and communicated with a Tor C2 on the same /api/agent path. Whether the two campaigns share the same operators has not yet been confirmed.
The Third Wave: Obfuscated Code Returns
By the night of June 13–14, 2026, a third, more elaborate wave was uncovered. Developer a821 first reported a new batch of affected packages — including various Node.js packages, a Plasma 6 applets package, Firefox packages, the Aura browser, LibreWolf extensions, and a NeoVim plugin — all containing malware hidden behind obfuscated code. Shortly after a821 reported back that those packages had been addressed, researcher Nicolas Boichat found yet more malicious packages using a local Gemma E2B AI model to scan PKGBUILDs.
One prominent example was ht-browser-bin, whose .install file contained a post-install function using hex escapes and mixed quoting to disguise the commands it ran. When decoded, the script changed directories to /tmp and used Bun to install two npm-style packages: ansi-colors and nextfile-js. The maintainer email on the package had been changed from its original address, consistent with the account takeover pattern seen throughout the campaign. While the obfuscation was relatively transparent to a careful reviewer, it was designed to slip past automated scanning tools.
The discovery led Boichat to advise: “If you installed or upgraded ht-browser-bin after this commit, you should treat your computer as potentially compromised.”
What You Should Do Right Now
The AUR team has asked users to pause AUR updates and report any additional suspicious packages. If you have installed or updated any AUR package on or after June 11, 2026, you should take the following steps immediately:
- Audit your AUR packages — Run
pacman -Qmto list all foreign packages installed on your system and cross-reference against the published list of compromised packages. - Check your logs — Inspect recent PKGBUILD history and pacman logs for any
atomic-lockfile,js-digest,lockfile-js, or Bun-based install commands. - Rotate all credentials immediately — This includes browser passwords, SSH keys, API tokens, CI/CD secrets, and any other credentials accessible from your machine. Assume anything stored was exfiltrated.
- Check for persistence — Look for unexpected systemd services, especially those configured with
Restart=always, which the malware used to maintain a foothold. - Consider a full reinstall — If you believe you may have been affected, security experts recommend treating the system as fully compromised and performing a clean OS reinstall.
A community-maintained detection script called AUR Vulnerability Test is available from the CachyOS community, and a text file listing all known affected packages is being kept current by the community for those who prefer to build their own checking scripts.
A Reckoning for the AUR’s Trust Model
The incident has sparked intense debate within the Linux community about the AUR’s long-standing trust model. Many users are calling for structural security changes, including mandatory review or automated scanning of PKGBUILDs before packages go live, LLM-assisted inspection tools for detecting suspicious install scripts, and stricter controls on the orphan package adoption process — the specific weakness that enabled this entire campaign.
Others argue that the AUR has always been a “use at your own risk” repository, and that the responsibility for reviewing PKGBUILD scripts before installation has always rested with the user. What is clear is that the scale of Atomic Arch — multiple coordinated waves, sophisticated Rust-written payloads, eBPF rootkits, and Tor-based C2 infrastructure — represents a level of organization that raises questions about whether this is a coordinated, possibly state-backed effort, or an opportunistic campaign stress-testing a known weak point in community Linux infrastructure.
Either way, the AUR’s reputation for being both powerful and risky has been put to its most severe test yet. Until further notice: stop using the AUR, inspect any system that has run AUR updates in the past 96 hours, and treat any affected machine as compromised.
Source: Phoronix, Hacker News
