Arch Linux AUR Recovers from Three-Wave Attack Targeting Over 1,500 Packages

An Unprecedented Crisis in the AUR Repository

On June 11, 2026, a large-scale attack was uncovered targeting the Arch User Repository, the unofficial package source for the Arch Linux distribution relied upon by thousands of users daily. Attackers managed to take over hundreds of orphaned packages, inject malicious code, and publish them as legitimate updates.

What began as an attack targeting around 400 packages escalated into a major security incident featuring three consecutive waves of attacks, before the Arch Linux team managed to fully contain the situation and confirm that everything was back to normal.

🔗 Official Source: archlinux.org/news/active-aur-malicious-packages-incident/ 🔗 List of Affected Packages: github.com/c78-contrib/cleanup-aur-blacklist

Attack Details: How Did the Compromise Happen?

First Wave: Initial Attack via NPM

Initially, attackers exploited the package adoption mechanism in AUR. Orphaned packages are those abandoned by their original maintainers. Any user can adopt them and claim update privileges. Attackers took over hundreds of orphaned packages and within hours modified their PKGBUILD files.

The modifications were cunning. A single line was added to the installation script to invoke npm, the JavaScript package manager, and install a malicious package named atomic-lockfile. This package contained a malicious file named deps.

When any user installed or updated the compromised package using an AUR helper such as yay or paru, the malicious code executed on their machine.

Second Wave: Obfuscated Attack

After the Arch Linux team announced they had contained the first attack and removed the compromised packages, everyone thought the crisis was over. However, the next day, developer a821 discovered a new wave of compromised packages. This time, attackers used advanced code obfuscation techniques to hide malicious code and make detection more difficult.

The second wave affected multiple packages, including Node.js tools, Firefox extensions, and KDE Plasma 6 applets.

Third Wave: Exploiting Bun and AI

The situation did not stop there. With the help of an independent researcher who used a local AI model, a third wave of attacks was discovered. This time, attackers exploited Bun, a fast Node.js alternative, to execute malicious commands. The code was more obfuscated, and malicious activities were hidden within the Bun command flow.

The Malware: What Did It Do?

The malicious deps file was not just a simple password stealer. It was a comprehensive attack tool.

Credential Stealer

The malware precisely targeted developer work environments. The data it attempted to steal included:

Browser data such as cookies from Chrome, Firefox, and Brave.

Access tokens for platforms like GitHub, GitLab, and npm.

Private SSH keys.

Data from communication applications such as Slack, Discord, Microsoft Teams, and Telegram.

Docker and Podman data.

Terminal history files that may contain user-entered passwords.

The goal was clear: take over developer accounts to access open source projects and their cloud infrastructure.

eBPF Rootkit

The most dangerous part of this malware was its ability to install a rootkit using eBPF technology. If the malware was run with root privileges, it could hide inside the kernel and conceal its presence, making detection and removal through traditional methods very difficult.

Team and Community Response

Once the attack was discovered, the Arch Linux team moved quickly. They temporarily disabled new account creation, halted the ability to push updates, and launched a campaign to delete compromised packages and close attacker accounts.

On June 15, the team confirmed that all compromised packages and malicious code had been removed, and the danger had passed. A comprehensive list of affected packages was published so users could review their systems.

The community also developed helper tools, such as the cleanup-aur.sh script, which scans the system for infected packages and helps remove them.

Reminder: The Nature of the AUR Repository

This incident served as a reminder of the dangerous nature of the AUR. The AUR is not an official repository. Packages in it are not subject to security review or auditing by the Arch Linux team.

When you install a package from the AUR, you are actually downloading a PKGBUILD file that downloads source code and compiles it on your machine. Anyone with an account can upload these build scripts. Therefore, security responsibility falls entirely on the user.

How to Protect Yourself

Developers reiterated the golden rule for dealing with the AUR: verify for yourself. Never install any package or update from the AUR without reviewing the PKGBUILD file first.

Arch Linux users who installed any AUR package in the past few days are advised to take the following steps:

Review the published list of affected packages to ensure none were installed.

Use automated scanning scripts such as cleanup-aur.sh.

If the system is found to be compromised, assume all credentials have been stolen and rotate them immediately.

In advanced cases where a rootkit is suspected, a complete system reinstallation from scratch is recommended to ensure no backdoor remains.

Summary

The AUR compromise incident served as a wake-up call for the Arch Linux community and all Linux distribution users in general, reminding us that trust in software must be limited and accompanied by scrutiny. The Arch Linux team succeeded in containing the situation, but the most important lesson is that the end user is the last and most important line of defense when dealing with community software.