In June 2026, attackers compromised more than 1,500 packages in the Arch User Repository (AUR). Sonatype researchers named the campaign Atomic Arch. It is one of the largest attacks against the AUR to date.
The AUR is a community-maintained collection of package build scripts. It is separate from Arch Linux's official repositories. The official repositories were not affected.
The attack did not exploit a flaw in Arch Linux or pacman. It abused the AUR's package adoption process to take over orphaned packages that users already trusted.
This article explains what happened, why it worked, and what you can do to reduce the risk in the future.
Table of Contents
Atomic Arch: AUR Malware Attack (June 2026)
The attackers did not exploit a vulnerability in Arch Linux. They abused a legitimate AUR feature called package adoption. Package adoption lets orphaned packages receive a new maintainer after the original maintainer stops maintaining them.
The attackers adopted orphaned packages and modified their PKGBUILD files. A PKGBUILD is a Bash script that tells makepkg how to download, build, and package software. Because it is a script, it can execute arbitrary commands during the build.
Many of the modified PKGBUILD files downloaded a malicious npm package named atomic-lockfile. An npm package is software distributed through the Node Package Manager (npm) registry. The npm package dropped a Linux ELF executable onto the system. An ELF executable is the standard binary format used by Linux.
The malware stole browser cookies, session tokens, login credentials, SSH keys, Docker credentials, VPN profiles, and cloud secrets. It could also deploy an optional eBPF rootkit after it gained root privileges. An eBPF rootkit uses Linux's Extended Berkeley Packet Filter (eBPF) framework to hide malicious activity from the operating system.
The campaign began with about 400 compromised packages and grew to more than 1,500 over the following days. Arch maintainers froze new AUR account registrations while they investigated the incident and removed the malicious packages.
The official Arch repositories (core, extra, multilib) were never affected. The attack targeted the AUR's trust model, not Arch Linux's packaging or package signing infrastructure.
Why this happened
The attack did not succeed because Arch Linux was insecure. It succeeded because the AUR is built on trust.
The AUR is a community-maintained collection of package build scripts. Anyone can submit new packages, and orphaned packages can be adopted by new maintainers. Unlike the official repositories, AUR packages do not go through a formal review before they become available.
That does not make the AUR unsafe. It means the responsibility for deciding whether a package is trustworthy belongs to the user. The AUR is designed to make community packaging easy, not to certify that every package is trustworthy.
The attackers took advantage of that model. Instead of creating new malicious packages, they adopted orphaned packages that already had existing users and an established history. After they became the maintainer, they modified the PKGBUILD files to include malicious code.
This incident shows that trust belongs to maintainers, not packages. When a package changes hands, that trust should be earned again. A package that was trustworthy last year is not automatically trustworthy today. Reviewing changes is just as important as reviewing a package for the first time.
How to use the AUR more safely
You do not need to stop using the AUR. You do need to be more deliberate about when and how you use it.
1. Prefer the official repositories
Check the official repositories before using the AUR. Official packages go through Arch's packaging process and are maintained by the Arch Linux team. Use the AUR only when the software is not available in the official repositories.
Some software vendors also provide official Arch repositories or official packages. When they do, prefer those over community-maintained AUR packages. Updates come directly from the publisher instead of an AUR maintainer.
2. Review the PKGBUILD before you build
A PKGBUILD is a Bash script. Review it before you build the package. If you already trust the package, focus on what changed since the last update.
Pay close attention if the package has a new maintainer or was recently adopted. Look for unexpected downloads, commands that are unrelated to building the software, or changes that do not match the upstream project.
A companion .install file can also run commands during package installation. Review it if the package includes one.
Read the package comments. Other users often report broken builds, maintainer changes, or suspicious behavior.
3. Build packages in a clean chroot
A clean chroot is an isolated build environment that contains only the packages needed for the build. It reduces the risk of a build script accessing files from your working environment and helps produce clean, reproducible builds. The devtools package provides tools for creating and using clean chroots.
You can find more details in the link below:
4. Consider Flatpak for desktop applications
Flatpak distributes prebuilt desktop applications that run inside a sandbox. A sandbox limits what the application can access unless you grant additional permissions. That reduces the impact of a compromised application, but it does not guarantee that the application is trustworthy.
You can install flatpak and enable flathub repository using commands:
sudo pacman -S flatpak
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
5. Use containers when you need software from another distribution
If you need software that is easier to install on another Linux distribution, consider running it inside a Distrobox container instead of relying on an unofficial AUR package. Distrobox keeps that software isolated from your main system while integrating it with your desktop.
To install Distrobox and create containers (E.g. Void Linux), do:
sudo pacman -S distrobox
distrobox create --name void-box --image voidlinux/voidlinux
distrobox enter void-box
6. Audit installed AUR packages
The following command lists foreign packages, which are packages that are not installed from the official repositories:
pacman -Qm
Review the list regularly. Pay extra attention to packages that have recently changed maintainers or were adopted after becoming orphaned.
7. Keep system snapshots
A filesystem snapshot captures the current state of your system. Tools such as Snapper or Timeshift let you roll back after a bad update, package installation, or configuration change. A snapshot cannot protect credentials that were already stolen, but it can make system recovery much faster.
Before you install or update an AUR package, ask yourself three questions:
- Is the software available from the official repositories or the publisher?
- Do the recent changes in the
PKGBUILDmake sense? - Do I trust the current maintainer?
If you cannot answer all three with confidence, stop and investigate before you continue.
Summary
The June 2026 AUR malware campaign is not a reason to stop using Arch Linux or the AUR. It is a reminder that trust should be earned and reviewed over time.
The attack did not exploit a vulnerability in Arch Linux. It exploited the trust users placed in packages that changed maintainers. The same idea appears in many software supply chain attacks. Attackers often target trusted software instead of technical vulnerabilities.
The AUR gives the community a simple way to package and share software that is not available in the official repositories. That openness also means users must decide which packages to trust.
Every recommendation in this article follows the same principle. Reduce the amount of trust you place in software, and reduce the impact if that trust is misplaced.
Treat every PKGBUILD as executable code, because that is exactly what it is. Review changes before you build. Pay attention to maintainer changes. Use the AUR when it adds value, not simply because it is convenient.
Security is not about avoiding every risk. It is about understanding where trust exists and deciding whether it has been earned.
If you're newer to Arch, build your base system from official repos, use Flatpak for extras, use containers for cross-distro needs, and treat the AUR as something you read before you trust.
Resources and Further Reading:
