The Arch AUR Keeps Getting Hit With Malware, and the Fixes All Cost Something

If you run Arch Linux, you already know the AUR, the Arch User Repository. It is the reason people put up with Arch, a giant community library where anyone can publish a build recipe for software that is not in the official repos. That openness is the whole appeal, and it is also the problem, because anyone includes people uploading malware. Over roughly the last 15 months the AUR has been hit four separate times, and the most recent one, in October 2026, was the crudest and in some ways the most telling.

I want to walk through what happened, because the mechanism is simple enough to understand in a few minutes and it explains why this keeps happening. None of the fixes are free, and that is the uncomfortable part.

What an AUR package actually is, and why that matters

A package in the official Arch repos is built and signed by a trusted Arch maintainer. A package in the AUR is a text file called a PKGBUILD that some random person uploaded. When you install an AUR package with a helper like yay or paru, that helper downloads the PKGBUILD, runs the build steps on your machine, and installs the result. PKGBUILDs can also carry install scripts that run at install or upgrade time, and those scripts run as root, because installing software needs root.

Read that again, because it is the entire attack surface. You are downloading a script written by a stranger and running part of it as root on your own machine. The AUR has always told you to read the PKGBUILD before installing. Almost nobody does. That gap between what you are supposed to do and what you actually do is what every one of these attacks lives in.

The October 2026 wave, a plain old typosquat

On 13 October 2026, an account called marchos1as mass uploaded packages that impersonated popular AUR helpers. The mailing list thread that raised the alarm was titled, bluntly, hundreds of packages mass uploaded with malware. The names were typosquats of real tools, the clearest example being yyay, an extra y bolted onto yay, the single most used AUR helper there is.

Typosquatting is the oldest trick in the book. You register a name that is a near miss for a popular one and wait for people to fat finger it. PayPal has spent years buying up domains like paypa1 and paypai so that a mistyped address lands back on the real site. On the AUR this has not historically been a thing people worried about, which is exactly why it worked. Most of the fake names were nonsense like Hay, Yeah, and Yizzy, the kind of thing nobody would ever type by accident. The point was volume. Upload enough misspellings and a few people will eventually install one.

Here is what made it dangerous rather than just annoying. The fake yyay package presented itself as a straightforward repackaging of yay, same upstream URL, same source table, so a glance at it looked fine. The install script, yyay.install, is where the payload sat. The post install and post upgrade functions were deliberately left empty, filled with a harmless true, so an automated scanner or a casual reviewer skimming for the obvious hook spots would see nothing. The actual malicious line sat at the top level of the script file, outside any function, which means it runs unconditionally as root on every install and upgrade.

That line piped a remote shell script straight into a shell. It pulled a file called linux.sh from a personal project on gitflic.ru, a Russian code host with no connection to the real yay project, and it wrapped the URL in a web.archive.org link that did not pin a snapshot timestamp. No pinned timestamp means the content served could change at any time, and there was no checksum on the fetch, so whoever controlled that script could swap the payload for credential theft one day and a rootkit the next. You would never know which one you got.

There is a thread worth pulling here. The repository the script pointed at, named something like hellscripter and install-scripts, matches the setup used in a separate npm campaign that researchers tracked under the name DirtyBlanket, which pulled code from a similar hellscripter repository and deployed the CHAOS remote access trojan. Nobody has confirmed the two operations are the same crew, and I am not going to claim they are. What the overlap tells you is that these AUR attacks are not isolated pranks, they sit inside a wider pattern of people planting the same kind of install time payloads across multiple package ecosystems.

Figure 1. How the fake yyay package hid its payload. The install hooks were emptied with true so scanners saw nothing, while the real command sat at the top level of the script and ran as root, piping a remote linux.sh from a Russian host straight into a shell with no checksum and no pinned version. Source: Author diagram based on the published malware scan

The one genuinely good part, it got caught fast

Credit where it is due. Less than an hour after the report hit the mailing list, an Arch maintainer confirmed the malicious payloads, banned the marchos1as account, and deleted every package it had uploaded. A maintainer running a detection tool called TrustSight helped flag the bad packages. So the live window was short, and most of the nonsense names almost certainly never got installed by anyone, since you need to get at least the first few characters of a command right before a typo even becomes plausible.

That is the good news and it is real. The bad news is that fast cleanup is a treadmill, not a fix. The account got malware onto the AUR during a period when the project had already locked things down because of earlier attacks, which tells you the lockdown is porous.

This was the fourth wave, not the first

The October typosquat did not come out of nowhere. The AUR has been a repeat target.

In July 2025, a user called danikpapas uploaded three packages named firefox-patch-bin, librewolf-fix-bin, and zen-browser-patched-bin. They looked like browser fixes. They installed CHAOS RAT, a remote access trojan that hands an attacker control of the machine. They went up on 16 July and were removed on 18 July, so they were live for about 2 days.

In the week of 12 June 2026, the attack was far more sophisticated, and it is worth sitting with because it shows how bad this can get. Attackers adopted orphaned AUR packages, ones whose maintainers had walked away, then edited the PKGBUILD or .install scripts so that building the package quietly ran npm install atomic-lockfile, with a couple of real npm packages alongside it for cover. They even forged the git commit metadata so the changes looked like they came from the long standing maintainers, though an Arch Trusted User confirmed those accounts were not actually compromised. A community count using grep reached about 408 affected packages, and the list was described as still growing and incomplete.

The payload was nasty. The atomic-lockfile npm package carried a preinstall hook that ran a bundled Linux binary, a Rust credential stealer aimed squarely at developer machines. It went after cookies, tokens, and local storage from Chromium browsers, logged in sessions from Electron apps like Slack, Discord, and Teams, GitHub and npm and HashiCorp Vault tokens, OpenAI bearer material, SSH keys and known_hosts, shell history, Docker and Podman credentials, and VPN profiles. It shipped the loot to temp.sh over plain HTTP and ran its command and control over Tor. If the binary already had root, it could load an optional eBPF rootkit that hid its own processes and sockets and blocked debuggers, and it even staged a file tied to monero-wallet-gui that looked like an unanalyzed cryptominer. Anyone who installed or updated an affected package on or after 11 June should assume those secrets are gone.

In late July 2026, another wave pushed Arch to suspend package adoption, the exact mechanism that let the June attackers grab orphaned packages, and within days the project halted new AUR uploads and account registrations entirely. If you go to the AUR register page today, you still hit a notice that new account registration is temporarily closed. That lockdown has held for more than a month, and it is the backdrop to the October incident, because marchos1as managed to upload malware anyway, which means the account already existed before the freeze.

Figure 2. Four AUR malware waves in about 15 months, from the July 2025 CHAOS RAT browser packages to the June 2026 takeover of more than 400 orphaned packages with a Rust infostealer, the July 2026 upload freeze, and the October 2026 typosquatting run. Source: Author timeline based on Arch mailing list reports and security coverage

The sleeper account problem nobody wants to talk about

The October wave points at something uncomfortable. Registrations were closed. Uploads were supposedly restricted. The account still pushed malware onto the AUR. That lines up with a worry that was raised during the earlier waves, that there are dormant accounts sitting on the AUR, created before the freeze, that have done nothing yet and are waiting. Closing the front door does nothing about the people already inside the house.

I have no way to confirm how many such accounts exist, and I would not trust anyone who claims a precise number. What I can say is that the pattern fits. An account that predates a registration freeze, surfacing mid lockdown to dump hundreds of typosquats, is exactly what a sleeper account would look like. The motive, based on what has been reported from people claiming involvement in these campaigns, is not some grand cause. It is that they can. When the only thing standing between an attacker and a root shell on your machine is whether you bothered to read a text file, and the payoff is real, someone will keep trying.

The other weird thing happening on the mailing list

Running alongside the malware is a smaller, stranger problem that points in the same direction. The AUR general mailing list has been getting waves of near identical emails that just say leave, or I’d like to unsubscribe from this mailing list, often several on the same day and then nothing. The sender posts once and vanishes, never replies, never explains. Leaving the list is trivial, you email a dedicated address, aur-general-leave at the list domain, so a human who wanted out would manage it. Dozens of people suddenly unable to figure that out, in a month where it almost never happened before, does not read like dozens of confused humans.

The likely explanation is AI agents. Automated agents subscribed to the list and now cannot work out how to unsubscribe, so they keep firing the same request into the void. One of them even threatened to report Arch Linux to Hetzner, the hosting provider, for sending unsolicited spam, which, if Hetzner took it seriously, could get Arch’s mail relay port throttled while they investigated, a real headache from a complaint that makes no sense. It is low stakes on its own, maybe 20 emails over a month, annoying rather than damaging. It matters because it is the same root cause as the malware, automated accounts interacting with the AUR’s open infrastructure faster than humans can reason about them, and nobody being quite sure which messages are bots and which are people.

Why the obvious fix breaks the thing you are trying to fix

So how do you stop this? The clean answer is to treat the AUR like the official repos. The official Arch repos almost never ship malware, because only a small set of trusted maintainers can put packages in them, and everything is reviewed and signed. Debian works the same way. Lock the AUR down to verified contributors, review submissions, sign the results, and the typosquatting problem mostly evaporates.

Except that destroys the AUR. The entire reason the AUR exists is that anyone can publish anything without waiting for a gatekeeper. The moment you add trusted maintainers and a review queue, you have built a second set of official repos, slower and smaller, and the open community library that made Arch worth using is gone. You would have solved the malware problem by deleting the feature.

Figure 3. The tradeoff behind every proposed fix. Official repos are safe because they are closed and reviewed. The AUR is useful because it is open to anyone, which is also why it keeps getting hit. Locking it down would stop the malware and stop it being the AUR. Source: Author diagram

The realistic options are all compromises. Keep registrations locked and reopen them one verified request at a time, which is slow and manual and does not touch the sleeper accounts. Add automated scanning of PKGBUILDs, which the October attack was specifically built to evade by hiding the payload outside the functions scanners check. Lean on third party detection tools like the TrustSight scanner maintainers have started running, which help but arrive after upload. Or shift the burden back onto users and actually get people to read PKGBUILDs before installing, which is the official advice and has never worked at scale because convenience always wins.

None of these is a solution. They are all ways of making the attack a little harder or a little slower while keeping the AUR open enough to still be the AUR. That tension does not resolve. As long as the AUR lets strangers publish code that runs as root on your machine, and as long as most people install without reading, the AUR will keep getting hit, and the response will keep being fast cleanup rather than prevention.

If you use the AUR, the practical takeaway is small and boring and worth doing anyway. Read the PKGBUILD and the .install file before you install, every time, especially for anything you typed quickly. Check that the package name is spelled exactly right. Be suspicious of any package that fetches a script from a host that has nothing to do with the real project. You can check what is installed with pacman -Qs and remove something with sudo pacman -Rns, though if you ran a root payload, removing the package does not undo what it already did, and a clean reinstall from backup is the safer call.