Over 400 Arch Linux AUR Packages Compromised to Deploy Infostealer and eBPF Rootkit

In a significant security breach, attackers have compromised over 400 packages in the Arch User Repository (AUR), a community-driven collection of software for Arch Linux. The attackers modified build scripts to deploy a credential-stealing malware on any machine that built these packages. This incident highlights vulnerabilities in trust models within open-source software ecosystems.

The malware, written in Rust, is designed to harvest sensitive developer information. When executed with root privileges, it can also load an eBPF rootkit to conceal its presence. The AUR operates independently from Arch Linux’s official repositories, which were not impacted by this attack.

Users who installed or updated any AUR package on or after June 11 are urged to verify their installations against the growing list of affected packages. This list is extensive and still being compiled, underscoring the attack’s scale.

Trust Exploitation Over Software Flaws

This incident exemplifies a targeted attack on the trust model rather than exploiting a specific software vulnerability. The compromised packages retained their original names and histories, preserving the trust users had in them. The only alteration was in the build instructions, which were modified to include malicious code.

The attackers took advantage of abandoned packages, editing their build files to execute the payload. Sonatype, which has dubbed this operation “Atomic Arch,” noted that the attackers specifically targeted orphaned projects—packages with maintainers who had ceased activity, making them vulnerable to takeover.

To further obscure their actions, the attackers manipulated git commit metadata, making it appear as though the changes were made by a long-standing maintainer. An Arch Linux Trusted User later confirmed that the account in question had not been compromised.

Once a package was hijacked, its PKGBUILD or .install script was altered to execute npm install atomic-lockfile during the build process. This command pulled in the malicious npm package alongside legitimate ones, effectively camouflaging the threat. The package, atomic-lockfile@1.4.2, contains a preinstall hook that executes a bundled Linux ELF file named deps, which runs upon building the package.

Functionality of the Malware

Independent researcher Whanos has reverse-engineered the deps payload, identifying it as a credential stealer targeting developer workstations and build systems. The malware is capable of collecting:

• Cookies, tokens, and local storage from Chromium-based browsers, including Chrome, Edge, and Brave.
• Session data from Electron applications like Slack, Discord, and Microsoft Teams.
• Tokens from GitHub, npm, and HashiCorp Vault, as well as OpenAI/ChatGPT bearer tokens and account metadata.
• SSH keys, known_hosts, and shell histories.
• Credentials for Docker, Podman, and VPN profiles.

Stolen data is transmitted over HTTP to a service hosted on temp.sh, while command and control operations are conducted through a Tor onion service using a local loopback proxy.

For persistence, the malware installs a systemd service with a Restart=always directive. When executed with root privileges, it copies itself to /var/lib/ and creates a unit file under /etc/systemd/system/. If run as a normal user, it uses the home directory and a user-specific unit under ~/.config/systemd/user/. This ensures the malware can re-establish itself after a reboot.

Early analyses may have overstated the role of the eBPF rootkit, which is optional and only activates if the binary already has root access and the necessary capabilities. When operational, it obscures the malware’s processes, names, and socket inodes from standard monitoring tools, employing pinned BPF maps labeled hidden_pids, hidden_names, and hidden_inodes. It also disrupts attempts to attach debuggers.

This complexity necessitates a reevaluation of cleanup strategies. Simply removing the AUR package is insufficient once the payload has executed. While a package manager can delete known files, it cannot guarantee the system’s cleanliness after a rootkit-capable payload has run.

Additionally, the binary stages a second file associated with monero-wallet-gui, flagged as a potential, unanalyzed cryptominer. The combination of a rootkit and a credential-stealing mechanism raises concerns about the attack’s severity.

Scope and Subsequent Waves

Sonatype’s initial report identified more than 20 compromised packages. Within a day, community trackers and the Arch mailing list had cataloged over 400, with one master list indicating approximately 408 affected packages. The atomic-lockfile npm package itself had only 134 weekly downloads before being removed from the registry, indicating that the primary exposure stemmed from the AUR build process rather than npm installations.

A subsequent wave of attacks utilized bun install js-digest, linked to different accounts but associated with the same npm publisher as atomic-lockfile. This payload is a distinct binary, flagged as malicious by the community.

The extent of this second wave is still under investigation. Initial reports listed a few dozen packages, but later searches of the AUR mirror revealed much higher numbers, potentially including transient changes as commits were removed. Users are advised to check for both atomic-lockfile and js-digest.

Recommended Actions for Users

In response to this incident, Arch maintainers are working to reset the malicious commits and ban the accounts involved. Users are encouraged to report any suspicious packages in the ongoing mailing-list thread.

Given the evolving nature of this situation, users should treat the published list of affected packages as incomplete. Recommended actions include:

• Verify any AUR package installed or updated on or after June 11 against community package lists and detection scripts. Check recent build history and caches for npm install atomic-lockfile, bun install js-digest, and the payload path src/hooks/deps.
• If a flagged package has been executed, treat the host as compromised. Rotate all credentials that may have been accessed, including browser sessions, SSH keys, GitHub and npm tokens, and any cloud keys.
• Investigate for persistence mechanisms. Look for unknown systemd services (both system units and ~/.config/systemd/user/) and unexpected files in /var/lib/. Inspect /sys/fs/bpf/ for the maps hidden_pids, hidden_names, and hidden_inodes, and review outbound connections to Tor and upload services.
• If the package was executed with root privileges, assume the presence of a rootkit and reinstall the operating system from trusted media. Trust cannot be restored otherwise.
• Moving forward, scrutinize the PKGBUILD and any .install hooks before building packages, especially those that have been recently adopted or reactivated after a period of dormancy. If the build instructions are unclear, refrain from installing the package.

For detection purposes, the SHA-256 hash of the main payload is 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b. A comprehensive set of indicators, including the onion C2 host, is available in the analysis by Whanos.

This incident mirrors previous attacks on abandoned packages, such as a PDF viewer package in 2018, but has escalated significantly, reflecting a broader trend of supply-chain attacks that exploit orphaned projects to inherit trust rather than relying on typosquatting. The affected list remains incomplete, and no CVE has been assigned yet. Sonatype is tracking this campaign as Sonatype-2026-003775, with a CVSS score of 8.7.

The attack’s success underscores the need for vigilance in the AUR, where trust is often placed in a package’s name and history rather than the current maintainer. Newly adopted packages or those that suddenly exhibit new install hooks should be treated with the same caution as unfamiliar software.

Source: thehackernews.com

Keep reading for the latest cybersecurity developments, threat intelligence and breaking updates from across the Middle East.