kief.dev
Security · · 4 min read

Atomic Arch: How the AUR Attack Actually Worked, and How to Lock Your System Down

Kief Studio
Atomic Arch: How the AUR Attack Actually Worked, and How to Lock Your System Down

If you run Arch, you already know the deal: the AUR is the best thing about the distro and the scariest. It is a giant pile of community build scripts that your helper happily executes on your machine. Most days that is fine. In June 2026 it very much was not.

This is the technical version — what the Atomic Arch campaign actually did, how to check whether you touched it, and how to stop being the person who runs the next one. No FUD, no "just don't use the AUR." If you depend on it, the move is to lock in your verification, not abandon the thing that makes Arch great.

The attack chain, end to end

Sonatype caught this one (campaign Atomic Arch, Sonatype-2026-003775, CVSS 8.7). Here's the chain, stage by stage.

1. Adoption, not intrusion. No accounts were popped. The AUR lets anyone request an orphaned package — one whose maintainer left. Attackers grabbed ownership of ~1,500 abandoned-but-still-installed packages across two waves (June 11–12). Reported names included guiscrcpy, netmon-git, inadyn-mt, nodejs-elm, keepassx2, alvr, and premake-git, among others. These had years of history and a clean reputation. That reputation is what got weaponized.

2. The PKGBUILD / .install edit. Once they owned a package, they edited the build recipe — PKGBUILD and/or its .install script — to pull a malicious npm dependency during the build:

# the kind of line that got slipped into build()/prepare()
npm install atomic-lockfile # later waves used bun

atomic-lockfile (and siblings js-digest, lockfile-js) shipped alongside a couple of legitimate packages for cover. Version atomic-lockfile@1.4.2 carried a preinstall hook that dropped and executed a bundled Linux ELF named deps.

3. The payload. deps is a Rust credential stealer. It goes straight for the good stuff:

  • ~/.ssh/ keys
  • browser sessions / cookies
  • GitHub and npm tokens
  • Slack and Discord data
  • HashiCorp Vault tokens
  • Docker/Podman and cloud credentials

…then exfiltrates over a Tor-connected C2.

4. Escalation. If it landed with root (or CAP_BPF), it loaded an eBPF rootkit that hides processes, files, and socket inodes, and set up persistence via systemd units (system and ~/.config/systemd/user/) with Restart=always. Community analysis also found cryptominer staging referencing /usr/bin/monero-wallet-gui.

The kicker: if one of these packages was already installed, you built and ran the payload on your next -Syu. The trust was inherited, not stolen.

Did you touch it? Hunt for the IOCs

Do this first. None of it needs the scanner — it's just good hygiene.

Check whether you have any flagged package installed:

# list your foreign (AUR) packages
pacman -Qm

# spot-check against reported names
pacman -Qm | grep -E 'guiscrcpy|netmon-git|inadyn-mt|nodejs-elm|keepassx2|alvr|premake-git'

Hunt for persistence:

# unexpected user-mode systemd services
systemctl --user list-unit-files --state=enabled
ls -la ~/.config/systemd/user/

# system-mode too
systemctl list-unit-files --state=enabled

# look for the eBPF rootkit's pinned maps
sudo ls -la /sys/fs/bpf/

# odd stuff under /var/lib
sudo ls -la /var/lib/

Check for the npm/bun indicators in any cached build:

grep -RskiE 'atomic-lockfile|js-digest|lockfile-js' ~/.cache/*aur* ~/.cache/yay ~/.cache/paru 2>/dev/null

There's also a community-maintained consolidator of IOCs worth a look: lenucksi/aur-malware-check.

If anything hits: treat the box as credential-compromised. Rotate everything the stealer targets — SSH keys, browser sessions, GitHub/npm tokens, Slack/Discord, Vault, Docker, cloud keys — from a known-clean machine. Then rebuild. Do not just pacman -Rns the package and move on; the payload already ran.

Scan before you build

Hunting after the fact is the bad timeline. The good timeline is reviewing the build script before makepkg ever runs it — which is exactly what Arch told everyone to do: "review all PKGBUILD and install script changes." The honest problem is that nobody reads every PKGBUILD on every update. So automate it.

That is what we maintain ks-aur-scanner for. It's free, open source, and built for precisely this threat model. Quick start:

# from the AUR (build it with the very scrutiny we're talking about)
git clone https://aur.archlinux.org/aur-scanner.git
cd aur-scanner && makepkg -si

# check a package BEFORE you install it (fetches + scans the exact bytes)
aur-scan check alvr

# scan a PKGBUILD directory you already have
aur-scan scan ~/.cache/yay/some-package

# make a scan failure a hard error (great for scripts/CI)
aur-scan scan --fail-on critical ~/.cache/yay/some-package

What it actually keys on — the patterns this campaign tripped:

  • npm/bun install inside build()/prepare() — network + arbitrary code at build time.
  • Network access inside build functions (curl, wget, package installers) where there should only be compilation.
  • Fetch-and-execute (curl ... | sh) and decode-then-run (base64/xxd piped into a shell), even split across lines.
  • .install hooks that do more than they should.
  • An IOC database (shipped in v2.0.0) that encodes this campaign's indicators directly, so a known-bad pattern is named, not just heuristically flagged.

Want it to gate every build automatically? Source the shell integration so your helper scans first:

# bash/zsh/fish/nu supported — wraps yay/paru/pikaur/trizen/pakku
echo 'source /usr/share/aur-scan/integration.bash' >> ~/.bashrc

Now yay -S whatever pre-scans the package and refuses to hand off to the helper if it trips the gate. There's also a fail-closed pacman hook for the belt-and-suspenders crowd, and a race-free aur-scan install mode that scans the exact bytes it then builds (no swap-after-scan window).

Keep it honest

A few things we will not pretend:

  • A scanner is not a force field. It catches the obvious-in-hindsight and automates the review you should already be doing. It does not read minds, and it deliberately does not follow remote code — if a build fetches a script from a URL, the scanner flags the opacity rather than executing it to "check." Unknown stays untrusted.
  • Static analysis has edges. We treat "can't analyze this" as a reason to warn, not a free pass, and we keep tightening the edges in the open. File issues; we read them.
  • Defense in depth wins. Scan before build, gate with the hook, keep your foreign-package list small, read diffs on maintainer changes, and have a rotation plan. No single layer carries the load.

The AUR is worth defending, not fleeing. Lock in the verification and keep using the best repo in Linux.

Tool: github.com/KiefStudioMA/ks-aur-scanner · Docs: aur-scanner.kief.studio · contributions and IOC submissions welcome.

More from us: the business-risk angle for teams, our CTO on the detection engineering behind the scanner, and our CEO on trust and open communities.

Sources: Arch Linux advisory · Sonatype: Atomic Arch · BleepingComputer

Security
← Back to blog