Extensive Supply Chain Attack Compromises Over 400 Arch User Repository Packages, Deploying Advanced Credential Stealer and eBPF Rootkit.

In a sophisticated supply chain attack that sent ripples through the open-source community, malicious actors successfully infiltrated the Arch User Repository (AUR) this week, compromising over 400 community-maintained packages. The attackers surreptitiously rewrote the build scripts of these packages, embedding a credential-stealing malware designed to target unsuspecting users who installed or updated them. This incident underscores a significant vulnerability in community-driven software ecosystems, where established trust models can be exploited to propagate highly potent malware.

The Genesis of the Attack: Exploiting Trust in the AUR

The Arch User Repository (AUR) is a vital component of the Arch Linux ecosystem, serving as a community-driven collection of package descriptions (PKGBUILDs) that allow users to compile software from source or retrieve pre-compiled binaries not available in the official repositories. Unlike the official Arch Linux repositories, which are rigorously vetted by trusted maintainers, the AUR operates on a more decentralized model, relying heavily on community contributions and mutual trust. This distinction is crucial, as the official Arch repositories remained unaffected by this specific campaign.

The attack, which security firm Sonatype dubbed "Atomic Arch," began to surface around June 11th. It did not leverage a zero-day vulnerability or a sophisticated exploit against Arch’s core infrastructure. Instead, it meticulously targeted the inherent trust model of the AUR. Attackers identified and adopted numerous "orphaned" packages—projects whose original maintainers had become inactive, leaving them open for new stewardship. This tactic allowed the malicious actors to inherit the established reputation and update privileges associated with these packages, circumventing typical scrutiny applied to new or unknown contributions.

Once a package was adopted, the attackers subtly modified its PKGBUILD or .install scripts. These scripts dictate how a package is built and installed on a user’s system. The insidious change involved adding instructions to execute external commands, specifically npm install atomic-lockfile during the build process of the first wave, and bun install js-digest for the second. These commands pulled malicious npm and bun packages, respectively, alongside legitimate dependencies, effectively camouflaging the true intent. To further enhance their deception, the attackers spoofed Git commit metadata, making it appear as though these changes originated from long-standing maintainers, a claim later debunked by an Arch Linux Trusted User who confirmed no legitimate accounts were compromised.

Unmasking the Malicious Payload: A Deep Dive into the Credential Stealer

Independent security researcher Whanos conducted a preliminary reverse-engineering analysis of the primary payload, an ELF binary named deps, which revealed it to be a sophisticated Rust-based credential stealer. This choice of language, Rust, is notable for its memory safety and performance, often making it a preferred choice for modern malware development due to its difficulty in reverse engineering compared to other languages. The malware was explicitly designed to target developer workstations and build systems, harvesting a wide array of sensitive information:

• SSH Keys: Critical for secure remote access to servers and code repositories.
• GPG Keys: Used for signing commits, encrypting communications, and verifying software integrity.
• Cloud Provider Credentials: Including AWS, GCP, Azure, and DigitalOcean access tokens, potentially allowing attackers to compromise cloud infrastructure.
• Cryptocurrency Wallet Data: Keys and seed phrases for various digital currencies.
• Browser Data: Including cookies, login credentials, and browsing history from popular web browsers.
• VPN Configuration Files: Potentially exposing access to corporate networks.
• Environment Variables: Often containing API keys, database credentials, and other sensitive configuration data.

The stolen data was then exfiltrated over HTTP to temp.sh, a legitimate file-sharing service often abused by threat actors. For command and control (C2) communications, the malware employed a more stealthy approach, routing traffic through a Tor onion service via a local loopback proxy, providing a significant layer of anonymity for the attackers and complicating tracking efforts.

Persistence and Evasion: The Role of eBPF and Systemd

Beyond data exfiltration, the malware incorporated robust mechanisms for persistence and evasion. For persistence, it established a systemd service configured with Restart=always. If executed with root privileges, it copied itself to /var/lib/ and installed a unit file under /etc/systemd/system/. For non-root users, it utilized the user’s home directory and a per-user unit under ~/.config/systemd/user/. This dual-mode persistence ensures the malware’s survival across reboots, regardless of the initial execution context.

A particularly advanced feature, initially overhyped in early reports, was the inclusion of an eBPF (extended Berkeley Packet Filter) rootkit. It’s crucial to clarify that this eBPF component was optional and not used for privilege escalation. It only activated if the binary already possessed root privileges and the necessary Linux capabilities. When active, its primary function was to obscure the malware’s presence from standard system monitoring tools. It achieved this by hiding its own processes, process names, and socket inodes using pinned BPF maps (e.g., hidden_pids, hidden_names, hidden_inodes). Furthermore, the rootkit actively detected and thwarted attempts to attach debuggers, making forensic analysis significantly more challenging.

The presence of this eBPF rootkit dramatically alters cleanup advice. Simply removing the compromised AUR package is insufficient. Once the payload has executed, especially with root privileges, a package manager cannot guarantee the system’s integrity. A full system reinstallation or a deep forensic analysis by an experienced professional becomes the only reliable method to ensure complete remediation. The analysis also flagged the staging of a second file tied to monero-wallet-gui, which security researchers indicated as a potential, unanalyzed cryptominer. The combination of a smash-and-grab credential stealer with an eBPF rootkit is an unusual and potent blend, highlighting the sophistication of the attackers.

Scope and Escalation: Two Waves of Attack

Sonatype’s initial report identified more than 20 hijacked packages. However, the true scale of the compromise rapidly became apparent as community trackers and the Arch Linux aur-general mailing list thread diligently cataloged affected packages. Within a day, the number surged past 400. Master lists, compiled by grepping the AUR Git mirror, indicated approximately 408 unique packages, with consolidated lists continuing to grow as the investigation unfolded.

The primary malicious npm package, [email protected], showed only 134 weekly downloads on Socket before it was removed from the registry. This relatively low download count for the npm package itself underscores that the real exposure stemmed from the AUR build path, where users were unknowingly executing the malicious npm install command as part of their package installation process, rather than directly installing the atomic-lockfile npm package.

A second wave of the attack was subsequently identified, employing a different malicious dependency: bun install js-digest. This second wave originated from a separate set of accounts, though community trackers linked them to the same npm publisher responsible for atomic-lockfile, suggesting a coordinated campaign by the same threat actors. The js-digest payload was a distinct binary, identifiable by its unique hash, and was also confirmed to be malicious. The full extent of this second wave is still being assessed, with early breakdowns listing a few dozen packages, while broader grep-based searches of the AUR mirror indicate potentially higher numbers, possibly including churn as malicious commits are identified and removed. Users are advised to check for indicators related to both atomic-lockfile and js-digest.

Official Response and Community Mitigation Efforts

In response to the widespread compromise, Arch Linux maintainers have taken decisive action. This includes systematically resetting the malicious commits to their clean states, banning the accounts responsible for the malicious package adoptions and modifications, and actively soliciting user reports of any other suspicious packages via the aur-general mailing-list thread.

For users who may have been affected, immediate action is paramount. The published lists of compromised packages, while growing, should be treated as incomplete. Proactive steps are essential:

1. Check for Compromise: Review your pacman.log (typically located at /var/log/pacman.log) for any AUR package installations or updates that occurred on or after June 11th. Cross-reference these against the community-compiled lists of affected packages.
2. Rebuild from Clean Sources: If an installed package is on the affected list, it is strongly recommended to remove it and then rebuild it from a trusted, uncompromised source. This involves carefully inspecting the PKGBUILD file to ensure no malicious changes are present before building.
3. Prioritize Reinstallation: For systems that installed a compromised package with root privileges, a full operating system reinstallation is the most secure course of action. This is particularly crucial given the potential for the eBPF rootkit to conceal malware components and the difficulty in guaranteeing a clean system post-execution of such a sophisticated payload.
4. Rotate Credentials: Immediately rotate all sensitive credentials, including SSH keys, GPG keys, cloud provider API keys, and any other developer secrets. Assume that any secrets present on a potentially compromised system have been stolen.
5. Monitor for Indicators: Utilize the main payload’s SHA-256 hash (6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b) and the full indicator set, including the onion C2 host, detailed in the ioctl.fail analysis, to scan systems for traces of the malware.

Broader Implications and Lessons for Supply Chain Security

This incident serves as a stark reminder of the escalating threat of supply chain attacks targeting open-source software ecosystems. The "Atomic Arch" campaign echoes similar past events, such as the compromise of a PDF-viewer package in the AUR back in 2018, but significantly scales up the scope and sophistication. These attacks increasingly bypass traditional security measures by exploiting inherent trust within community-driven projects, opting for "inheritance of trust" rather than relying on typosquatting or direct exploits.

The vulnerability exploited here lies at the heart of the AUR’s trust model: it historically placed significant reliance on a package’s name and history, rather than rigorously scrutinizing the current maintainer, especially for adopted packages. A package that has recently changed hands, or one that suddenly introduces new and complex install hooks, now warrants the same level of suspicion as a package from an entirely unknown source.

The CVSS score of 8.7 (tracked as Sonatype-2026-003775) assigned to this campaign reflects its severe impact potential, capable of leading to significant data breaches and system compromise. This event necessitates a re-evaluation of security practices within community repositories and among users. It highlights the critical need for:

• Enhanced Maintainer Vetting: More stringent processes for adopting orphaned packages and ongoing monitoring of maintainer activity.
• Automated Security Scans: Integration of automated tools to scan PKGBUILD and .install scripts for suspicious commands or changes.
• User Vigilance: Encouraging users to meticulously review PKGBUILD files before building, particularly for packages from the AUR, and to be wary of sudden, unexplained changes in build processes.
• Isolation and Sandboxing: Employing sandboxed environments (e.g., containers, virtual machines) for building and testing AUR packages to limit potential system compromise.
• Least Privilege: Ensuring that package builds and installations are performed with the minimum necessary privileges.

The "Atomic Arch" attack is not merely a footnote in cybersecurity history; it represents a significant escalation in the ongoing battle to secure the software supply chain. Its impact will undoubtedly shape future discussions and developments in how open-source communities manage trust, security, and the adoption of orphaned projects. Vigilance, technical scrutiny, and robust community collaboration remain the strongest defenses against such evolving threats.