400+ AUR Packages Hijacked: What the “Atomic Arch” Campaign Means for Supply-Chain Security

What it is

The "Atomic Arch" campaign (Sonatype's name), disclosed June 11, 2026 by researchers and the Arch Linux community. Attackers adopted 400+ orphaned AUR packages and modified their PKGBUILDs/install hooks to pull a malicious npm package posing as atomic-lockfile (variant js-digest), delivering a Rust credential stealer. The summary covers the payload and scope; below is what the page adds for someone deciding how to respond.

How it works

The abused mechanism is AUR's ownership transfer: an abandoned package can be adopted by anyone, inheriting its name, users, and accumulated reputation. The injected build logic runs npm install atomic-lockfile at install/update time — so the malicious dependency executes on the host during the ordinary build, not from an obviously suspicious package. The page frames this as "ownership hijacking beats typosquatting": no lookalike, the trusted name is taken over directly.

Preconditions / Affected

The vector is AUR-specific. It hits you only if an Arch or Arch-derived environment actually installs AUR packages:

• Arch, EndeavourOS, Manjaro (when AUR is used)
• Self-hosted CI runners/build agents on Arch that install AUR packages in bootstrap or job steps
• Windows developers running Arch under WSL2 and installing AUR inside it

Not affected by this vector: GitHub-hosted runners; self-hosted runners on RHEL/Rocky, Debian/Ubuntu, or Windows (unless they nest Arch); native macOS/Windows machines. The page notes the stolen assets — GitHub tokens, cloud keys, SSH keys — are the same ones that gate non-Arch production, so a single compromised Arch laptop is a pivot into everything else.

flowchart TD
    A[Orphaned AUR package] -->|attacker adopts| B[Malicious PKGBUILD]
    B -->|user installs/updates| C[npm install atomic-lockfile]
    C --> D[Rust credential stealer runs]
    D --> E{Running as root?}
    E -->|yes| F[eBPF persistence, hides processes/files]
    E -->|no| G[Exfiltrate tokens, keys, sessions]
    F --> G
    G -->|stolen GitHub/cloud creds| H[Pivot into non-Arch production]

What to do

The page's core response guidance: treat any compromised host as fully untrusted.

• Rebuild from clean media — do not clean in place.
• Rotate all exposed credentials (SSH keys, GitHub/npm/dev tokens, cloud access keys, Docker/Podman creds, browser/SSO/Slack/Discord/Teams sessions).
• A one-off malware scan is explicitly not sufficient, especially where eBPF persistence may hide activity from userspace tools.

(The post's "Immediate Response" section is truncated in the fetched text; the steps above are what it states before the cutoff.)

Caveats

Initial reports undercounted the scope; the 400+ figure came from follow-up community analysis, so the true count may still shift. The eBPF rootkit capability is conditional — it applies only where the malware gains root.