Atomic Arch Campaign Hijacks 400+ Linux AUR Packages to Deploy Infostealer and eBPF Rootkit

Key Findings

• Over 400 packages in the Arch User Repository (AUR) were hijacked this week with malicious build scripts

• Attackers modified PKGBUILD files to inject a credential stealer written in Rust that harvests developer secrets

• The malware can load an eBPF rootkit when running with root privileges to hide its presence

• Attack targets orphaned packages with abandoned maintainers, then spoofs commit metadata to appear legitimate

• Malware collects browser cookies, SSH keys, GitHub tokens, and credentials from Slack, Discord, Teams, and other apps

• Two waves identified: first using atomic-lockfile npm package, second using bun install js-digest

• Simply removing the package is insufficient if the rootkit payload has already executed

• Official Arch repositories were not affected; only the community AUR was compromised

Background

The Arch User Repository is a community-maintained collection separate from Arch Linux's official packages. It allows users to contribute installation scripts called PKGBUILDs that automate building and installing software. When package maintainers abandon projects, the packages become orphaned and available for anyone to adopt. This flexibility is a strength for the community but creates an opening for exactly this kind of attack.

Attack Method

The attackers exploited the trust model rather than a software vulnerability. They adopted abandoned packages, keeping their original names and histories intact, then rewrote only the build instructions. Users saw familiar package names they recognized and trusted, with no reason to suspect the underlying recipe had changed.

The malicious code was embedded in modified PKGBUILD or .install scripts that ran npm install atomic-lockfile during the build process. This pulled down a malicious npm package alongside legitimate ones for cover. The atomic-lockfile package contained a preinstall hook that executed a bundled Linux binary called deps. When users built the package, the payload ran automatically.

Confirmed examples included the alvr and premake-git packages. The attackers also spoofed git commit metadata to make changes appear as if they came from long-standing maintainers. Arch Linux Trusted Users later confirmed these accounts were never actually compromised.

What the Malware Does

The deps binary is a Rust-based credential stealer designed to target developer workstations and build systems. It collects an extensive inventory of sensitive data:

• Cookies, tokens, and local storage from Chromium-based browsers including Chrome, Edge, and Brave

• Session data from Electron apps like Slack, Discord, and Microsoft Teams

• GitHub, npm, and HashiCorp Vault tokens plus OpenAI and ChatGPT bearer tokens

• SSH keys, known_hosts files, and shell histories

• Docker and Podman credentials and VPN profiles

Stolen data is exfiltrated over HTTP to temp.sh, with command and control routed through a Tor onion service via a local loopback proxy. The malware installs itself as a systemd service with Restart=always for persistence, placing itself under /var/lib/ with a unit in /etc/systemd/system/ when running as root, or in the home directory and ~/.config/systemd/user/ as a regular user.

The eBPF Rootkit Component

Early reports overstated the eBPF rootkit's significance, but it is worth noting. The rootkit is optional and only loads when the binary already has root access and the correct capability. It is not used to escalate privileges.

When activated, it hides the malware's own processes, process names, and socket inodes from standard tools using pinned BPF maps named hidden_pids, hidden_names, and hidden_inodes. It also kills attempts to attach a debugger for analysis. The rootkit's presence changes cleanup recommendations significantly.

Removing the AUR package is insufficient once the payload has executed with elevated privileges. A package manager can only remove files it knows about. After a rootkit-capable payload runs, there is no way to definitively prove the system is clean without deeper forensic work.

The binary also stages a second file tied to monero-wallet-gui flagged as a possible cryptominer, though this remains unanalyzed.

Scope of the Compromise

Sonatype initially counted over 20 hijacked packages. Within a day, community trackers and the Arch aur-general mailing list thread cataloged over 400 packages, with grep-based searches of the AUR git mirror putting the number around 408 and consolidated lists showing even higher counts as analysis continued.

The atomic-lockfile npm package itself showed only 134 weekly downloads on Socket before removal, indicating the real exposure came through the AUR build path rather than direct npm installs. The attack's reach extends far beyond simple download statistics because AUR users typically build packages on their own machines as part of their workflow.

A second wave emerged using bun install js-digest, launched from separate accounts that community researchers linked to the same npm publisher behind atomic-lockfile. This payload deploys a different binary by hash that the community also flagged as malicious. Early counts listed a few dozen compromised packages in the second wave, though later grep searches returned much higher numbers that may include reverted commits.

Timeline and Affected Packages

The initial wave targeted packages adopted between the start of the campaign and June 11. Anyone who installed or updated an AUR package on or after that date should check it against current affected-package lists before trusting the host. Confirmed examples span from alvr to premake-git and many others still being cataloged.

The second wave using js-digest remains ongoing with its full scope still being counted. Both waves warrant investigation, so users should check their systems for evidence of both atomic-lockfile and js-digest.

Remediation Challenges

Standard signature-based security tools failed to catch these compromises because the hijacked packages themselves looked perfectly clean. Only the build instructions changed, leaving no obvious signs of tampering in the final compiled binaries.

Arch maintainers began resetting malicious commits and banning compromised accounts, but the distributed nature of the AUR means detection and cleanup relied heavily on community effort. The combination of a credential stealer and rootkit means infected systems require more aggressive remediation than simply removing a package. Deep forensic analysis may be necessary to confirm systems are truly clean.

Sources

• https://thehackernews.com/2026/06/over-400-arch-linux-aur-packages.html

• https://hackread.com/atomic-arch-hijacks-linux-aur-packages-malware/