1,579 AUR Packages Were Taken Over Through the Adoption Process

On June 11, the aur-general mailing list started seeing reports of suspicious commits on AUR packages. By June 12 morning, Phoronix counted 400 compromised packages. By that evening, the number was 1,579.

The official Arch Linux advisory uses careful language:

We are currently experiencing a high volume of malicious package adoptions and updates in the Arch User Repository. — archlinux.org, June 12 2026

Adoptions. Not breaches. Not stolen credentials. The attackers used the AUR's published process for adopting orphaned packages, applied as legitimate new maintainers, and got handed the keys to packages that had real users.

How AUR adoption works

The AUR is a build-script repository. PKGBUILDs and .install files describe how to fetch and compile software. When a package's maintainer disappears, the package becomes "orphaned." Any AUR user can request adoption. There is no two-of-three. There is no proof-of-contribution. There is one click.

This is the right design for a volunteer-maintained software graveyard. It is the wrong design for a trust boundary. And it is the boundary every Arch user crosses when they type yay -S package-name.

What got injected

Sonatype's Security Research team tracked one strand of the campaign — "Atomic Arch" — and found the payload routed through an npm dependency added to the PKGBUILD. The AUR script pulled a poisoned npm package during install. Arch Linux machines started running JavaScript-delivered, rootkit-like malware out of a Linux distribution package manager.

The cross-ecosystem mechanic matters. AUR doesn't host the binary — the attacker only needed control of a trusted PKGBUILD and a tame-looking npm dependency. Two ecosystems, one trust path, no behavioral history check at either hop.

This isn't the first time

In July 2025, firefox-patch-bin and librewolf-fix-bin were pushed to the AUR by a fresh account and contained Chaos RAT. That incident hit a few packages. This one hit 1,579.

The structural lesson is the same in both. The AUR's defense model is "review the PKGBUILD before installing." The official advisory still says "review all PKGBUILD and install script changes." That's a useful instruction. It is also a confession that the trust model puts the work on the user.

The npm parallel

We have been writing about the npm side of this all month. 32 Red Hat packages with valid provenance. 57 packages using a 14-year-old binding.gyp execution path. 37 packages where the commit author signed as "claude". Different bypasses. Same shape.

Maintainer-identity-takeover doesn't care about the ecosystem. The mechanic is:

• A package accumulates trust through downloads and use.
• The trust attaches to the slug, not the human.
• A new human steps behind the slug — through adoption, account compromise, or social engineering.
• The trust transfers to the new human at zero cost.

npm calls this "compromised account." AUR calls it "adoption." Both are the same attack with different names.

What behavioral signals show

The attackers in the AUR incident were fresh accounts. No prior PKGBUILDs. No contribution history outside the adoptions they just made. No commits to upstream projects. No public identity attached to anything older than a week.

That signal is cheap to compute. It is the signal Commit scores npm and PyPI and Cargo packages on. Single publisher, short history, no behavioral track record outside the package itself — that's the structural fingerprint of every successful supply chain attack this year.

Incident	Ecosystem	Packages	Common fingerprint
Microsoft typosquats (May 31)	npm	14	Zero behavioral history
Red Hat Miasma (Jun 1)	npm	32	Compromised single publisher
Phantom Gyp (Jun 3)	npm	57	Compromised single publisher
IronWorm (Jun 6)	npm	37	Compromised single publisher
TrapDoor (Jun 6)	npm/PyPI/crates	34	Zero behavioral history
Atomic Arch (Jun 11–12)	AUR + npm	1,579	Fresh adopter, no AUR history

What this changes

Arch's response is the right tactical one. They froze adoption. They froze new accounts. They walked the commit graph and reverted what they could find. The advisory closes with "many (but not all)" of the affected packages.

The strategic problem is upstream of all that. As long as the trust model lets identity be transferred to a package — instead of letting identity be earned by a human — the defense is racing the attack, and the attack has every unmaintained package in the registry as ammunition.

Commit's bet is that the only signal an attacker can't fake in advance is the behavioral history of the human behind the artifact. Years of commits to other projects. Cross-ecosystem identity that resolves to the same person. Declarations are gameable. Behavior isn't.

Check your project

npx proof-of-commitment

Scores every dependency in your npm, pip, or Cargo lockfile against the same structural fingerprint that flagged the npm packages above. AUR PKGBUILDs are out of scope today — but if a PKGBUILD pulls an npm dependency that scores CRITICAL, you want to know that before the build script runs on your machine.