Atomic Arch: 400+ AUR Packages Hijacked Through Orphan Adoption

400+ AUR packages. One orphaned adoption flow.

On June 11, Sonatype researchers disclosed Atomic Arch: a supply chain campaign that compromised hundreds of AUR packages by exploiting a workflow designed for good-faith maintainer transitions. The AUR orphan adoption process lets anyone claim a package whose maintainer walked away. The package keeps its name, history, star count, and user trust. Only the build instructions change hands.

The attackers adopted 400+ orphaned packages, then modified each PKGBUILD to add a post-install script. When a user ran yay -S or paru -S , the build process silently fetched and installed a malicious npm package called atomic-lockfile from the public npm registry. The package looked legitimate: valid TypeScript source, proper directory structure, a real README. Its package.json contained a preinstall hook that executed a bundled Linux ELF binary.

Sonatype engineer Eyad Hasan flagged the campaign. The official Arch repositories ([core], [extra], [multilib]) were never affected — those have stricter review. This was entirely in the AUR, the community-run side of Arch. If you use AUR helpers, you were the target.

The npm package was a delivery vehicle. The ELF was the weapon.

The atomic-lockfile package (and a second package js-digest, also malicious) worked the same way. Inside package.json:

"preinstall": "./src/hooks/deps"

That deps file is a Linux ELF binary. npm executes it automatically during installation when lifecycle scripts are enabled (the default). The binary does not rely on any JavaScript. It is a native credential stealer compiled for Linux, bundled inside a TypeScript package destined for developer workstations.

Researchers at ioctl.fail reverse-engineered the ELF. It contains an encoded Tor onion service address for C2, uses SOCKS-based local loopback transport, and exfiltrates stolen data through HTTP POST to /api/agent on the hidden service in addition to uploading collected files to temp.sh.

eBPF rootkit. Credential sweep. No process visible.

The ELF bundles an eBPF program (scales.bpf.c) that hooks system calls related to directory listing. When active, ps, htop, and ls cannot see the malware's processes or files. The same mechanism detects debuggers and sandbox environments — if the binary spots analysis tools, it halts execution.

Once running, the payload sweeps the infected machine for:

GitHub credentials and SSH private keys (pivot to remote infra).

Browser credential stores — saved passwords, session cookies, autofill data from Chromium and Firefox.

System environment variables — API tokens, cloud credentials (AWS, GCP), and application secrets.

HashiCorp Vault tokens — direct access to vaulted secrets if the workstation has an active session.

Communication tool stores — Slack, Discord, Microsoft Teams, and Telegram session data.

Cryptocurrency wallet files and seed phrases from local wallet directories.

Every stolen credential, token, and file is uploaded to the attacker's infrastructure via the Tor C2 channel or dumped to temp.sh.

The AUR trust model was never designed for this.

The AUR orphan adoption process is a wiki-style handoff. Anyone with a GitHub account can claim an orphaned package. There is no identity verification, no code review of the PKGBUILD changes, and no automated scanning for outbound install-time behavior. The process trusts that the new maintainer acts in good faith.

Atomic Arch is what happens when that trust is treated as an attack surface. The attackers did not need to compromise any official infrastructure. They did not need to steal maintainer credentials or crack a build server. They just clicked "adopt" on the AUR, committed a modified PKGBUILD, and let yay and paru do the rest.

This is the same structural weakness as the GitHub Actions OIDC token theft we covered in the postinstall-hook-700-repos piece. Different platform, same root cause: a trust-based workflow with no verification step between intent and execution.

What the Arch team did, and what it did not fix.

The Arch Linux security team reverted the malicious PKGBUILD commits, banned the attacker accounts, and published a list of affected packages. The official repos were confirmed clean. Arch responded within hours of disclosure.

What that does not fix: any user who ran yay -Syu or paru -S between the compromise and the revert has a credential-stealing rootkit installed. pacman -R on the original package does not remove atomic-lockfile or the eBPF payload. They were side-loaded by the build process, not tracked by pacman. Reimaging is the only safe recovery path.

Check if you hit it.

If you run Arch and use AUR helpers, check whether you built any of the compromised packages during the campaign window. The full list is maintained in the Arch Linux advisory. Key indicators:

Your ~/.npm/ directory contains a .cache/ or _cacache/ entry for atomic-lockfile or js-digest.

A process named atomic-lockfile or deps runs on your system (though the eBPF hook will hide it from ps).

Outbound connections to a .onion address or to temp.sh originating from your development user.

Unknown SSH public keys in ~/.ssh/authorized_keys or new cron entries referencing hidden paths.

Audit this system for Atomic Arch compromise.

1. Check ~/.npm/ for any cache entries related to atomic-lockfile or js-digest.

2. Search for the binary at src/hooks/deps or any file named deps that is an ELF
   (file deps → ELF).

3. Check for eBPF programs currently loaded: sudo bpftool prog list.
   Flag any program with a name containing scales or bpf that was not
   loaded by a known security tool.

4. Review ~/.ssh/authorized_keys for keys you did not add.

5. Inspect cron and systemd user timers for unknown entries:
   systemctl --user list-timers --all, crontab -l.

6. Check outbound connections on loopback for SOCKS proxy activity:
   ss -tlnp | grep 127.0.0.1: and look for processes named atomic-lockfile
   or node running a SOCKS transport.

The move.

Do not run AUR helpers as root. This attack landed as your user, not root. That containment limited what the eBPF payload could see: only your user's processes, files, and credentials. Running AUR helpers as root would have handed over the entire system.

Review the packages you adopt, even briefly. The AUR orphan flow has no review gate. Before you run the first build on an adopted package (or any new AUR package), read the PKGBUILD. Look for curl, wget, npm install, or pip install calls that were not in the original. A one-line diff review takes thirty seconds and catches this entire attack class.

Use AUR helpers with sandbox builds. Tools like aurutils can build in containers or dedicated build users. yay and paru have --buildscript flags, but by default they run the PKGBUILD as your user. Treat any AUR build as untrusted code execution until you have read the build instructions.

The AUR is a community resource built on volunteer trust. Atomic Arch is the predictable result of scaling that trust without verification. Read the PKGBUILD before you run it. That is the entire fix.