400+ Arch Packages Got Backdoored With a Rootkit Stealer This Week. If You Daily-Drive Arch, Manjaro, or EndeavourOS, Here's the 10-Minute Saturday Check.

Around June 11, researchers caught a campaign they're calling Atomic Arch: more than 400 packages in the Arch User Repository were compromised, their build scripts rewritten to install a Rust credential stealer with optional eBPF rootkit capabilities. The attackers didn't break into anything. They used a feature. The AUR lets you adopt orphaned packages (projects whose original maintainers walked away) through a normal, sanctioned process, and that's exactly what they did, at scale, then added a preinstall script that pulls a malicious npm package called atomic-lockfile, which drops an ELF payload named deps to harvest credentials.

If you run plain Arch, Manjaro, EndeavourOS, CachyOS, or any other derivative that taps the AUR, and you installed or updated AUR packages in the last few days, this is your problem and the fix is a ten-minute job you should do before you close the laptop this weekend.

Why the AUR is structurally exposed

The AUR isn't a malicious system and this isn't a flaw to be patched. It's a user repository, and its convenience is its attack surface. Three properties stack up into the problem.

It's community-maintained, so there's no central review gate between a maintainer and your machine. Installing a package runs its build script (the PKGBUILD) on your system, as you, which is the entire point: the AUR builds from source on your box. And orphaned-package adoption is a designed feature, because abandoned packages need new maintainers, so claiming one is a normal request, not a red flag. Put those together and you get the attack: claim hundreds of abandoned packages legitimately, edit the build scripts you now control, and wait for yay -S whatever to run them.

The solo dev who treats yay -S like apt install is the target. Those are not the same operation. apt install pulls a signed binary from a reviewed repository. yay -S downloads a script a stranger wrote and runs it on your machine. People who know that intellectually still forget it at 11pm when they just want the package.

The 10-minute check

Don't overthink this. Three steps.

First, list every foreign (AUR-installed) package on your system:

pacman -Qm

That gives you the set of packages that didn't come from the official, signed Arch repositories, the only ones in scope here. Cross-reference that list against the published roster of compromised packages; the community has consolidated detection lists, including a GitHub repo built specifically for this incident.

Second, audit what you installed or rebuilt between June 10 and 12. Check your AUR helper's logs and your PKGBUILD history for anything touched in that window. If you ran an AUR update in those days, assume you pulled whatever the package said to pull at that moment, not whatever it said last month.

Third (and this is the one people skip because it's annoying), if any flagged package was on your machine, rotate everything a credential stealer would have grabbed. Browser-saved passwords, SSH keys, API tokens, cloud access keys. All of it.

If you got hit, the credentials are already gone

This is the part to be clear-eyed about. A credential stealer's whole job is to read your secrets and exfiltrate them before you notice. By the time you're running pacman -Qm, the theft, if it happened, already happened. There's no "clean it up and you're fine": removing the package stops further damage, it does not un-steal what's already left.

So rotation isn't optional cleanup you do if you have time. It's the actual remediation. Removing the package and rebooting feels like fixing it and isn't, because the value was never the malware sitting on disk: it was the keys it read on the way in. The eBPF rootkit angle makes this worse: kernel-level stealth means you can't fully trust the machine to tell you what ran on it. If a flagged package was installed and you care about what those credentials protect, the conservative move is to rotate first and investigate second.

What I'd actually do going forward

Read PKGBUILDs before you install. Yes, every time, and yes, it's friction: that friction is the security model the AUR is built on, and skipping it is opting out of the only review the system has. Your AUR helper has a flag to show you the build script and diffs before it runs; turn it on and actually look. Prefer official-repo packages over AUR ones when both exist. And keep the genuinely sensitive credentials off your daily-driver desktop entirely (a hardware key for SSH, a separate machine or a sandbox for anything that touches production) so that the worst case of "I ran a bad PKGBUILD" is a reinstall, not a breach.

The honest counter-take: most people reading this installed none of the 400 packages, will find a clean pacman -Qm, and will conclude the warning was overblown, and for them, it was. The base rate of any single user hitting a specific compromised package out of the AUR's enormous catalog is low, and I'm not going to pretend the median Arch user is owned this week, because they're not. But the check costs ten minutes and the downside it's guarding against is every credential on your machine. That's the cleanest risk-reward in computing: ten minutes against your entire keychain. Run pacman -Qm before you close the laptop. If it's clean, you've lost ten minutes. If it isn't, you just found out before the person holding your keys did something with them.

Author

Lukas

@lukcombinator

Sources

• Over 400 Arch Linux packages compromised to push rootkit, infostealer (BleepingComputer)
• Over 400 Arch Linux AUR Packages Hijacked to Deploy Infostealer and eBPF Rootkit (The Hacker News)
• aur-malware-check: detection tools for the June 2026 atomic-lockfile AUR attack (GitHub)
• The Arch Linux AUR had over 400 packages compromised with malware (GamingOnLinux)