AINEWS
Hundreds of AUR Packages Were Backdoored. The Real Story Is Who Wasn't Watching.
An attacker slipped a malicious npm package into orphaned AUR builds. The structural problem is not the malware. It is that nobody owns those packages anymore.
An attacker slipped a malicious npm package into orphaned AUR builds. The structural problem is not the malware. It is that nobody owns those packages anymore.
Hundreds of orphaned Arch Linux AUR packages were found backdoored this week, and the malware itself is almost the least interesting part of the story. The interesting part is who was supposed to be reviewing those packages, and what it means that the answer, in many cases, was nobody.
According to LWN, the attacker added a malicious npm package named "atomic-lockfile" to the build dependencies of orphaned AUR packages. Anyone who installed or updated one of those packages recently, typically through a helper like yay or paru, would have fetched the poisoned tarball at build time. The package can exfiltrate sensitive data from the build host, and because the vulnerable step is the build-time npm fetch rather than a prebuilt binary signed by Arch, this is a source-poisoning attack, not a binary-tampering one.
The incident is being worked on Arch's aur-general mailing list, where a report thread has accumulated 54 comments from 19 participants in roughly a day. As of Friday morning Pacific, however, archlinux.org/news has not promoted an advisory to top-level project news, which is itself worth flagging. Arch is responding, but on a developer list, not on the page users are most likely to check.
The AUR, the Arch User Repository, lets any logged-in user submit or edit a package's PKGBUILD. The system works because most packages have an active maintainer who reviews incoming changes and reverts bad ones. Orphaned packages do not. When a maintainer goes inactive, the package's revision history is effectively open to the next person who comes along with commit access, and the only barrier to landing a malicious change is whether anyone else happens to look. In a healthy distribution most of those orphans get picked up quickly. In a community the size of Arch's, the queue grows, and the gap widens.
That gap is what LWN's reporting describes, and it is the same gap that a community security researcher, sodiboo, also documented in a corroborating analysis. A practical list of affected packages has been compiled from the git log of commits that introduced "atomic-lockfile" across the orphaned repos, and is being maintained at gr.ht/aur_pkg_list.txt. The list is large enough that the empirical floor on affected packages is in the hundreds, per LWN's count, and possibly higher as the forensic log continues to grow.
Two things are worth holding in mind at the same time. First, this is not a freak event. AUR orphans have been a known structural concern for years, and the trust model that lets any contributor patch an unmaintained package is the same trust model that produced this incident. Second, calling the AUR broken would be the wrong frame. The repository has produced most of the software Arch users actually run, and the cost of mandatory review would be a real cost in contributor friction. The question is whether the existing mitigations are sized to the threat.
The most concrete near-term fix is faster orphan handling. When a maintainer goes silent, the package should move to a visible queue with a short adoption window before it is treated as effectively unowned. AUR helpers already surface orphan flags in their UIs; what is missing is a path that ties that flag to a deadline, and a default of disallowing external commit access once that deadline passes. None of that requires a redesign of the AUR. It requires the project to decide that "orphaned for a long time" is a security state, not just an aesthetic one.
The second fix is transitive-dependency visibility at the helper level. Most users do not read a PKGBUILD's makedepends line before they build a package, and they should not have to. If yay, paru, and their peers flagged a build that pulls a fresh, low-download, single-author npm tarball as a dependency, the kind of payload that just landed in the AUR would surface in the user's terminal before the build started. AUR helpers already check the integrity of the package source itself; extending that check to a coarse reputation signal on build-time dependencies is a small additional cost with a high payoff.
The third fix is upstream. LWN points out that "atomic-lockfile" resembles legitimate file-locking utilities in the npm ecosystem, which is exactly the kind of name a deliberate supply-chain camouflage would pick. There is no public evidence yet that the package was a typosquat rather than a fresh publication, and LWN does not claim one. The npm registry's own takedown state for the package, and its publish history, were not directly fetchable in time for this piece, which the LWN-cited npm package page does not change. The relevant point for now is that the npm package existed, propagated, and was treated as a normal dependency by every build that pulled it.
For users, the action list is the same one the aur-general thread has been repeating. Check the community list of affected packages against what you have installed or updated in the last week or two, downgrade or rebuild from a clean checkout for anything that matches, and rotate any secrets that lived on a build host that ran one of those packages. None of this is novel advice for a supply-chain incident, and that is part of the point. The AUR is one of the largest user-curated package sources in active use, and the playbook for surviving a compromise of it is the same playbook for surviving a compromise of any of them.
The question worth watching over the next week is whether archlinux.org/news adds a top-level advisory, and whether the AUR's existing orphan-adoption process moves visibly faster as a result. If it does, the incident will end up as a case study in how a community tightened the right screw. If it does not, it will be the next entry in a longer list.