Atomic Arch: How 1,500+ AUR Packages Got Weaponized Against You

If you've been running an Arch-based system and used paru or yay to install anything between June 9 and June 12, read this before you do anything else.

A supply chain attack hit the AUR this week. Researchers are calling it Atomic Arch. What started as a wave of roughly 400 compromised packages on June 11 expanded to over 1,500 within 24 hours as the attackers pivoted to a second delivery vector and as of yesterday, a new wave of more obfuscated malware is still being uncovered. The Arch security team has reverted what they can find and banned the attacker accounts, but if you installed any AUR packages since June 9, you need to check your system.

---

What Actually Happened

The AUR has a known weak point: orphaned packages. When a maintainer abandons a project, any user can claim it through the standard adoption process — no vetting, no waiting period beyond the basics. The attackers exploited exactly this. They claimed ownership of dozens of legitimately trusted, abandoned packages and then quietly modified the PKGBUILD scripts.

PKGBUILDs are just shell scripts. They define how a package gets downloaded, compiled, and installed. They run with your user's permissions at build time, and AUR helpers like paru and yay execute them without sandboxing. You've probably paru -S'd a hundred packages without reading a single one. So have I.

The modified PKGBUILDs fetched rogue npm packages during installation initially atomic-lockfile, then a second wave on June 12 added js-digest installed via the Bun runtime and later lockfile-js. By the time the community detection repo on GitHub had a full tally, the count was past 1,600 packages.

These acted as loaders, deploying a multi-stage payload that:

• Scraped browser credentials and session cookies from Chromium and Firefox profiles

• Harvested SSH private keys

• Swept environment variables for API tokens and cloud credentials

• Targeted cryptocurrency wallet files and seed phrases

Beyond the data theft, the malware included a rootkit component. It disguised its processes as legitimate kernel threads, making it invisible to ps, htop and anything else relying on procfs. You'd need rkhunter or proper forensic tooling to catch it.

The first report surfaced on the aur-general mailing list on June 11 whe someone noticed something off with the alvr package. From there the community pieced together the full scope fast.

---

Why This Attack Design Is Nasty

The part that gets me is how quickly it escalated. The first wave — ~408 packages, atomic-lockfile as the loader — was caught within a day. So the attackers immediately pivoted: second wave, new delivery mechanism (js-digest via Bun), more packages. The community was essentially playing whack-a-mole with an active campaign.

They didn't break anything. They didn't find a zero-day or exploit a vulnerability in pacman. They walked through an open door the community left unlocked — the orphaned package adoption process — and leveraged years of accumulated trust in packages users had already decided were safe. Nobody installs a package they've used for two years and scrutinizes the PKGBUILD each time. That's the attack surface.

Sonatype described the payload as targeted at developers specifically, not random consumers. And it shows. Browser passwords and SSH keys are nuisance-level data for most attackers. But SSH keys unlock infrastructure. Environment variables carry AWS access tokens, GitHub PATs, Kubernetes credentials. For anyone running a dev workstation on Arch — and a lot of us do — this isn't credential theft in the abstract; it's a potential foothold into entire organizations.

The eBPF rootkit capability is the other thing worth paying attention to. eBPF programs run in the kernel. A rootkit using eBPF hooks can intercept syscalls and hide processes at the source, before any userland tool sees them. It's the same mechanism defenders use for runtime security (Falco, Tetragon) turned against you. Detecting it requires either dedicated eBPF-aware tooling or booting from external media.

---

What You Should Do Now

Official repositories — [core], [extra], [multilib] — were not affected. This is AUR-specific.

Step 1: List your AUR packages.

bash

pacman -Qm

Cross-reference the output against the published list of compromised packages.

Step 2: If any flagged package was installed between June 9 and June 12, treat the system as compromised. That means:

• Rotate everything: browser passwords, SSH keys, API tokens, cloud access keys, any secrets stored in .env files

• Run rkhunter --check and chkrootkit to scan for rootkit artifacts, though note these may not catch eBPF-based hiding

• Review ~/.ssh/known_hosts and revoke/regenerate any keys that were present

Step 3: Audit how you handle AUR packages going forward.

bash

# Enable PKGBUILD review in paru before every build
# In /etc/paru.conf:
[options]
Review = true

With Review = true, paru will open the PKGBUILD for inspection before executing it. Tedious? Yes. But you should at least skim it — check for unusual network calls, anything invoking curl or wget piped to bash, or npm/pip installs buried in the build steps.

---

The Broader Pattern

This isn't the first time the AUR's trust model has been exploited, and it won't be the last. The repository's value comes from the same thing that makes it dangerous: it's open, anyone can publish, and the community maintains everything on a volunteer basis. That's a tradeoff Arch users accept when they use it.

But 2026 has been a rough year for supply chain security more broadly. The npm ecosystem gets hit constantly. GitHub Actions runners have been used as a vector. PyPI sees periodic malware campaigns. The attack surface isn't any single repository — it's the general assumption that open-source code, because it's public, is somehow safer to run without thinking.

It's not. Reading what you install is table stakes, not paranoia.

The Arch security team responded well once the compromise was surfaced. The community pieced it together quickly. But the detection happened through human observation on a mailing list, not automated scanning. That gap is worth thinking about.