AUR Supply-Chain Compromise (Atomic Arch, 400+ Packages), Check pacman -Qm, Rotate Credentials, Reinstall if a Rootkit Landed

Beginning around June 11, 2026, an attacker mass-adopted more than 400 orphaned packages in the Arch User Repository (AUR) and edited their PKGBUILD / .install files to run a malicious post-install hook. The hook pulls a rogue npm package (atomic-lockfile; a later, separately reported wave used js-digest via Bun) whose bundled native Linux binary is both a credential infostealer and an eBPF rootkit that hides its own processes, files, and network connections. Because the AUR .install hook executes under pacman as root, the rootkit path can run with kernel-level privilege on any host that installed or rebuilt an affected package during the window. Sonatype, which named the campaign "Atomic Arch," tracks it as Sonatype-2026-003775 (CVSS 8.7); there is no CVE. The official Arch [core]/[extra] repositories are not affected, only the user-contributed AUR. Arch staff removed the malicious commits around 17:30 UTC on June 12 and banned the accounts, but if any of your machines pulled an affected AUR package in the window, the most urgent actions are: confirm which packages, rotate every credential the host could reach, and plan to reinstall, because an eBPF rootkit can survive ordinary cleanup.

Framing note: this is a compromise of a community package repository, not a vulnerability in Arch Linux, pacman, or any single application, and there is no CVE or vendor patch to apply. The affected population is "machines that installed or updated an AUR package via an AUR helper (yay, paru, aurutils, or manual makepkg -si) during the June 11 to 12 window," which in practice includes Arch and Arch-derived distributions (CachyOS, EndeavourOS, Manjaro, and similar) that consume the AUR. The IOCs below come from community incident tracking and named-research analysis; where a hash or a count is sourced from secondary reporting rather than a single primary advisory, that is flagged inline.

Priorities, by environment

Triage hinges on one question: did this host install or rebuild an AUR package via an AUR helper or makepkg during the June 11 to 12 window? Pulling official-repo updates with pacman -Syu alone does not expose you. The affected population is AUR users specifically.

Categorization source: Bulletin's framing, based on the campaign's root-level execution path and the infostealer's documented credential targets. It is not an Arch-issued or Sonatype-issued priority schema.

Am I affected?

Step 1: Did you install or rebuild an AUR package in the window?

List foreign (AUR) packages, then check the pacman log for installs or upgrades on June 11 to 12:

pacman -Qm

grep -E '^\[2026-06-1[12]T.*\] \[ALPM\] (installed|upgraded|reinstalled) ' /var/log/pacman.log

The reinstalled action matters here: an AUR rebuild of an already-present package logs as a reinstall, not an upgrade. Note this lists all pacman transactions, not AUR ones specifically, so cross-reference any package it names against your pacman -Qm foreign set. If nothing in your AUR set was touched in that window, your exposure is low. If something was, continue.

Step 2: Cross-reference your AUR packages against the affected list

Intersect your locally installed foreign packages with the community-maintained affected-package list. Download the list first (so a fetch failure cannot masquerade as "no matches"), then intersect it with your foreign packages. This needs a shell with process substitution (Bash or Zsh):

curl -fsSL https://cscs.pastes.sh/raw/aurvulnlist20260611.txt -o /tmp/aurvuln.txt && wc -l /tmp/aurvuln.txt

comm -12 <(pacman -Qqm | sort) <(sort /tmp/aurvuln.txt)

Confirm the download succeeded (a non-zero line count, one package name per line) before trusting an empty comm result; curl failing silently would otherwise leave you with a false all-clear. Even with a good download, an empty result is reassuring but not absolute: the list is a community snapshot dated June 11 and may not capture every adopted package or the later js-digest activity. Treat the list as a high-confidence positive signal, not an exhaustive negative.

Step 3: Look for the rootkit's eBPF objects directly

bpftool reads loaded eBPF state from the kernel and is not subject to the getdents64() hook. The named maps are the tell:

sudo bpftool map list | grep -E 'hidden_pids|hidden_names|hidden_inodes'

sudo bpftool prog list

Do not redirect stderr away here: a missing binary, a sudo failure, or a kernel error would otherwise look identical to "no matching maps." Run the commands bare, read any error, and only treat a clean, error-free run with no hidden-* map as a negative. Any hit on the hidden-* map names is high-confidence compromise. bpftool ships in the bpf package (sudo pacman -S --needed bpf) if it is not already present. Even an error-free empty result does not fully clear the host: the rootkit loads only when the install hook ran as root, and absence of the maps now could also mean the implant has not loaded in the current boot.

Step 4: Hunt the install-time artifacts

Check the AUR helper build caches and any Node/Bun artifacts for the malicious package names and hook strings:

grep -rlE 'atomic-lockfile|js-digest|herbsobering' ~/.cache/yay ~/.cache/paru ~/.cache/aurutils

sudo find / -xdev -type d \( -name atomic-lockfile -o -name js-digest \)

sudo find / -xdev -name deps -type f

Scope caveats: the grep covers only those three candidate AUR-helper cache locations, so add any manual makepkg build directory you use (and note unreadable or nonexistent paths are silently skipped). find -xdev stays on one filesystem, so re-run it per mount if /home or others are separate mounts, and use sudo so root-owned paths are not missed. deps is a common filename, so treat a bare deps hit as a lead to investigate, not proof. A community detection script (Kidev) bundles similar checks; review it before running, as with any remote script: https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc3992. Remember the rootkit may hide on-disk paths from find, so a negative file search is weaker evidence than the bpftool and pacman.log checks.

Response, if a host installed an affected package in the June 11 to 12 window

1. Isolate the host. Take it off the network or restrict outbound traffic, ideally at a router or firewall outside the machine, since on-host firewall state can be tampered with by a root implant. Do not start deleting packages yet if you want triage artifacts; capture the pacman.log, the bpftool output, and the build caches first. If this is a production or build host, treat it as an IR case and preserve a disk and memory image before remediation.
2. Establish the credential blast radius and rotate everything reachable. The infostealer specifically goes after GitHub credentials, SSH keys (~/.ssh), HashiCorp Vault tokens (~/.vault-token, VAULT_TOKEN in env), cloud CLI material (~/.aws, ~/.config/gcloud, ~/.azure, ~/.kube), browser cookie and password stores, Slack / Discord / Teams / Telegram sessions, environment variables, and crypto wallets. Rotate or revoke all of it: GitHub PATs and SSH keys, cloud keys, Vault tokens, npm tokens, browser-saved passwords, and move any wallet funds to a fresh wallet generated on a clean device. Do the rotation from a known-clean machine, not the suspect host. Revoking session tokens (GitHub, Slack, Discord) matters as much as changing passwords, since the stealer grabs live sessions.
3. Confirm the rootkit before you trust any local scan. Run the bpftool map list / prog list checks from a root shell. If the hidden_* maps are present, you have a confirmed kernel-resident implant and should go straight to reinstall (step 6); piecemeal cleanup of an eBPF rootkit is not reliable.
4. Remove the malicious AUR packages and any Node/Bun residue. Identify affected packages from step 2 and remove them with sudo pacman -Rns -- package-name (substitute the real package name; the -- stops flag parsing). Delete the atomic-lockfile / js-digest node_modules and Bun caches the build pulled. If you intend to reinstall a package later, rebuild from a known-clean upstream PKGBUILD you have reviewed, not from the AUR copy that was live during the window.
5. Block the exfil path at the network edge. Reporting indicates the C2 ran over Tor, so blocking outbound Tor at your router or firewall (and watching for connections to Tor guard nodes in egress logs) is a reasonable network-side containment while you remediate hosts. This does not clean an infected machine; it limits ongoing exfiltration.
6. Reinstall from scratch where the rootkit is confirmed or the host's role warrants it. An eBPF rootkit with process/file/inode hiding can survive ordinary package removal and signature scans. For any host that held real credentials, build/CI duties, or sensitive data, the defensible move is wipe and reinstall from trusted media, then restore data (not binaries) from a backup that predates June 11. Re-enroll rotated credentials only after the rebuild.
7. Pause AUR updates until the all-clear, and re-examine your AUR hygiene. Until the aur-general thread reports the cleanup complete, stick to official-repo updates (pacman -Syu) and hold off on AUR rebuilds. When you resume, enable your AUR helper's diff review (yay --editmenu / --diffmenu, paru's review prompt) so PKGBUILD and .install changes are shown before they run, and be wary of packages whose maintainer or upstream changed recently. This campaign worked precisely because adopted-orphan PKGBUILD edits run unreviewed by default.
8. Document the timeline. Record which hosts installed which packages when, what was rotated, and what was reimaged. As of June 12, 2026 the community list and the named-package set were still being updated, and a later js-digest wave was reported, so re-check the primary sources as more package names surface.

The broader pattern

This is the same supply-chain quarter the Bulletin has been tracking, but it moves the attack one rung closer to the developer's own machine. The npm / PyPI campaigns (TrapDoor, PyTorch Lightning, Bitwarden CLI, xinference) poisoned language-registry distribution. The DAEMON Tools compromise poisoned vendor-direct binary distribution. Atomic Arch poisons a community OS package repository with no pre-publication review, using account adoption rather than a stolen key. The defenses are correspondingly different: lockfile pinning and registry malware scanning do not help here, and neither does Authenticode-style publisher trust, because the AUR has no signing of user PKGBUILDs at all.

The escalation worth noting is the payload itself. Most of the 2026 registry campaigns shipped JavaScript or Python credential-stealers that ran as the user. This one ships a native eBPF rootkit and gets root for free because AUR install hooks run inside pacman. "It ran as my user, I cleaned the package, I'm fine" was a defensible read for the earlier incidents. It is not a defensible read for a kernel-resident rootkit on a machine that ran the hook as root. When the implant operates below the tools you would use to find it, the honest posture for a confirmed hit is rebuild, not scrub.