Cloud Security

Arch Linux AUR Mass Compromise: 400+ Packages Weaponized

June 12, 2026 · 7 min read · By William

How the Atomic Arch Campaign Works

On June 11, 2026, security researchers uncovered a supply-chain campaign now tracked as Atomic Arch (Sonatype-2026-003775, CVSS 8.7) that hijacked over 400 packages in the Arch User Repository — with later assessments suggesting the scope may reach 1,500. The attackers adopted orphaned AUR packages whose maintainers had walked away, modified their PKGBUILD files to silently install a malicious npm dependency, and let the trust those package names carried do the rest. No zero-day. No exploit. No breach of Arch’s infrastructure. Just inherited trust, weaponized at scale.

According to the The Hacker News analysis, the attackers also spoofed git commit metadata so the malicious changes appeared to come from long-standing maintainers. An Arch Linux Trusted User later confirmed those accounts were never actually compromised — the commits were forged. Once adopted, the packages’ PKGBUILD or .install scripts were edited to execute npm install atomic-lockfile minimist chalk during the build. The legitimate packages minimist and chalk served as cover. Confirmed examples reported to the Arch mailing list include alvr and premake-git.

The npm package atomic-lockfile@1.4.2 contains a preinstall lifecycle hook — "preinstall": "./src/hooks/deps" — that executes a Linux ELF binary directly during installation. No JavaScript wrapper. No additional configuration. The C2 endpoint is encoded inside the binary itself. Build the AUR package, and the malware runs.

What the Malware Steals

Independent researcher Whanos reverse-engineered the payload — a stripped, Rust-compiled ELF named deps (SHA-256: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b) — and published a detailed static analysis. The binary is a credential stealer built for developer workstations and CI/build environments. It targets:

Cookies, tokens, and local storage from Chromium-based browsers (Chrome, Edge, Brave)
Session data from Electron apps — Slack, Discord, Microsoft Teams
GitHub, npm, and HashiCorp Vault tokens
OpenAI/ChatGPT bearer tokens and account metadata
SSH keys, known_hosts, and shell histories
Docker and Podman credentials
VPN profiles and configuration files

Stolen data is uploaded to temp.sh via HTTP POST. Command and control runs through a Tor onion service (olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion) accessed through a local loopback proxy. The binary also stages a second file tied to monero-wallet-gui that researchers flag as a likely cryptominer, though it remains unanalyzed.

For persistence, the malware installs systemd services with Restart=always. With root, it copies itself under /var/lib/ and writes a system unit. As a normal user, it uses the home directory and a per-user unit under ~/.config/systemd/user/. Either way, it comes back after reboot.

The eBPF Rootkit Component

Early reporting overstated the rootkit angle, and that matters for triage. The eBPF component is optional — it only activates when the binary already has root and the necessary capabilities. It is not used for privilege escalation. When it does load, it hides the malware’s own processes, process names, and socket inodes from standard inspection tools using pinned BPF maps named hidden_pids, hidden_names, and hidden_inodes. It also kills debugger attach attempts.

But that changes the cleanup calculus entirely. Removing the compromised AUR package is insufficient once the payload has executed. A package manager can remove files it knows about. It cannot prove the machine is clean after a rootkit-capable binary has run with elevated privileges.

Second Wave Expands the Attack

Sonatype’s initial disclosure counted roughly 20 hijacked packages. Within 24 hours, community trackers grepping the AUR git mirror cataloged over 400, with consolidated lists still climbing — a scale reminiscent of how a single VS Code extension compromise exfiltrated 3,800 internal GitHub repos. A second wave emerged on June 12 using bun install js-digest rather than npm, pushed from a separate set of AUR accounts linked to the same npm publisher. Its payload is a different ELF binary with a distinct hash. BleepingComputer reports that Sonatype also identified lockfile-js as a third malicious package in the campaign. The full scope of the second wave is still being counted, but it is not a footnote — check for both atomic-lockfile and js-digest.

Why This Matters for Cloud Ops

Arch Linux is not just a desktop distribution. It underpins container base images used in cloud deployments. Manjaro and EndeavourOS derivatives appear in CI pipelines. The AUR is routinely consumed in Dockerfiles and build scripts for bleeding-edge tooling. If a developer workstation that builds these images was compromised, the blast radius extends far beyond that one host — stolen Vault tokens, SSH keys, and cloud credentials can grant access to production infrastructure.

The attack vector is particularly dangerous because it targets the build environment, not the runtime. Secrets available at build time — CI/CD tokens, registry credentials, signing keys — are often more valuable than what runs in production. The malware’s focus on developer secrets (GitHub tokens, npm credentials, Docker logins, Vault tokens) confirms the operators understand this distinction — echoing the credential-harvesting pattern seen when stolen credentials caused 31% of breaches this year.

Immediate Remediation Steps

Arch maintainers are resetting malicious commits and banning attacker accounts, but the affected-package list remains incomplete. If you run Arch-based systems or consume AUR packages in any build pipeline:

Check every AUR package installed or updated on or after June 11 against the community-maintained affected-package lists and detection scripts.
Grep build history for npm install atomic-lockfile, bun install js-digest, and the payload path src/hooks/deps.
If a flagged package ran, treat the host as compromised. Rotate everything: browser sessions, SSH keys, GitHub and npm tokens, Slack/Teams/Discord sessions, Vault tokens, Docker/Podman credentials, and any cloud keys.
Hunt for persistence: check for unknown systemd services (both system units and ~/.config/systemd/user/) and unexpected files under /var/lib/. Inspect /sys/fs/bpf/ for the maps hidden_pids, hidden_names, and hidden_inodes.
If the package ran as root, reinstall from trusted media. There is no reliable way to verify system integrity after a rootkit-capable payload has executed with elevated privileges.
Going forward, read PKGBUILD and .install hooks before building — especially for recently adopted packages or those suddenly active after long dormancy. If you do not understand the build instructions, do not install the package.

Why AUR’s Trust Model Failed

This attack worked because the AUR still trusts a package’s name and history over who is maintaining it now. A package with years of legitimate history and community trust can be adopted by a new maintainer who introduces malicious build steps, and the existing trust is inherited automatically. The same tactic hit an abandoned PDF-viewer package back in 2018. The 2026 version just scaled it to 400+ packages simultaneously, part of a broader supply-chain trend where hijacking orphaned projects to inherit trust outperforms typosquatting — the same trust-inheritance tactic seen when 73 Microsoft GitHub repos fell to the Miasma supply chain worm earlier this month.

For organizations that rely on Arch-based tooling, this is a wake-up call to treat community repositories as untrusted input. Pin package versions, verify PKGBUILD contents in CI, and maintain an allowlist of trusted maintainers. The convenience of yay -Syu is not worth credential exfiltration from every developer workstation and build host in your environment.