More Than 400 Arch Linux Packages Compromised in the "Atomic Arch" Supply-Chain Attack

In one of the most significant Linux software supply-chain incidents of 2026, security researchers confirmed that hundreds of packages in the Arch User Repository (AUR) were quietly hijacked to distribute malware. The campaign — dubbed "Atomic Arch" by researchers at Sonatype and tracked as Sonatype-2026-003775 (CVSS 8.7) — turned trusted, community-maintained software into a delivery system for a Rust-based credential stealer and a stealthy eBPF rootkit.

What began as roughly 408 compromised packages on June 11, 2026 rapidly expanded. A second wave the following day pushed the total to more than 1,500 affected packages before the AUR's maintainers and the wider community intervened. Importantly, the official Arch Linux repositories were never affected — only the community-run AUR.

Whether you run Arch Linux yourself or just want to understand how modern attacks keep slipping past traditional defenses, here's a plain-language breakdown of what happened, how it worked under the hood, and what it means for you.

What Is the AUR, and Why Was It Targeted?

The Arch User Repository is a community-driven collection of build scripts — not finished software — that lets Arch Linux users compile and install programs that aren't carried in the official repositories. Each package is defined by a file called a PKGBUILD, which tells the system where to download the source code and how to build it.

Because anyone can contribute and maintainers are unpaid volunteers, packages occasionally become "orphaned" — abandoned when their original maintainer stops being active. The AUR provides a normal, legitimate workflow for someone else to adopt an orphaned package and keep it alive. That adoption process, designed to help the community, is exactly what the attackers abused.

Rather than breaking in by force, the threat actors requested ownership of established-but-unmaintained packages through the AUR's own adoption system. Once in control, they inherited each package's accumulated reputation and download history, then edited the PKGBUILD to inject malicious commands. To make the tampering even harder to detect, the attackers spoofed the Git commit metadata to make their changes appear to originate from the packages' legitimate former maintainers — an Arch Linux Trusted User later confirmed that those maintainer accounts were never actually compromised. To anyone installing or updating one of these packages, nothing looked out of place.

How the Attack Unfolded

The campaign moved fast and adapted when its first delivery method was flagged:

How the Malware Worked

"Atomic Arch" used a multi-stage chain. The hijacked PKGBUILD didn't contain the malware itself — it simply reached out to fetch it, which is what made the change so easy to overlook in a quick glance at the build script.

Stage 1 — The hijacked build script

The attacker-controlled PKGBUILD was modified to invoke a package manager during installation. In the first wave it ran npm install atomic-lockfile; in the second it switched to bun install js-digest. Both pulled down a malicious dependency package.

Stage 2 — The malicious dependency

That dependency's package.json defined a preinstall script — a command that runs automatically the moment the package is installed, before you ever use it. The package bundled a native Linux executable named "deps", and the preinstall script launched it. Both atomic-lockfile and js-digest were traced back to the same publisher, suggesting a single threat actor controlled the entire pipeline.

Stage 3 — The "deps" payload

The deps binary (SHA-256: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b), written in Rust, was the heart of the attack. It served two roles at once: a wide-ranging credential stealer and the dropper for a rootkit. Exfiltrated data was sent over HTTP to temp.sh, with command-and-control traffic routed back through a Tor onion service via the local loopback proxy — a setup designed to hide the attacker's infrastructure and make takedowns harder. On execution it swept the system for developer and personal secrets, including:

• Browser and Electron application data — Chrome, Edge, Brave, and others (cookies, tokens, local storage)
• GitHub and npm authentication tokens
• SSH keys, known_hosts, and config files
• Docker and Podman credentials
• HashiCorp Vault secrets
• Slack, Discord, and Microsoft Teams session data
• VPN configurations and credentials
• OpenAI and ChatGPT bearer tokens and account metadata
• Shell histories and other locally stored developer secrets

Stage 4 — Persistence via systemd

Once the stealer ran, it didn't simply exit — it installed itself as a systemd service to survive reboots. With root access, the service unit was written to /etc/systemd/system/ with Restart=always and the binary dropped in /var/lib/. Without root, it fell back to the user's own systemd instance at ~/.config/systemd/user/. Either way, the malware restarted itself automatically every time the machine booted, continuously attempting to exfiltrate new credentials and maintain its C2 connection.

The eBPF Rootkit — Why This Was So Dangerous

The detail that set "Atomic Arch" apart from a run-of-the-mill infostealer was its eBPF-based rootkit. If the malware happened to run with elevated (root) privileges, it deployed a component that buried itself deep in the system.

eBPF (extended Berkeley Packet Filter) is a powerful, legitimate Linux technology that lets approved programs run safely inside the kernel — the core of the operating system. It's used every day for networking, performance monitoring, and security tooling. In the wrong hands, that same kernel-level access becomes a near-perfect hiding place.

Here, the rootkit hooked the getdents64() system call — the function the OS uses to list the contents of a directory — and maintained three lists in special kernel maps stored under /sys/fs/bpf/: hidden_pids, hidden_names, and hidden_inodes. By filtering what that system call returned, the rootkit could make its own processes, files, and network activity invisible to standard tools like ls, ps, and find. It also blocked debugger attachment to its own processes, frustrating any attempt at live analysis. To an administrator looking at the machine, everything appeared normal — even as data was being siphoned off continuously.

How It Was Discovered and Contained

Independent researcher Whanos first reverse-engineered the payload and published technical findings at ioctl.fail, establishing the key details of the deps binary and its behavior. Researchers at IFIN raised broader community awareness after noticing the pattern of mass package modification. Sonatype's analysts then traced the full chain — the rogue npm/bun dependencies, the preinstall trigger, the systemd persistence, and the rootkit payload — and named the campaign "Atomic Arch," assigning it the tracking ID Sonatype-2026-003775 with a CVSS severity of 8.7 (High).

An Arch Linux Trusted User subsequently confirmed that the maintainer identities used in the spoofed commits were real but impersonated — the legitimate accounts themselves were never breached. The attacker fabricated the authorship metadata from scratch. Once the campaign was fully mapped, the AUR maintainers reset malicious commits, banned attacker-controlled accounts, and opened a community reporting thread at aur-general@lists.archlinux.org for ongoing coordination. But the cleanup doesn't undo exposure for anyone who already installed a tainted package — which is why individual remediation matters so much here.

What to Do If You Run Arch Linux

If you use Arch (or a derivative like Manjaro or EndeavourOS) and rely on the AUR, take these steps:

1. Review your recent AUR activity. Check what you installed or updated from the AUR around June 11–13, 2026. Your AUR helper's logs (e.g. yay or paru) and your shell history can help reconstruct this.
2. Look for the indicators. Search your package caches for the malicious build commands. Check for unexpected files under /sys/fs/bpf/ (such as hidden_pids, hidden_names, or hidden_inodes) — their presence is a strong sign of the rootkit. Also check for unknown systemd services: run systemctl list-units --type=service and inspect ~/.config/systemd/user/ for anything unfamiliar. The known payload hash is 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b — you can check files against it with sha256sum.
3. Rotate every credential the stealer targets. From a clean device, revoke and reissue GitHub and npm tokens, regenerate SSH keys, reset Vault and Docker/Podman credentials, change VPN secrets, and sign out of browser sessions everywhere.
4. Enable two-factor authentication on GitHub, email, and any account that may have been exposed, so a stolen password alone isn't enough.
5. Consider a clean reinstall if root was compromised. A kernel-level rootkit is notoriously hard to fully evict. If the malware ran with elevated privileges, the safest path is to back up your personal files, wipe the system, and reinstall from trusted media.

What This Means for Everyday Windows and Mac Users

You don't have to run Linux to take a lesson from "Atomic Arch." The same playbook — inherit trust instead of asking for it — shows up across every platform:

• Hijacked browser extensions that were safe for years until an update added malicious code.
• Trojanized "free" or cracked software that piggybacks on a familiar name.
• Compromised app updates delivered through legitimate channels.

The defenses are the same on Windows, Mac, and Linux alike: install software only from sources you trust, keep your system and apps patched, use multi-factor authentication everywhere it's offered, and keep regular backups so a compromise never becomes a catastrophe.

Worried your PC or Mac may have picked up something it shouldn't have? Bring it to our Roswell shop for a free diagnostic. We'll check for stolen-credential indicators, remove any malware completely, and help you lock everything back down.