Arch Linux users are dealing with a large supply chain attack against the Arch User Repository after attackers modified hundreds of community packages to run credential-stealing malware during the package build process.
The campaign surfaced on June 11 and June 12, 2026, as Arch community members began collecting malicious AUR commits in an aur-general mailing list thread. Arch maintainers said they were working to reset or delete malicious commits and ban the accounts involved. Subsequent community lists and downstream distro forums put the number of affected packages in the hundreds, with some trackers listing more than 1,000 possible package names as the investigation widened.
The important distinction is scope. This was an AUR incident, not an attack on Arch Linux’s official binary repositories. But that does not make it harmless. The AUR is widely used by Arch, EndeavourOS, CachyOS, Manjaro, and other Arch-based Linux users to install software outside the official repos. A compromised AUR package can execute code on the developer workstation or build host that compiles it.
How the AUR packages were abused
Early reporting from BleepingComputer and The Hacker News described a coordinated takeover of AUR packages that changed build or install scripts. In the first major wave, attackers used orphaned packages and forged-looking commit metadata to make malicious changes appear as if they came from a known maintainer. The compromised scripts pulled in a malicious npm package named atomic-lockfile version 1.4.2.
The technique matters because it hid the malware behind a normal-looking package build step. AUR helpers and manual builds usually fetch a package recipe, inspect or run its PKGBUILD and associated install hooks, then build locally. If that recipe calls an external tool such as npm and the downloaded package contains a lifecycle hook, the user’s machine becomes part of the execution path.
A reverse-engineering report by researcher Whanos at ioctl.fail found that the malicious atomic-lockfile package included a Linux ELF payload named deps and wired it into npm’s preinstall lifecycle script. In practical terms, installing the npm package could automatically launch the binary before the user ever interacted with the package’s advertised functionality.
What the malware tried to steal
The payload was not a generic nuisance. The analysis describes a Rust-based Linux credential stealer aimed squarely at developer and power-user machines. It looked for browser and Electron app data, Slack and Microsoft Teams sessions, Discord tokens, GitHub and npm credentials, Vault tokens, Docker and Podman credential material, SSH keys, VPN profiles, shell histories, and other local secrets.
That target list explains why the incident matters beyond Arch enthusiasts. AUR users are often developers, Linux administrators, researchers, and technical users who keep valuable credentials on the same machines they use to build packages. A stolen GitHub token, npm token, SSH key, or cloud credential can turn one compromised laptop into a path toward source code, package publishing rights, CI systems, private infrastructure, or internal chat data.
The malware also had persistence behavior. The analysis found systemd service installation paths for both root and user-level execution, with restart behavior designed to keep the process alive. When run with enough privilege, it could load an embedded eBPF rootkit that hid selected processes, names, and socket activity. The eBPF component was not described as a privilege-escalation mechanism; it was a hiding layer for systems where the malware already had sufficient capability.
That distinction is useful for response teams. A normal user-level AUR build is still dangerous because of credential theft. A build or install that ran as root, or on a machine where the malware gained root-level capability, raises the bar for cleanup because live response tools may miss hidden process or socket artifacts.
Who should check their systems
Anyone who installed or updated AUR packages around June 9 through June 12, 2026 should review the affected package lists before assuming the host is clean. CachyOS forum guidance noted that most users are not affected unless they install from the AUR, and suggested checking locally installed foreign packages with paru -Qm for users of the Paru helper. Similar checks can be made with other AUR helpers or with pacman’s foreign-package listing.
The community-maintained aur-malware-check repository consolidates detection scripts and a package list for the June 2026 atomic-lockfile AUR supply chain attack. Its README describes two script versions, exit codes for clean or infected results, and indicators such as known package names, suspicious service artifacts, and the malicious payload hash. As with any incident-response helper, users should read the script before running it and fetch updates from the source they trust.
A good first pass is simple: list AUR packages installed on the machine, compare them with the current affected-package list, and check package-manager logs for suspicious builds during the incident window. Systems that show a match should be treated as potentially compromised, especially if the package build ran as root or on a machine that stores developer tokens.
What to do if there is a match
For a confirmed or likely hit, removing the package is not enough. The malware’s purpose was credential access, and some of those credentials can outlive the infected process. Rotate GitHub personal access tokens, npm tokens, SSH keys, Slack and Teams sessions, Vault tokens, Docker registry credentials, cloud keys, and any credentials used from that machine during or after the suspected build window.
Look for unknown systemd user services and system services, unexpected files under user configuration paths or /var/lib, and eBPF pinned objects such as hidden maps under /sys/fs/bpf on systems where root execution is possible. The community detection repository specifically calls out systemd persistence checks and eBPF rootkit artifacts, while also warning that a rootkit-capable system may require cleanup from trusted media or reinstallation rather than in-place repair.
For developer machines, also assume downstream blast radius. Review recent Git pushes, package publishes, CI secrets, registry tokens, SSH access, and cloud audit logs. If the host had access to private repositories or production infrastructure, the response should move beyond the laptop and into account, repository, and infrastructure review.
Why this one feels different
The AUR has always been a trust-on-inspection ecosystem. Users are expected to read recipes, understand that packages are community-maintained, and treat abandoned or newly adopted packages with caution. The June attack shows how that model strains when package helpers make installation feel routine and when attackers can combine orphaned packages, forged-looking commit metadata, external package managers, and lifecycle hooks into a single chain.
The incident also connects Linux desktop package risk with the broader software supply chain problem. The malicious AUR recipes did not need to exploit a kernel bug or defeat package signing in the official repositories. They used the flexibility of build scripts and the trust users place in community package metadata. That is the same uncomfortable pattern showing up across npm, PyPI, browser extensions, CI templates, and developer tools: attackers go where developers already run code.
For Arch users, the practical answer is not to abandon the AUR wholesale. It is to treat AUR installs like code execution, because that is what they are. Inspect PKGBUILD files and install hooks, be cautious with orphaned packages and sudden maintainer changes, avoid building unknown packages with elevated privileges, keep AUR helper prompts visible, and separate daily-use credentials from experimental package-building environments where possible.
This is also a reminder for teams that allow developer workstations to use community repositories. AUR access should be part of endpoint and credential policy, not an invisible personal preference. The machines that build hobby packages may be the same machines that hold production SSH keys, npm publish tokens, or GitHub access to business-critical code.
