Arch Linux AUR affected by malware aimed at stealing developer credentials.

      One of the largest open-source package repositories spent an entire weekend addressing the aftermath of a malware campaign that didn’t actually breach any systems. It didn’t need to.

      Attackers took over more than 1,500 packages in the Arch User Repository (AUR), which is a community-managed software collection alongside Arch Linux's official repositories, and quietly modified their build instructions to include a credential stealer on any machine that compiled them. By Monday, the project had made the uncommon decision to suspend new account registrations while they rectified the situation.

      The numbers kept changing. It began with approximately 400 packages, escalated to over 1,500 during the weekend, and one tracking list noted 1,579, which Arch itself referred to as “many, but not all” of the affected packages. Importantly, Arch’s core distribution and its official repositories were never compromised.

      This incident highlights an attack on trust rather than a security flaw. What is remarkable is the minimal hacking involved. The AUR is user-submitted and explicitly unsupported: Arch advises users to read a package's build file before installing it each time. There is no vetting process, by design.

      The attackers capitalized on this very aspect. They took control of “orphaned” packages—those whose maintainers had abandoned them—gaining access to their names, histories, and the trust that had been established. Security firm Sonatype, which labeled the campaign “Atomic Arch,” discovered that the attackers spoofed git commit data to make it appear as though the changes were from a long-standing maintainer.

      That account, later confirmed by an Arch Trusted User, was never actually compromised. Only the build recipe was modified. The altered scripts incorporated a malicious npm package called atomic-lockfile, whose install hook executed a hidden binary as soon as the package was built. The software appeared identical to what users intended to install, mirroring the same logic behind the Miasma worm that affected 73 Microsoft GitHub repositories: undermine trust rather than directly tamper with the code.

      The payload, a Rust binary reverse-engineered by researcher Whanos, was designed specifically to target developers. This is significant because the individuals who create AUR packages are the very ones whose machines contain the credentials for everything else.

      It collects browser cookies, session tokens, logins for Slack, Discord, and Microsoft Teams, GitHub and npm tokens, as well as HashiCorp Vault and OpenAI credentials, SSH keys, Docker logins, and VPN profiles, then exfiltrates this data via Tor.

      These credentials are exactly what could facilitate the next supply-chain attack, following a pattern seen with last year’s tainted VS Code extension that caused GitHub to lose thousands of repositories.

      Initial reports emphasized an eBPF “rootkit,” but that detail should be viewed with caution. As noted by The Hacker News, this component is optional and only activates if the malware already has root access, not as a means of initial infiltration. When it does execute, it hides the malware and obstructs debuggers, which is crucial because if a compromised package runs with root privileges on your machine, merely removing it isn’t sufficient; you must reinstall.

      This situation is not unfamiliar for Arch. A similar adoption strategy targeted an abandoned PDF viewer package back in 2018, and in 2025, the project endured both a two-week denial-of-service attack and a batch of compromised browser packages carrying a remote-access trojan.

      This incident is part of a broader trend for 2026. Attackers are increasingly seizing control of established, trusted projects that have been neglected instead of merely exploiting typographical errors in new projects—a tactic that now extends to AI coding agents directed at unfamiliar repositories. With around 13,000 orphaned packages still present in the AUR, the potential vulnerabilities are vast.

      Arch’s maintainers are reversing the malicious commits and banning the associated accounts, while their guidance to users remains the same: review the build script before compiling, and remain cautious with any recently adopted or suddenly active packages.

      The more complicated issue lies in the structural approach. A repository that prioritizes a package’s name and history over the current maintainer has no solution to this problem, only a choice about how long the open door remains ajar.