Your AUR Helper Is Not a Trust Boundary
The Arch User Repository hijack is a reminder that developer package feeds are not harmless convenience. Build scripts run code, and abandoned packages inherit trust too easily.
The dangerous part was not clever exploitation. It was package maintenance.
Attackers took over abandoned packages in the Arch User Repository, changed the build recipes, and waited for users to run the code for them. According to The Hacker News, the count passed 400 affected AUR packages as community trackers dug through the mirror. Sonatype tracks the campaign as Sonatype-2026-003775 and rated it CVSS 8.7.
That number matters, but the shape of the attack matters more. The official Arch repositories were not breached. This happened in the community repository, where users already know they are closer to the metal. But "closer to the metal" often turns into muscle memory: run the helper, skim the diff if you are feeling virtuous, accept the build, move on.
That is exactly where this attack lived.
The payload was in the recipe
The hijacked packages did not need a zero-day. They changed PKGBUILD or install scripts so the build process pulled a malicious npm package named atomic-lockfile. Its preinstall hook ran a bundled Linux ELF payload.
The reported payload is a Rust credential stealer aimed at developer machines and build hosts. The Hacker News, citing reverse engineering by independent researchers, says it collects developer secrets and sends stolen files over HTTP to temp.sh, with command and control routed through a Tor onion service via a local loopback proxy.
It also tries to persist with systemd. With root, it writes under /var/lib/ and creates a service in /etc/systemd/system/. Without root, it falls back to the user's home directory and a per-user systemd unit.
The eBPF rootkit detail is real but easy to misunderstand. The reporting says it does not grant root. It only activates when the payload already has root and the needed capability. When it does, it hides the malware's own processes and sockets from normal tools.
So the practical advice is grim but simple: if the payload ran as root, uninstalling the package is not a cleanup plan. You have to treat the host as potentially compromised.
Orphaned packages are trust debt
AUR has always relied on users taking responsibility for what they build. That is fine in theory. In practice, developer machines are now stuffed with SSH keys, cloud tokens, package registry credentials, CI secrets, password manager sessions, and agent credentials.
A build script on a laptop is no longer "just local". It can be one step away from production.
The attack also abused a very human shortcut: name recognition. A package that has existed for years feels safer than a new random package. But if the maintainer disappeared and someone else adopted it yesterday, the old name is just inherited trust.
That is the bit I would not wave away as an Arch-only problem. The same pattern shows up in npm, PyPI, browser extensions, Docker images, VS Code extensions, and abandoned GitHub projects. Attackers do not need to trick everyone. They need to find a stale package with enough habitual users and a build path that runs code.
What to do if you used AUR this week
If you installed or updated AUR packages on or after June 11, check the current affected package lists before trusting the machine.
Then look for the behaviors tied to this campaign:
- AUR build scripts invoking
npm install atomic-lockfileorbun install js-digest. - Unexpected systemd units under
/etc/systemd/system/or~/.config/systemd/user/. - Suspicious binaries copied into
/var/lib/or the user's home directory. - Network traffic to
temp.shor the published onion command-and-control indicators. - Developer secrets that may have been present on the machine at build time.
If the host built a compromised package as root, rotate secrets from a clean machine. SSH keys, GitHub tokens, package registry tokens, cloud credentials, deployment keys, CI tokens, anything an infostealer would care about. Do not rotate them from the suspected host and call it done.
For normal AUR use, the boring habit still helps: read the PKGBUILD and .install diff before building. Pay special attention when a package was recently adopted, suddenly adds install hooks, pulls from a new domain, invokes npm/bun/curl, or changes maintainer metadata in a way that does not match the project's history.
It is annoying. That is the point. Supply-chain defense is mostly about making the dangerous path slightly less automatic.
The bigger lesson
Developer convenience tools have become part of the security boundary.
AUR helpers, dependency installers, AI coding agents, CI runners, preinstall hooks, project templates, build scripts. They all sit in the same uncomfortable category: things we run because they save time, often before we have thought about what permissions they actually have.
The old mental model was "I am only installing a package." That is too soft now. A better one is: "I am letting a stranger's build recipe execute on a machine that probably has credentials."
Once you say it that way, the controls become obvious, even if they are boring: isolate builds, review scripts, avoid running helpers as root, pin what matters, remove stale packages, and keep sensitive credentials away from general-purpose developer workstations where possible.
None of that is glamorous. It is just less embarrassing than losing production credentials to an abandoned package you updated out of habit.