Arch Linux AUR Compromise: 400+ Packages Infected with Infostealer and Rootkit

Over 400 packages in the Arch User Repository (AUR) were compromised in a large-scale supply chain attack. A malicious actor impersonating a trusted maintainer adopted orphaned packages and injected malicious preinstall scripts to deploy infostealers and eBPF rootkits.

The Attack Vector: Orphaned Package Adoption

This compromise leveraged a fundamental design feature of the AUR: any user can "adopt" a package that has been marked as unmaintained (orphaned). The attacker used this mechanism to automate the adoption of abandoned packages and push malicious updates.

To deceive users, the attacker spoofed a known, trusted maintainer's account, making the malicious commits appear legitimate. The attack is described as ongoing, with indicators of compromise (IoCs) shifting as the campaign progresses.

Technical Execution and Payloads

The malware was delivered via modified PKGBUILD files containing preinstall scripts. The attack evolved through different variants:

Variant 1: npm-based delivery

In the first identified variant, the preinstall script used npm to install a malicious package named atomic-lockfile. This package was maintained by a user named herbsobering on NPM.

Variant 2: bun-based delivery

As the attack evolved, reports indicate the attacker shifted to using bun to install a malicious package named js-digest. This shift suggests that the attacker is actively adapting to avoid detection or bypass simple npm-based workarounds.

Rootkit and Infostealer Capabilities

Beyond simple data theft, this campaign is notable for the deployment of an eBPF rootkit. The combination of an infostealer and a kernel-level rootkit allows the attacker to maintain persistence and hide their activity from the system administrator, removing the possibility of trusting the system once infected.

Remediation and Recovery

If you are an Arch Linux user, the following steps are recommended to determine and mitigate exposure:

1. Identify Infected Packages

Users can identify installed AUR packages using pacman -Qm. To check for specific compromised packages, community-developed scripts have been provided:

• aur_check.sh
• aur-malware-check
• aurvulntest20260611.sh

2. System Recovery

Because the attack involves a rootkit, standard cleanup is insufficient. The recommended procedure is to rotate all credentials and perform a full system reinstallation of Arch Linux.

Community Analysis and Debate

The incident has sparked a significant debate within the Arch community regarding the trust model of the AUR.

The "Review Every PKGBUILD" Mandate

Many users argue that the AUR has always been a collection of user-generated content and that the responsibility lies with the user to review every PKGBUILD and every update before installation.

"People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs. You have to review the source of every PKGBUILD from the AUR you install, full stop."

Proposed Structural Changes

Other community members have proposed changes to the AUR's governance to prevent similar attacks:

• Adoption Warnings: Implementing warnings in AUR helpers (like yay or paru) when a package changes ownership.
• Trusted User Review: Moving toward a community repository model where packages must be reviewed by a a "Trusted User" before being merged.
• Adoption Restrictions: Restricting the ability for any user to adopt orphaned packages without notification or review.

The Role of NPM/Bun

There is widespread frustration regarding the frequency of which NPM packages are used as delivery mechanisms for supply chain attacks, leading some users to suggest that the presence of npm or bun on a production system should be treated as a high security risk.