“Atomic Arch”: Nearly 900 AUR Packages Backdoored with a Developer-Targeting Infostealer and eBPF Rootkit

beanburrito

Active Member
Joined
May 14, 2026
Messages
139
Reaction score
206
Credits
1,062
As mentioned (but maybe overlooked by users) here, here, and here.

There's a great write up about it here:


"On June 11, someone going by the username arojas spent what was probably a quiet afternoon methodically adopting orphaned Arch User Repository packages and injecting them with malware. By the time the community caught on, 408 packages were already compromised. By the time this piece was being written, that number had crossed 900 and is still climbing.

Sonatype researchers have named the campaign Atomic Arch. It’s one of the largest AUR supply chain incidents on record, and the technical sophistication of the payload puts it well beyond your average package repository drive-by."

"If you’re not on Arch Linux, you’re not affected."

= Sections include:

How It Started: AUR’s Orphan Adoption Policy
The Infection Chain: How a PKGBUILD Becomes a Backdoor
The Payload: Meet deps
What it steals
Persistence: How It Digs In
The eBPF Rootkit: Why This Is Serious
Command and Control: Tor Onion Service
Threat Actor Infrastructure
Comprehensive Analysis
Detection & Response Guidance
What You Need to Do Right Now
The Bigger Picture


Hacker News Discussion
 
Last edited:


just checked my main system, I'm clear. thanks for the link! it's a nice writeup
 
Thanks for sharing! I did already read it and hear about it in several places. I replaced everything with verified Flatpaks, one I'm downloading the binary directly from the source, an official appimage and one I'm pulling the source and then building it myself. For the ones that aren't Flatpaks I created a desktop file myself so I can easily launch them, no more AUR needed.
 
 
I found these on another forum and one is also mentioned in the AUR-general mailinglist.
 
I found these on another forum and one is also mentioned in the AUR-general mailinglist.

ran the malware check scripts via https://github.com/lenucksi/aur-malware-check and tested clean a lot faster than manually checking since the list is now 1600+ packages... havent updated any of my secondary computers in a few weeks and I think I just wont for a while (they're mostly Arch derivatives)
 
Live by bleeding edge, die by bleeding edge. Arch users got burned pretty bad by this one.
Good lesson not to trust rolling release distros, or at least random user repos.
 
I wonder if it's possible to detect and deny any obfuscated code. If it's to be open source, there's really no reason to include obfuscated code. That is, by definition, going to make it more difficult to read and understand what the code is doing. That's the opposite of what we should expect in free (as in libre) software. We should expect the code to be easy to understand by someone versed in the programming language used by the author.

It seems like a difficult task to automatically evaluate this. There's zero chance that it could be reasonably done with human labor. It's simply too much code. Though, once reviewed, you might be able to do a differential check that'd narrow down the code that needs to be reviewed.

Evaluating source code for obfuscated code sounds like a task best suited for computers. With the wide variety of code, and the languages they use, it could be hard for a machine to accurately look at code to decide if it's obfuscated code or just code that it doesn't recognize. I guess it could flag something for human review, but I'm not willing to speak for someone else's time.
 
Live by bleeding edge, die by bleeding edge. Arch users got burned pretty bad by this one.
Good lesson not to trust rolling release distros, or at least random user repos.
It would be a mistake to apply the issues of the AUR to all rolling releases and then not trust rolling releases as a consequence. The AUR is a user-maintained community package repository without any central oversight for testing of packages or their interactions with other packages. The arch distro itself, as rolling release, is a curated distro with packages having been tested and integrated into a coherent system. Hence, it's not the "rolling release" that can't be trusted, but rather the AUR because of it's nature.

There are a number of other rolling releases which are also finely curated and don't have the issues such as those currently seen with the AUR. Suse tumbleweed and siduction are robust successful rolling releases.

As an example, siduction has been run here for a few years now without any issues other than those generally suffered by linux such as xz issue.
 


Follow Linux.org

Members online


Top