Arch Linux AUR Packages Hijacked to Drop Infostealer and Rootkit

Arch Linux AUR users should review recent package builds after a broad supply-chain compromise in the Arch User Repository tied trusted community package names to malicious JavaScript-package installs, credential theft, and rootkit-like Linux behavior. Reports published on June 11-12, 2026 describe more than 400 affected AUR packages, with Arch maintainers actively deleting malicious commits and banning accounts while the community continues to collect reports.¹²

The attack is important because the payload did not need to trick users into installing a brand-new suspicious project. Instead, attackers reportedly adopted or modified familiar AUR package recipes and changed their build instructions. To the user, an update could look like a normal AUR build; behind the scenes, a package script invoked npm or bun and pulled malicious dependencies such as atomic-lockfile or js-digest.²³

Sonatype’s analysis of the Atomic Arch campaign says modified PKGBUILDs added a post-install step that invoked npm and installed atomic-lockfile. The npm package then ran a bundled native Linux executable through a preinstall script. Static analysis found references to eBPF components, process/file/network hiding behavior, debugger detection, archive handling, multipart uploads, and targets including GitHub credentials, SSH artifacts, Vault tokens, browser cookie databases, Slack, Discord, Microsoft Teams, Telegram, Docker/Podman material, shell histories, and other developer secrets.²⁴

BleepingComputer’s June 12 report cites community research that one sample included a Linux ELF payload named deps, described as a credential stealer with optional root-only eBPF rootkit capabilities. That distinction matters: a non-root build may still expose local tokens and browser data, but a root-run build or privileged helper path can raise the response bar because rootkit-style hiding means the machine may no longer be trustworthy for cleanup from inside the same OS.⁴

What Arch users should check now

First, treat the exposure window as a practical triage question, not only a package-name question. Community scan guidance uses June 9, 2026 as an observed campaign start point, so users who installed or upgraded AUR packages through helpers such as yay, paru, pikaur, trizen, or aurutils after that date should review /var/log/pacman.log, helper clone caches, and installed package metadata for suspicious JavaScript package-manager invocations.⁵

Useful indicators include atomic-lockfile, js-digest, lockfile-js, src/hooks/deps, and unexpected use of npm, npx, pnpm, yarn, bun, or bunx from an AUR install scriptlet or hook. Those checks are intentionally broader than one dependency name because the campaign already showed signs of dependency rotation.³⁵

If a compromised build is found, removing the AUR package is not enough. Rotate GitHub, SSH, npm, registry, VPN, Docker/Podman, Vault, chat, browser-session, and cloud credentials from a separate clean device. Review recent token use and repository activity. For developer workstations and CI hosts, assume cached secrets may have been exposed. If the build ran as root or there is evidence of eBPF/rootkit behavior, a clean reinstall is safer than trying to prove the running system is clean.⁴

This incident also connects to a wider pattern howtofix.guide has covered in recent developer supply-chain attacks: token theft through Miasma’s Microsoft GitHub repository wave, poisoned developer tooling in the Nx Console VS Code extension case, and malicious package updates in the Laravel-Lang Composer compromise. The common lesson is not “avoid community packages forever”; it is to reduce the number of machines that can build unreviewed package scripts while holding valuable tokens.

For future AUR installs, inspect PKGBUILDs and install scripts before building, prefer actively maintained packages, avoid running AUR builds with more privileges than required, and keep development secrets out of everyday build environments where possible. AUR remains useful, but this campaign shows why a package ownership change can be as dangerous as a brand-new malicious package.