Skip to main content
Back to Blog
automationsupply-chain-attackarch-linux-aurcredential-stealerdevsecopspkgbuildsonatypeorphaned-packages

The AUR Hijack Shows Package Trust Is Broken: 400+ Orphaned Projects Weaponized Against Developers

Atomic Arch hijacked 400+ orphaned AUR packages to deliver a Rust credential stealer targeting developer machines — an AUR package supply chain attack.

Zyfolks Team ·

Attackers didn’t break Arch Linux this week — they just adopted its abandoned children. Over 400 packages in the Arch User Repository were quietly taken over by people who waited for maintainers to walk away, then rewrote the build scripts to drop a Rust credential stealer onto every machine that compiled them. No exploit. No zero-day. Just patience and a busted trust model.

How the Atomic Arch Campaign Hijacked Trust Instead of Code

According to Sonatype, which named the campaign Atomic Arch and tracks it as Sonatype-2026-003775 (CVSS 8.7), the attackers targeted orphaned AUR projects — packages whose maintainers had stepped away — adopted them through normal channels, and edited the PKGBUILD or .install files to run npm install atomic-lockfile during the build. The npm package carried a preinstall hook that executed a bundled ELF named deps. The attackers also spoofed git commit metadata so changes appeared to come from a long-standing Trusted User, an account Arch later confirmed was never compromised.

Why it matters: this isn’t a vulnerability you can patch. The AUR’s trust model rewards package history and name continuity, not the identity of whoever happens to own the package today. Once an orphan is adopted, the new maintainer inherits all the reputation the old one built. A second wave using bun install js-digest, traced to the same publisher, shows attackers are already iterating the playbook.

If you’re a developer who runs yay -Syu weekly without reading PKGBUILDs, you’ve been treating community packages like vendor-signed software. Confirmed examples reported to the Arch mailing list include alvr and premake-git — packages real teams actually depend on. The prediction: expect copycats targeting Homebrew taps, AUR-equivalents on other distros, and abandoned VS Code extensions within months. Orphaned-project adoption is now an attack pattern, not a one-off.

What the Deps Payload Actually Steals From Developer Machines

Independent researcher Whanos reverse-engineered the payload and described a Rust credential stealer aimed squarely at developer workstations and build systems. It collects cookies, tokens, and local storage from Chromium-based browsers including Chrome, Edge, and Brave; session data from Electron apps like Slack, Discord, and Microsoft Teams; GitHub, npm, and HashiCorp Vault tokens; OpenAI/ChatGPT bearer material; SSH keys, known_hosts, and shell histories; and Docker, Podman, and VPN credentials. Stolen files are uploaded over HTTP to temp.sh, and command and control runs over a Tor onion service via a local loopback proxy.

Why it matters: this list is a developer’s entire working identity. A compromised laptop hands attackers your source repos, your CI secrets, your team chat, your model API keys, and your production access — all from one makepkg. The malware installs a systemd unit with Restart=always, copying itself under /var/lib/ if it has root or under ~/.config/systemd/user/ if not. It wants to come back.

One adopted package on an engineer’s AUR install and your GitHub org tokens, Vault sessions, and Slack cookies are exfiltrated before lunch. The take: stealers that target Vault tokens and Docker credentials specifically are no longer fringe — they’re built for the developer toolchain, and that tells you who attackers think is worth hitting.

Why the eBPF Rootkit Changes Cleanup Forever

Early write-ups oversold the eBPF rootkit, but the cleanup implications are real. The rootkit is optional and only loads when the binary already has root with the right capability — it’s not a privilege-escalation vector. When it does activate, it hides the malware’s processes, process names, and socket inodes from standard tools using pinned BPF maps named hidden_pids, hidden_names, and hidden_inodes, and it kills attempts to attach a debugger. The binary also stages a second file tied to monero-wallet-gui that analysis flags as a possible cryptominer.

Why it matters: removing the AUR package is no longer enough. A package manager can delete the files it knows about, but it cannot prove a host is clean after a rootkit-capable payload has executed. eBPF rootkits weaponize a subsystem that defenders rely on for observability, which means the same telemetry tools you’d use to investigate get blinded by the thing you’re investigating.

If you ran a flagged package as root — even once, even during a build that errored — the only honest cleanup path is reinstall from trusted media. If it ran as your normal user, rotate everything: browser sessions, SSH keys, GitHub and npm tokens, Slack/Teams/Discord sessions, Vault tokens, Docker and Podman credentials, and cloud keys. Hunt for unknown systemd services and inspect /sys/fs/bpf/ for those three map names. The take: eBPF rootkits will become a checklist item in every IR runbook by year-end, and most teams aren’t ready for that.

How Adoption Attacks Reshape Software Supply Chain Defense

The same trick hit an abandoned PDF-viewer AUR package back in 2018. The 2026 version just scaled it up — part of a broader run of software supply chain attacks that hijack orphaned projects to inherit trust rather than typosquatting to trick users. Sonatype’s initial count of 20+ packages climbed past 408 within a day as community trackers grepped the AUR git mirror. The atomic-lockfile npm package itself had only 134 weekly downloads on Socket before removal, which tells you the AUR build path — not npm — was the real distribution channel.

Why it matters: typosquatting is a noisy, detectable pattern. Adoption attacks look identical to legitimate maintainer transitions, which happen constantly in open source. The defender’s signal is no longer “weird name” — it’s “recently adopted package” or “long-dormant project suddenly active.” Whether package registries need cryptographic identity tied to maintainer changes is now a real debate, and the trade-offs between cryptographic ledgers and traditional package databases are suddenly practical.

If you maintain internal mirrors or vendor open source aggressively, audit which of your dependencies have changed hands recently. The prediction: within 12 months, at least one major package registry will ship maintainer-change attestations as a default-on feature, and security tooling will start flagging recently-adopted dependencies the way it currently flags unsigned commits.

FAQ

Q: What is the Arch User Repository (AUR) and why was it targeted? A: The AUR is Arch Linux’s community-driven package collection, separate from the official Arch repositories, which were not affected. It was targeted because anyone can adopt an orphaned package and edit its build scripts, inheriting whatever trust the previous maintainer had built up.

Q: How do I know if I’m affected by the Atomic Arch campaign? A: Check any AUR package installed or updated on or after June 11 against the community-maintained affected-package lists. Grep your build history and caches for npm install atomic-lockfile, bun install js-digest, and the payload path src/hooks/deps. The main payload’s SHA-256 is 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b.

Q: Is removing the malicious package enough to clean up? A: No. If the payload ran as your user, rotate every credential it could touch and hunt for systemd persistence units. If it ran as root, assume the eBPF rootkit deployed and reinstall from trusted media — there is no reliable way to verify the host otherwise.

Key Takeaways

  • Audit any package whose maintainer changed recently before trusting it, regardless of how long the project itself has existed.
  • Treat developer workstations as credential vaults, not endpoints — a single hijacked build script can expose your entire toolchain identity.
  • Add /sys/fs/bpf/ inspection and user-scoped systemd unit checks to your standard incident response playbooks now, before eBPF rootkits become common.
  • Push your team to read PKGBUILDs and install hooks for adopted or newly-active packages; if the build instructions aren’t legible, the package isn’t installable.
  • Expect package registries to ship maintainer-change attestation features within the next year, and start designing internal mirrors that flag adoption events today.

Have a project in mind?

Tell us what you're building — we reply within 24 hours.