Arch Linux AUR affected by malware aimed at developer credentials.

      One of the largest open-source package repositories recently spent a weekend addressing the aftermath of a malware campaign that did not involve any unauthorized access. The attackers managed to take control of over 1,500 packages in the Arch User Repository, or AUR, which is a community-managed collection of software that operates alongside the official repositories of Arch Linux. They subtly modified the build instructions for these packages to install a credential-stealing program on any machine that compiled them. By Monday, the project had temporarily halted new account registrations to facilitate the cleanup process.

      The count of affected packages kept changing. It began at around 400, soared past 1,500 over the weekend, and one tracking list identified 1,579, which Arch itself referred to as “many, but not all” of the targeted packages. Importantly, Arch’s core distribution and its official repositories remained unaffected.

      What makes this incident significant is the minimal amount of hacking that occurred. The AUR relies on user submissions and is explicitly unsupported; Arch advises users to review a package’s build file before installation every time. This lack of vetting is intentional.

      The attackers mostly exploited this lack of oversight. They took over "orphaned" packages—those whose maintainers had abandoned them—thereby inheriting their names, histories, and the trust those packages had established. Security firm Sonatype, which labeled the campaign “Atomic Arch,” discovered that the attackers were spoofing git commit data to make the changes appear as if they originated from a long-time maintainer.

      A trusted Arch user later confirmed that the associated account had never been compromised. Only the build instruction was altered. The modified scripts incorporated a harmful npm package called atomic-lockfile, whose installation hook executed a hidden binary as soon as the package was built. The software appeared identical to what users intended to install. This mirrors the strategy used by the Miasma worm that affected 73 Microsoft GitHub repositories: it aimed to compromise the trust rather than the code.

      The malware's payload consists of a Rust binary reverse-engineered by researcher Whanos, specifically designed to target developers. The individuals who create AUR packages are precisely those whose machines hold critical access credentials.

      This malware collects browser cookies and session tokens, logins from Slack, Discord, and Microsoft Teams, as well as GitHub, npm tokens, HashiCorp Vault, OpenAI credentials, SSH keys, Docker logins, and VPN profiles, then transmits this sensitive information over Tor.

      These credentials are the same ones that can facilitate the next supply-chain attack, akin to last year’s compromised VS Code extension that resulted in thousands of affected GitHub repositories. Initial reports emphasized an eBPF "rootkit," which requires clarification. As noted by The Hacker News, this aspect is optional, activates only if the malware already has root access, and is not used to gain entry. When it does operate, it conceals the malware and obstructs debuggers, which is crucial: if a compromised package has root access on your machine, simply removing it won’t suffice; you will need to reinstall.

      This situation is not new for Arch. A similar adoption tactic affected an abandoned PDF viewer package back in 2018, and in 2025, the project faced both a fortnight-long denial-of-service attack and a series of compromised browser packages bearing a remote-access trojan.

      Moreover, this incident reflects a wider trend expected in 2026. Attackers are increasingly taking control of orphaned, trusted projects as opposed to targeting new ones with typosquatting, a tactic that now threatens AI coding agents directed at unfamiliar repositories as well. With about 13,000 orphaned packages still in the AUR, the potential vulnerabilities are substantial.

      Arch's maintainers are resetting the malicious commits and banning the affected accounts, and the guidance for users remains the same: review the build script before building, and approach any recently adopted or suddenly active package with caution. The more challenging issue is structural. A repository that prioritizes a package's name and history over the current maintainer has no fix for this issue, only a choice about how much longer the open door remains open.