Arch disables AUR adoption: audit your orphaned deps

Arch Linux turned off package adoption in the AUR after attackers started claiming abandoned packages and quietly pushing malware into them. No exploit, no stolen credential, no typosquat. The feature worked exactly as designed: an orphaned package needs a new maintainer, and the attacker volunteered. If you run Linux dev machines, the thing to audit isn't your package versions — it's who owns your dependencies now.

What actually happened

Robin Candau, posting for the Arch DevOps team on the project mailing list on July 31, said adoption was disabled "due to the current influx of malicious package adoptions and follow-up commits made via the AUR," per BleepingComputer.

The campaign started around July 29 with openconnect-sso. Community reports cited by BleepingComputer put the eventual spread near 200 packages — that number is user-collected, not an Arch count, so treat it as a scale indicator rather than a fact. Named compromises include boringssl-git, icloudpd, windscribe-cli-v2-bin, stirling-pdf-desktop-bin, and pgadmin4-server.

The payload is where it gets specific to how you work now. A Rust second stage goes after browser credentials, password manager data, SSH keys, cloud and developer secrets, crypto wallets, messaging tokens — and AI service API keys. It takes remote commands over Tor and spreads laterally using the SSH credentials it just stole.

This is the second wave in two months. A June campaign hit over 400 AUR packages with rootkit and infostealer payloads.

Why orphaned dependencies matter for your business

We've written twice in the past week about supply-chain attacks that went after AI assistant credentials and about npm packages traced to a state actor. Those were code problems — a malicious version, a stolen publishing token. This one is a governance problem, and it's harder to see.

A package you reviewed in 2023 is not the package you're installing today if it changed hands in between. Your lockfile records a version. It doesn't record who has commit rights now. AUR is the sharpest case because adoption is open by design, but the same handoff happens on npm, PyPI, and every ecosystem where burned-out maintainers hand the keys to whoever asks nicely.

What to do this week:

• Inventory what came from AUR on every dev machine and build box. pacman -Qm lists foreign packages. Most teams have never looked.
• Check maintainer changes, not just versions. A new maintainer on a package you depend on is a review trigger.
• Read the PKGBUILD diff before upgrading. That's the entire security model of the AUR, and it always was.
• Rotate if you installed from AUR since July 29. SSH keys, cloud credentials, and every AI provider key on that machine. Those keys bill to you.

Passphrase your SSH keys and turn off agent forwarding while you're in there. The lateral movement step is the part that turns one laptop into your whole fleet.

Sources: BleepingComputer, SC Media.