Fake Arch Linux AUR packages run malware with root access

A threat actor has uploaded malicious packages to the Arch User Repository (AUR) that posed as yay and paru, two widely used helper tools. The packages ran a remote shell script with root privileges when installed.

The packages were detected on October 13. They were published by a user named "marchos1as" under typosquatted names that closely resembled the legitimate tools.

What the AUR is and why helpers matter

The AUR is a community-maintained package index for Arch Linux and distributions based on it. It does not host finished binaries. It hosts build scripts, known as PKGBUILDs, that users run to build and install software themselves. These scripts cover third-party and proprietary tools, beta releases, and older versions that are no longer available through the official distribution channels.

Tools such as yay and paru are known as AUR helpers. They make it easier to find and install user-contributed packages, so many Arch users install them early, often as one of the first things they add to a new system. This made them an attractive disguise for attackers.

Real code with a malicious install script

Users were alerted through a thread on the Arch Linux mailing list titled "hundreds of aur packages were mass uploaded with malware." Within minutes, community members had looked at the packages and confirmed what they contained.

The packages bundled the genuine upstream code, but added a malicious installation script. That script downloaded and ran a remote shell script with root privileges.

AUR maintainer Andreas Reichel described one of the packages in detail.

"The package presents itself as a straightforward repackaging of the legitimate 'yay' AUR helper (same upstream URL, same source tarball), but the package name 'yyay' and the malicious install scriptlet reveal it is a trojanised impersonation designed to blend in with the real package," Reichel warned.

Because the source URL and tarball matched the real project, a quick look at the build script would not have shown anything unusual. The malicious part sat in the install scriptlet, which runs during package installation.

Another maintainer, Emiliano Gandini Outeda, published a list of malicious packages that had triggered alerts on his own system. The detections came from rules in TrustSight, an open-source application security tool he develops.

The AUR team banned the marchos1as account and removed the malicious packages from the repository.

A payload routed through the Wayback Machine

According to Reichel, the payload was not fetched directly from an attacker server. Instead, the install script pulled it through a Wayback Machine URL. That URL pointed to a personal repository named hellscripter/install-scripts, hosted on GitFlic, a Russian code hosting service.

Using an archive service as an intermediate step lets attackers route traffic through a trusted domain, which may help the download look less suspicious.

A possible link to an npm worm

The repository name has appeared before. Application security company SafeDep recently documented an npm campaign it called "DirtyBlanket." That campaign fetched code from a repository with the same name, hellscripter/install-scripts, but hosted on Codeberg.

SafeDep researchers found a Linux worm in that activity. It deployed the CHAOS remote-access trojan disguised as a font service and also injected a loader into AUR packages.

An OSV advisory covering DirtyBlanket also lists the same Wayback Machine and GitFlic domain seen in the latest AUR uploads.

These overlaps are notable, but there is currently no confirmation that the two operations are connected.

Part of a series of AUR attacks

This is not the first time the AUR has been targeted this year. In June, 400 packages distributed credential-stealing malware with rootkit capabilities. Another campaign in July led the Arch team to temporarily disable package adoption, the process that lets users take over orphaned packages.

Arch users who installed any of the suspicious packages should assume their systems are compromised and take remediation steps right away. Since the malicious script ran as root, the attacker could have changed anything on the affected machine.

Our Take

This is the third AUR campaign in about four months, which suggests attackers now see the repository as a reliable entry point into Linux systems. The model that makes the AUR useful, with open uploads and user-built packages, also leaves screening largely to the community. In this case the community responded fast, but detection still depended on volunteers reading mailing list threads and running their own tools.

The choice of targets is telling. AUR helpers are installed early and trusted widely, and pairing genuine upstream code with a hidden install scriptlet is designed to pass a casual review. The same pattern of hiding malicious steps inside install scripts shows up in campaigns such as the MALFEX npm malware operation and in malicious GitHub repositories built to look legitimate.

For Arch users, the practical lesson is to check package names carefully and read install scripts, not only the source URLs. It is worth watching whether the suspected link to DirtyBlanket is confirmed, and whether the Arch team adds stricter controls on new uploads after this latest wave.