Arch's malware wave hit 1,500 AUR packages by climbing through orphans anyone can adopt
It started at 400 infected packages, passed 900 within hours, and ended above 1,500. The vector was malicious npm dependencies pulled into build scripts, and the open door was 15,000 unmaintained packages waiting to be claimed.
The official repos were never touched; this lived entirely in the AUR, Arch's explicitly unvetted, build-it-yourself user repository. An infosec consultant posted the exact pacman incantation to find foreign packages on your own box.
The fastest containment wasn't a patch. It was volunteers racing to adopt rarely-updated orphan packages so attackers couldn't, while others argued the AUR needs minimum package ages and adoption limits, like npm.
Not "Linux got hacked" — the AUR did
Phoronix reported the escalation in near real time, a count that kept moving as people read it. A commenter quoted the article's own arc:
"It was bad enough when finding out more than 400 AUR packages… had been infected with malware but now that number has risen to around 900 a few hours ago and now in the end at more than 1,500 user-contributed packages." — a reader who avoids the AUR and builds from source
The crucial scope: this is the Arch User Repository, a community free-for-all where users are warned to read every PKGBUILD before installing, not Arch's official, signed repositories. The infection rode in through malicious npm packages — atomic-lockfile, js-digest, lockfile-js — pulled in as build dependencies. Arch now says the incident is under control.
The incident-response command people actually needed
The most useful comment in the thread wasn't analysis, it was a runbook. An EU infosec consultant posted how to enumerate what you'd installed from outside the official repos and grep for the poisoned files:
"it seems it installed 'atomic-lockfile', 'js-digest' or 'lockfile-js' from npm… I ran the following command to find foreign packages… > pacman -Qmi" — an infosec consultant for EU banking and SMEs
The structural hole: 15,000 adoptable orphans
The reason 1,500 packages fell so fast is that the AUR is full of software whose maintainers have walked away — and anyone can pick up an orphan and push an update. The defense that worked was almost comically low-tech: claim the orphans first.
"There are 15k orphaned packages on AUR. I just adopted 3 rarely-updated ones this morning… If you're using an orphaned package, consider adopting it so the baddies can't." — the author of Beej's Guides and a CS instructor at Oregon State
The longer-term fixes people wanted are borrowed straight from the npm ecosystem that just bit them:
"I should be able to set a minimum package age just like I can with pnpm. Orphaned packages should not be adoptable by just anyone… Someone or something should vuln-scan these packages as they're published." — a software developer who called the response impressive but insufficient
Convenience was the attack surface
The AUR's whole appeal is that it makes installing anything one command away, and helper tools smooth over the "read the build script" step that was supposed to protect you. Bolt that convenience onto 15,000 packages nobody is watching, and you get a turnkey supply-chain attack that scales as fast as people can refresh the page. The patch here isn't a CVE fix. It's deciding whether an unvetted repository can keep pretending the warning label is enough.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
China's GLM 5.2 shipped open-weight the same hour Washington froze Fable, benchmarks not even ready
Z.ai released a frontier open-weight model without the usual benchmark post — because, commenters argue, it was rushed out to catch the wave of users suddenly locked out of Anthropic's Fable.