The betrayal of the AUR: how an attack on the supply chain turned orphaned packages into a theft of credentials and hidden persistence

The latest wave against the Arch User Repository (AUR) forces us to rethink how we trust community packages: attackers took control of hundreds of "orphan" packages, modified only their construction instructions (PKGBUILD / .install) and managed to get development machines to run a Rust binary designed to steal credentials. The key part of the attack was not a failure in Arch or a zero-day, but the exploitation of the AUR's confidence model: name and history intact, changed maintainer.

What happened in technical terms: the adversaries adopted abandoned packages, inserted calls such as npm install atomic-lockfile or bun install js-digest during the compilation and thus dragged a malicious npm package that runs an ELF called deps in the build process. This binary collects tokens from browsers and electron apps, SSH keys, container credentials, Vault data and even OpenAI / ChatGPT material, and exfilters to public services (temp.sh). If you run with root privileges, you can install a persistent service and optionally load an eBPF module that hides processes, names and sockets; the rootkit-eBPF is accessory but increases gravity because it complicates the cleaning. For technical analysis and set of indicators see the Community report and forensic analysis of the sample: Sonatype - Atomic Arch and ioctl.fail - analysis and signals.

Practical implications: if you built or updated any package from the AUR since June 11, it is not enough to trust that deleting the manager's package leaves the system clean. Once the payload is run with sufficient privileges, the attacker can leave persistence, steal secrets and, in the worst case, hide his presence with eBPF. The initial numbers of committed packages reached hundreds and continue to fluctuate: the exposure route was not the direct download of the npm package (atomic- lockfile had very few weekly downloads), but the build channel on the AUR.

What to check immediately on a suspicious team: check the log and caches of makepkg / build (search for traces of npm install atomic-lockfile, bun install js-digest or routes such as src / hooks / deps), inspect systemd units at both system and user level for unknown services, explore / var / lib / by artifacts and / sys / fs / bpf / by maps named as hidden _ pids, hidden _ names or hidden _ inodes. Monitor unusual outgoing connections, especially to nodes Tor or services of rise, and compare suspicious binary with hashes published by researchers. If the binary ran with root, the wise thing is to make the machine commitment and reinstall from means of confidence.. The AUR and Arch's official repos are different; the official repos were not affected, but that does not clean up a compromised local system.

Containment and Recovery Actions: If a compilation ran any of the payloads, immediately roll any secret that malware may have read: sessions and browser cookies, GitHub and npm tokens, SSH keys, Vault credentials, Docker / Podman credentials, VPN profiles and cloud keys. Revoke and regenerate keys and tokens from another known clean machine. Search and remove unknown systemd services and files in persistent locations; however, remember that a rootkit capable of hiding could prevent reliable detection. Therefore, when there is a sign of execution with privileges, the only safe way to regain confidence is to reinstall the system from verified means and restore data from previous and examined backups.

Medium-term and long-term prevention: treat newly adopted packages or which have remained asleep as potentially risky. Do not build AUR blindly: read the PKGBUILD and the .install hooks before running makepkg, and if you do not understand the build steps refrain. Valore build packages in isolated environments: ephemeral virtual machines, containers or chroots without access to sensitive credentials. For projects maintained by the community, observe the maintenance history and signs of recent adoption; the attackers exploit precisely that window of trust. Official resources and security guides in AUR are available in the Arch documentation: AUR and the Wiki of Arch on package policy and security.

Finally, the lesson is structural: supply chains that delegate confidence in names and history without validating the identity and the intention of the maintainer are fragile. Teams should incorporate controls that reduce the blast radius of unreliable building: role separation, dedicated compilation environments, human review of build scripts and frequent rotation of secrets. For technical indicators, hashes and the consolidated list of affected packages follow public research (the analysis and the whole of IOCs are collected by the community and by researchers such as those linked above).