Arch Linux AUR Packages Hijacked: What Happened and How to Check Your System

In mid-June, a coordinated campaign compromised more than 400 Arch Linux packages in the Arch User Repository (AUR), rewriting their build scripts to deliver a Rust-based infostealer. The malware harvests developer secrets and, when executed with root privileges, installs an eBPF rootkit to evade detection. Unlike traditional supply-chain attacks that exploit software vulnerabilities, this attack abused the trust model of the AUR community by hijacking package build instructions without altering the package binaries themselves. Users who built or updated these packages after June 11 may have unknowingly executed malicious code on their systems.

The attack targeted orphaned packages—those left unmaintained by their original authors—and repurposed them to deliver malware. By editing PKGBUILD or .install scripts, attackers injected commands that pulled a malicious npm package during the build process. This npm package, atomic-lockfile@1.4.2, included a preinstall hook that executed a bundled Linux ELF binary named deps. Anyone building the compromised package would automatically run this binary, which installed a credential stealer designed to collect sensitive files and transmit them via HTTP to a temporary file-sharing service. Command and control was routed through a Tor onion service via a local loopback proxy, making the traffic harder to trace.

How the Attack Exploited the AUR Trust Model

The Arch User Repository (AUR) is a community-driven collection of package build scripts for Arch Linux. Unlike official repositories maintained by Arch developers, the AUR relies on user-contributed packages and open adoption of orphaned projects. Attackers exploited this model by identifying abandoned packages and submitting new maintainers to take over their build scripts. Once adopted, they edited the PKGBUILD or .install files to include malicious build steps.

Notably, the attackers went beyond simple hijacking. They manipulated Git commit metadata to make it appear as though changes were made by a long-standing trusted user. This spoofing technique added legitimacy to the malicious edits, making them harder to spot during code review. Arch Linux confirmed that the impersonated account was not compromised, highlighting that the deception occurred at the social and process level rather than through a technical breach.

The core of the attack was not a software flaw but a misuse of trust. The package names, version histories, and even the binary contents remained unchanged. Only the build instructions were altered. This meant that users installing or updating these packages would receive exactly what they expected—except that the build process now executed hidden malicious code. The attackers leveraged the fact that many developers build AUR packages from source rather than installing prebuilt binaries, trusting the process to be safe.

The Malicious Payload: Credential Theft and Rootkit Persistence

The delivered malware is a Rust-based binary designed to harvest developer secrets from workstations and build systems. Its primary function is to collect sensitive files such as SSH keys, configuration files, and credentials stored in browsers or password managers. The stolen data is exfiltrated over plain HTTP to a temporary file-sharing service, temp.sh, which does not require authentication. This approach ensures rapid data exfiltration but leaves traces in network logs that defenders can detect.

Persistence is achieved through systemd services, with behavior that adapts based on privilege level. When executed with root, the malware copies itself to /var/lib/ and installs a system service with Restart=always to ensure survival across reboots. Without root, it uses the user’s home directory and installs a per-user systemd unit under ~/.config/systemd/user/. This dual-mode persistence strategy increases the likelihood that the malware survives reboots and remains active even if the user lacks administrative privileges.

In addition to credential theft, the malware includes an eBPF rootkit component. eBPF (Extended Berkeley Packet Filter) is a Linux kernel feature originally designed for networking and observability. Attackers abuse this feature to load custom programs into the kernel, allowing them to hide processes, files, and network connections from standard monitoring tools. The rootkit’s presence means that even if the malware is detected, traditional tools like ps or top may not reveal its activities. This advanced technique underscores the growing sophistication of Linux-targeting malware and the challenges defenders face in detecting and removing such threats.

Affected Packages and How to Identify Them

The list of compromised packages is extensive and continues to grow as new hijacked packages are discovered. Early confirmed examples include alvr and premake-git, but the campaign likely spans hundreds of additional packages across various categories, including development tools, libraries, and utilities. Because the attack relies on hijacking orphaned packages, the affected names are diverse and not limited to any single software domain.

Arch Linux maintains an ongoing list of affected packages, which is updated as new hijacks are reported. Users are advised to check any AUR packages they have installed or updated since June 11 against this list before continuing to trust the systems. It is important to note that only packages built from source using the compromised PKGBUILD scripts are affected. Installing prebuilt binaries from official repositories or trusted third parties remains safe.

The process of verifying affected packages involves checking the AUR web interface or using command-line tools like yay or paru to inspect build scripts. Users should review the PKGBUILD and .install files for suspicious commands, particularly those invoking npm install or running arbitrary binaries during the build process. Any package that includes steps to install or execute atomic-lockfile or similar npm packages should be treated as compromised.

What Happened During the Build Process

When a user builds a compromised AUR package, the PKGBUILD script executes a series of commands defined by the attacker. One of the key steps is running npm install atomic-lockfile@1.4.2, which pulls in a malicious npm package alongside legitimate dependencies. This npm package includes a preinstall hook—a script that runs automatically before the package is installed. The preinstall hook executes a bundled ELF binary named deps, which is the actual malware payload.

The deps binary then runs silently in the background, collecting sensitive data and preparing to install itself persistently. Because this execution happens during the build process, users may not notice any immediate symptoms unless they monitor system activity closely. The malware does not alter the final installed software; it only runs during compilation, making detection more difficult. This highlights a critical blind spot in the trust model: users assume that the build process is safe, but compromised scripts can execute arbitrary code with the same permissions as the builder.

The use of npm as a delivery vector is notable because it blends in with typical build dependencies. Many AUR packages rely on npm for frontend or JavaScript tooling, so the presence of an npm package does not immediately raise suspicion. Attackers exploited this familiarity to camouflage their malicious code within legitimate-looking build steps.

Detection and Response: What to Do If You’re Affected

If you have built or updated AUR packages since June 11, the first step is to check whether any of them appear on the official list of compromised packages. If a package is confirmed affected, do not rebuild or reinstall it. Instead, remove the package immediately using pacman -Rns, which will uninstall the software and its configuration files. After removal, inspect your system for signs of compromise.

Look for unfamiliar systemd services, especially those named with generic or deceptive names. Check both system-wide services in /etc/systemd/system/ and user services in ~/.config/systemd/user/. The malware creates services with Restart=always, so even if you stop the service, it will likely restart automatically. Use systemctl list-units --type=service to review active services and look for anything unexpected.

Next, scan for the presence of the deps binary or related files. The malware may be located in /var/lib/ or within the user’s home directory under ~/.local/ or ~/.cache/. Use find or locate to search for the filename deps or any recently modified binaries. Also review network connections for outgoing HTTP traffic to temp.sh or connections to Tor onion services via local proxies. Tools like ss, netstat, or Wireshark can help identify unusual network activity.

If you suspect deeper compromise, consider isolating the affected machine from trusted networks and rebuilding it from a known-good state. This is especially important for development workstations or build servers that may have handled sensitive credentials. Rotate all passwords, SSH keys, and API tokens that were accessible on the system. The credential stealer was designed to harvest such secrets, so assume they have been compromised.

Long-Term Implications for the AUR and Open-Source Supply Chains

This incident exposes vulnerabilities in the AUR’s trust model, which relies heavily on community participation and package adoption. While the AUR provides flexibility and access to a vast ecosystem of software, it also introduces risks when orphaned packages are hijacked. The attack did not exploit a technical flaw but rather the social and procedural aspects of package maintenance. This raises questions about how to better protect community repositories without stifling contribution.

One potential improvement is stricter adoption controls for orphaned packages. Requiring multi-party review or a minimum period of inactivity before allowing adoption could reduce the window for hijacking. Another approach is to deprecate or archive truly abandoned packages more aggressively, removing them from active search results to reduce their visibility to attackers. Arch Linux could also implement automated scanning of PKGBUILD scripts for suspicious commands, such as those invoking npm install or running untrusted binaries.

The broader open-source ecosystem must also reconsider how build-time dependencies are handled. The use of npm as a delivery vector highlights a larger trend where JavaScript tooling is integrated into non-JavaScript build processes. While convenient, this increases the attack surface. Projects should audit their dependency chains and consider whether certain npm packages are necessary or could be replaced with safer alternatives.

How Developers Can Protect Themselves Going Forward

For developers who regularly build software from source, especially on Arch Linux, several best practices can reduce risk. First, always review PKGBUILD and .install files before building or updating AUR packages. Look for unfamiliar commands, particularly those involving npm install, curl, or wget that fetch and execute binaries. If anything looks suspicious, do not proceed with the build.

Consider using a dedicated build environment, such as a virtual machine or container, to isolate the build process. This way, even if a package is compromised, the malware runs in a constrained environment and cannot access the host system. Tools like Docker or systemd-nspawn can create lightweight, disposable environments for building packages safely.

Enable auditing of system calls and file modifications during the build process. Tools like auditd or eBPF-based monitors can log suspicious activity and help detect when a build script deviates from expected behavior. While this adds overhead, it can provide early warning of compromise.

Finally, maintain a minimal set of AUR packages. Only build and install what is necessary, and avoid adopting packages that are clearly abandoned or have minimal usage. Regularly audit your installed packages and remove those no longer needed. A leaner system reduces the potential attack surface and makes it easier to spot anomalies.

What Arch Linux and the Community Are Doing

Arch Linux has responded by publishing and updating a list of affected packages and advising users to avoid rebuilding them. Community maintainers are reviewing recently adopted packages and removing suspicious ones. The incident has sparked discussions about improving package vetting, possibly through automated scanning or stricter maintainer requirements.

Independent security researchers have also contributed by reverse-engineering the malware and sharing indicators of compromise. Their work helps the community detect and remove infections more effectively. The collaborative response demonstrates the strength of open-source security culture, where transparency and shared analysis lead to faster mitigation.

Looking ahead, the Arch Linux team may introduce changes to the AUR submission process, such as mandatory waiting periods for new maintainers of orphaned packages or enhanced logging of build script changes. These measures aim to balance community openness with security, ensuring that the AUR remains a valuable resource without becoming a vector for widespread compromise.

Conclusion

The hijacking of over 400 Arch Linux AUR packages is a sobering reminder that trust in open-source ecosystems is not just about code integrity—it’s also about process and community oversight. This attack did not rely on a software flaw but on the manipulation of human trust and procedural gaps. The result was a stealthy credential stealer and rootkit delivered through seemingly legitimate build scripts.

For users, the immediate priority is to check whether any installed AUR packages are affected and to remove them if necessary. For the community, the incident underscores the need for stronger safeguards around orphaned packages and build-time dependencies. Developers must adopt stricter review habits and consider isolation strategies when building software from source.

As supply-chain attacks grow more sophisticated, the Arch Linux AUR incident serves as a case study in how attackers exploit trust models and automation. Vigilance, transparency, and proactive security measures remain the best defenses against such threats.