Arch Linux disables package adoption in the AUR after a wave of more than 200 malicious hijackings
The Linux world’s most popular community repository has had to pull the handbrake. The Arch Linux project has temporarily disabled package adoption in the AUR (Arch User Repository) after detecting an avalanche of malicious takeovers: attackers claiming orphaned packages —abandoned by their original maintainers— in order to slip a remote-access trojan that communicates over the Tor network into them. It is the second serious blow to the AUR in barely two months and it puts an uncomfortable question back on the table: to what extent can we trust the software we install with a simple command?
The notice was published by contributor Robin Candau on the aur-general mailing list: “Due to the current avalanche of malicious package adoptions and subsequent commits made through the AUR, package adoption is disabled while we manage the situation.” The measure is temporary, but with no return date. Meanwhile, the team asks the community to report any suspicious adoption or commit that remains unreviewed.
What the AUR is and why it is such a juicy target
The AUR is not an official repository of compiled packages, but a collection of build recipes (the PKGBUILD files) that the community itself uploads and maintains. When a user installs something from the AUR with a helper such as yay or paru, what they actually do is download that script and run it on their machine to compile the program. Therein lies the problem: a PKGBUILD is code that runs with the user’s permissions, and in many cases with installation privileges. There is no prior editorial review as there is in the distribution’s official repositories.
When a maintainer abandons a package, it is marked as “orphaned” and any registered account can adopt it. The attackers created new accounts, took over those ownerless packages and began publishing poisoned updates. According to community tracking, the campaign has already reached more than 200 packages, some with considerable pull: names such as openconnect-sso, boringssl-git, icloudpd, windscribe-cli-v2-bin, stirling-pdf-desktop-bin or pgadmin4-server are mentioned. The full list has not been published or independently verified, so it is best treated as a clue, not confirmation.
A two-phase trojan that avoids the labs
The technical analysis, spread by independent researchers and picked up by outlets such as BleepingComputer, Phoronix and LWN, describes a fairly polished two-stage infection. The first is a loader that, before doing anything, checks whether it is being observed: it looks for debuggers, sandboxed environments, virtual machines and even continuous-integration systems. If it detects it is in an analysis lab, it stays quiet. If not, it installs systemd services and cron jobs to survive reboots and launches a Tor client camouflaged under the name dbus-daemon to download the second phase from a .onion server.
The second stage is an information stealer written in Rust, and its shopping list is devastating: credentials saved in the browser, cryptocurrency wallets, password-manager databases, development and cloud-service secrets, API keys for artificial-intelligence services, SSH keys and tokens for messaging apps. It also opens an encrypted channel over Tor so the attacker can run commands remotely and —most worrying for professional environments— uses the stolen SSH keys to copy itself and run on other machines on the same network. In other words, it behaves like a worm inside the victim’s infrastructure.
The weak link is no longer the operating system
This incident is not a failure of Arch Linux or of Linux in general: it is an attack on the software supply chain, the same pattern we have seen over and over in npm, PyPI, browser extensions or GitHub repositories posing as legitimate projects. The attacker no longer looks for a kernel vulnerability; they look for an abandoned package with hundreds of users who update without looking. In June, another campaign had compromised more than 400 AUR packages to distribute a rootkit and an infostealer.
For anyone using Arch or derivatives, the recommendations are common sense but uncomfortable to follow: read the PKGBUILD before installing or updating —the helpers show it and almost nobody reads it—, distrust packages that have recently changed maintainer, review the commit history and, if an infection is suspected, immediately rotate SSH keys, tokens and saved passwords. And for companies, a broader lesson: any community repository that enters a development team should go through the same filter as an external vendor. The convenience of installing anything with a single command has a bill, and this time trust has paid it.
