Supply chain

On October 13, an Arch User Repository (AUR) account named marchos1as uploaded packages whose names were misspellings of yay and paru, two popular AUR helpers. One of them, yyay, shipped the real yay source code together with an install script that downloaded a shell script from the internet and ran it as root. The AUR team banned the account and deleted its packages within the hour, but anyone who mistyped a helper name in that window, or installed one of the packages since, should treat the machine as compromised.

This is the third malware wave on the AUR since June. Arch is a common choice for developer and administrator workstations, and those machines tend to hold SSH keys, cloud credentials and access to production. If your team runs Arch, or Arch-based distributions such as EndeavourOS or Manjaro with AUR access enabled, the checks below take a few minutes per machine.

How it works

An AUR package is a git repository holding a PKGBUILD, a bash file that tells makepkg where to download the source, how to build it and which files go into the package. makepkg refuses to run as root: build() runs as your user and package() runs under fakeroot, which only pretends to be root so file ownership comes out right. The finished package is then handed to pacman, which installs it with real root privileges. AUR helpers such as yay and paru automate that clone, build and install loop.

The PKGBUILD can also name an install scriptlet with install=<name>.install. makepkg copies that file into the package, and pacman runs it as root at install, upgrade and removal time. The documented hooks are functions such as pre_install, post_install and post_upgrade. Pacman sources the file in a shell to call them, so any command written outside a function runs every time the scriptlet is loaded.

The yyay package used exactly that. According to Andreas Reichel's scan on the aur-general mailing list, its PKGBUILD pointed at the same upstream URL and source tarball as the real yay, so the checksums passed and the build produced a working helper. The scriptlet's post_install and post_upgrade functions were empty, which looks harmless at a glance. The payload was a single top-level line that downloaded a script from a personal project on gitflic.ru, a Russian code hosting service, through a web.archive.org wrapper, and piped it into a shell. Nothing pinned or checksummed that script, so its author could change what it did at any time.

The Wayback Machine wrapper matters for defenders. A request to web.archive.org from a workstation looks routine to most proxies and DNS filters, while a direct fetch from a Russian code host might be blocked or flagged.

What attackers are doing

The first warning came from James Smith on aur-general at 19:51 on October 13 (times as shown in the list archive, UTC minus 7), in a thread titled "hundreds of aur packages were mass uploaded with malware". Reichel's scanner marked yyay 13.0.1 as malicious with 99% confidence twelve minutes later. Maintainer Emiliano Gandini Outeda reported that rules in his open source tool TrustSight had flagged the batch automatically. At 20:37, AUR maintainer DeepChirp confirmed the malicious install scripts, banned the user and deleted all of their packages.

No source has confirmed how many packages there were or how many people installed one, and the "hundreds" in the thread title has not been verified. Nobody has published what the downloaded script did either. A root shell script can install a backdoor, steal credentials or hide itself, so the response below assumes any of these happened.

BleepingComputer found that the payload path, hellscripter/install-scripts, matches a repository used by an npm campaign that SafeDep calls DirtyBlanket. OSV advisory MAL-2026-17242 for one of its packages, express-javascript, describes a Linux worm that installs a Tor-proxied systemd service named systemd-fontd, harvests SSH keys, spreads to known hosts and republishes npm and AUR packages. That campaign used Codeberg and the October AUR one used GitFlic, and no one has confirmed they are the same operation.

The earlier waves used a different way in. In June, attackers adopted orphaned AUR packages, which anyone may do, and changed their build files to pull in credential-stealing malware. Early reports counted more than 400 packages and later counts reached about 1,500, so sources differ. In July, another wave led Arch to suspend package adoption.

What to do

Check every Arch machine with AUR access, including build servers and CI runners.

1. List what came from outside the official repositories with pacman -Qm. Every AUR package shows up there. Look for any name that is one or two letters off a helper, such as yyay, and for anything you do not recognise.
2. Search the install history with grep -iE 'yyay|marchos' /var/log/pacman.log and read the installed and upgraded lines from October 13 onwards. Pacman also logs scriptlet output as ALPM-SCRIPTLET, so grep -C2 ALPM-SCRIPTLET /var/log/pacman.log shows which packages ran one.
3. Check the scriptlets of everything installed. Pacman keeps each one at /var/lib/pacman/local/<package>-<version>/install. grep -lE 'gitflic|web\.archive\.org|curl|wget' /var/lib/pacman/local/*/install lists any that fetch from the network. Very few legitimate scriptlets do, so read every hit.
4. Search your helper caches for the same strings: grep -rlE 'gitflic|hellscripter' ~/.cache/yay ~/.cache/paru/clone.
5. In proxy and DNS logs, look for gitflic.ru and for web.archive.org requests containing hellscripter.
6. Since the payload may match DirtyBlanket, run systemctl list-units --all | grep -i fontd and look for unexpected Tor processes or outbound SSH from the workstation to your other hosts.

If any check hits, removing the package is not enough, because the script ran as root and could have changed anything. Disconnect the machine, keep a disk image if you want to investigate, and reinstall from trusted media. From a clean device, rotate everything the machine could reach: SSH keys, and remove its public key from every authorized_keys file it was added to, along with GPG keys, browser-saved passwords, cloud CLI credentials, API tokens and anything in .env files.

For future AUR installs:

• Read the PKGBUILD and any .install file before building, and treat a scriptlet that downloads anything as malicious until proven otherwise. If your helper offers to show the build files or a diff before building, accept it every time.
• Check the package page on aur.archlinux.org before installing: the maintainer, when it was first submitted and its votes. A helper uploaded this week by a brand new account is not the one you meant.
• Install helpers once, by their exact names, and update them through the helper itself rather than searching for them again.
• On company machines, decide whether developers need the AUR at all. Where they do, keep a short approved list and watch pacman -Qm output in your endpoint inventory.

The wider lesson

An AUR helper clones repositories and builds them, so its safety depends on someone reading the files it builds. A mistyped name skips that judgement entirely, and the June wave showed that a package you trusted last month can change owner. Developer workstations deserve the same software inventory and egress monitoring as servers, because they hold the keys to the servers.

If you want to know which developer machines could run unreviewed packages with root and what they could reach, our safeguarding and hardening team can audit and lock down workstation package sources, and security operations can add the log and egress checks above to your monitoring. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: BleepingComputer: Fake Arch Linux packages push malware with root privileges, Help Net Security: Fake Arch Linux AUR packages exploit typos to run malware with root privileges, aur-general: first report by James Smith, aur-general: Andreas Reichel's scan of yyay, aur-general: DeepChirp bans the account, aur-general: Emiliano Gandini Outeda's TrustSight alerts, Secure Reading: Malicious AUR packages impersonate yay and paru, OSV MAL-2026-17242 (express-javascript), Phoronix: more than 400 AUR packages compromised, Linux Magazine: AUR hit again with malicious packages, PKGBUILD(5) manual, pacman(8) manual, makepkg(8) manual.