Skip to content
Hacker Posts

Fake Arch AUR packages impersonate yay and paru, run as root

An AUR account uploaded typosquatted yay/paru packages whose install scripts fetched and ran a remote shell as root; the AUR team banned the account on October 13.

Published 3 min read
breacharch-linuxsupply-chainmalware

A threat actor uploaded malicious packages to the Arch User Repository (AUR) that typosquatted two of the most-used AUR helpers, yay and paru, and whose install scripts pulled down and executed a remote shell script with root privileges. The campaign was flagged on October 13 through the Arch Linux aur-general mailing list, and the AUR team banned the account and removed the packages. Reporting is at BleepingComputer.

What the packages did

The AUR ships build recipes (PKGBUILD and .install scripts), not binaries — helpers like yay and paru run those recipes through makepkg, so a malicious install script runs on the user's machine at install time. The uploaded packages paired genuine upstream code with a booby-trapped install script, so the build looked normal while the script silently fetched a remote shell script and ran it as root.

Details confirmed across reporting:

  • The account was named marchos1as; one of the typosquatted package names was yyay.
  • The payload was fetched through a Wayback Machine URL pointing at a personal repository, hellscripter/install-scripts, hosted on the Russian service GitFlic.
  • AUR maintainer Andreas Reichel analyzed the package; alerts also came from Emiliano Gandini Outeda's open-source tool TrustSight.
  • An OSV advisory, MAL-2026-17242, tracks the same Wayback/GitFlic payload path.

A separate npm campaign reported by SafeDep as "DirtyBlanket" used a similarly named hellscripter/install-scripts repository on Codeberg. There is no confirmed link between the two operations.

Who is affected

Anyone who installed one of the typosquatted packages — not users of the legitimate yay or paru, which were not themselves compromised. Because the malicious script ran as root, an affected system should be treated as fully compromised, not merely as having a bad package installed.

What to do

  1. Check what you installed from the AUR since around October 13. Look for typosquats of common helpers (e.g., yyay) and anything whose .install script you did not read.
  2. If you installed a flagged package, assume root compromise. Rebuild the host rather than trying to clean it; rotate any credentials, SSH keys, and tokens that were on it.
  3. Read the PKGBUILD and .install before every AUR build. This is the AUR's security model — upstream vets nothing — and helpers that auto-confirm diffs defeat it.
  4. Prefer official-repo packages where one exists, and pin AUR helpers to show and pause on recipe changes.

Context

This is the latest in a run of AUR supply-chain abuse in 2026: a June wave that compromised on the order of 1,500 orphaned packages ("Atomic Arch"), and a July incident around Firefox-fork packages. Those earlier waves hijacked abandoned-but-trusted package names; this one is plain typosquatting of popular tools. The common thread is that the AUR is user-submitted by design — the repository curates nothing, and the only review step is the one the person running makepkg performs. That assumption is exactly what each of these campaigns monetizes.

Related stories