Arch Disabled AUR Package Adoption. October's Malware Wave Never Needed It.

On October 13 the aur-general mailing list got a thread with the understated title "hundreds of aur packages were mass uploaded with malware." The uploads came from a fresh account called marchos1as, and this time they were not hijacked projects. They were typosquats of yay and paru, the two helper tools Arch users type into a terminal without a second thought. One of them, yyay, carried the legitimate yay upstream URL and the identical source tarball. The malware lived in the .install scriptlet, and it was built to survive a glance: post_install and post_upgrade were deliberately emptied to a bare "true" so the file reads as a benign stub, while the payload sits at the top level, outside any function, so it runs unconditionally as root on every install and upgrade. That is not sloppy malware. That is a package written with a reviewer's eyeballs modeled in.

The fetch line pointed at a personal repo, hellscripter/install-scripts, wrapped in a web.archive.org URL, which is an unpleasant trick: the address looks like a citation, and blocking it means blocking the Internet Archive. This is the third AUR mess in four months. In June, more than 400 packages were compromised through orphaned adoptions and shipped an infostealer with an eBPF rootkit. In July, Arch temporarily disabled package adoption outright. The October campaign never touched adoption; it needed a new account and a package name one character off the real one. That is the uncomfortable part. The control Arch shipped answers the previous attack path, while the bottleneck has always been review, not publishing. The same plumbing shows up in npm. SafeDep documented nine packages published in 33 minutes by an account called dirtyblanket on September 29, each carrying a preinstall hook that pulls a second stage through a Wayback Machine mirror of that same hellscripter/install-scripts repo and drops a Linux worm: a CHAOS remote-access trojan disguised as a systemd font service, an SSH worm that walks known_hosts, and a step that injects the loader into any AUR package the stolen keys can push to. The OSV advisory for express-javascript describes the identical archive wrapper and repo. BleepingComputer is careful to note nobody has confirmed the two operations share an operator, and that caveat is fair, but shared infrastructure is doing the work regardless of who holds the leash.

Source article image
Source image 1

The practical version: if you run Arch and installed anything with a helper-shaped name in the last few days, treat the machine as compromised and rotate keys. More generally, "not on the affected list" is not a safety signal. The check that carries weight is whether a package has an .install or .hook file at all, and what executes at the top level of it before any function is even called. Arch's answer to supply-chain abuse keeps being to restrict who can publish. This campaign points at a cheaper win: making review mechanical, signed tags by default, hooks disabled unless declared, and a scanner sitting in front of every install the way TrustSight sat in front of the maintainers who caught this one. What would you actually put between a package and a root transaction?

Source article image
Source image 2

Sources

Comments

Popular posts from this blog

AI Is Starting to Feel Less Like a Gadget and More Like Infrastructure

When Two AI Bots Finally Learned to Talk in Discord

Enterprise AI Is Quietly Becoming a Systems Integration Problem