I haven't used Arch for a few years now, but when I did the AUR was my favourite aspect. It was never perfect from a security PoV, but in 2026 this kind of trust model feels increasingly scary.
We are pretty far from "never perfect"
AUR packages compromised with Infostealer and Rootkit
41–50 of 234 posts
Re: AUR packages compromised with Infostealer and Rootkit
#42Here's an easy script to scan for compromised packages: https://cscs.pastes.sh/aurvulntest20260611.sh Not my script. It's easy to read/parse. Never pipe a script directly to bash.
It isn't guaranteed that the list is conclusive. Always check PKGBUILD and sources, AUR is not to be trusted for the most part. I'm actually more surprised that such compromise hasn't happened earlier.
> hasn't happened earlier.
it happens all the time
Just not always on this scale and doesn't always end up on HN.
Similar to how you don't see every npm supply chain attack or malicious github action or similar on HN.
In general you _have to_ manually review every PKGBUILD update by hand (by diff). Everything else is neglect IMHO. Luckily for most packages this is reasonably doable, IFF you trust the upstream sources they fetch from. (As in: Most packages are a small amount of glue between pacman and a upstream source.)
As consequence AUR packages with AUR dependencies are in general "uh..., lets not do it" cases for me, as on one hand the review overhead can be a pain and on the other hand it's easy to make a mistake overlooking a change in AUR dependencies.
Still the policy which allows relatively easy adoption of orphaned packages is IMHO a problem. A adoption should be treated as a new package which just happen to have the same name. (It can be fine to not have that if arch maintainers "bless" the adoption, but IMHO that would only matter for a view very widely used packages which are candidates to be included in the official repo but aren't for e.g. license reasons.)
Re: AUR packages compromised with Infostealer and Rootkit
#43I remember installing an emulator (Mednafen) on Arch Linux about a decade ago. The program failed to run because it was linked against a library my system didn't have. Turns out, the maintainer built the software on his own system and it used a library he had on his system but was not listed in the dependencies.
It is an officially maintained package and I always assumed these were built on a dedicated build server instead of some a random volunteer/home computer. Don't know if Arch still builds the same way but this event scared me enough to switch distros.
Re: AUR packages compromised with Infostealer and Rootkit
#44Wow, this is effectively the end of the AUR model. There's been a malicious package or two before, but an attack this widespread shows things are fundamentally broken. Guess I'll be switching to a new OS this weekend across multiple machines.
> Guess I'll be switching to a new OS this weekend across multiple machines.
This is a bit of an odd response. Arch very explicitly separates the AUR from everything else and doesn't make it easy to work with, because its security model has always been fundamentally broken and requires you to do your own vetting. It exists to facilitate sharing of package recipes between untrusted users. You should treat it like a pastebin.
Re: AUR packages compromised with Infostealer and Rootkit
#45Here's an easy script to scan for compromised packages: https://cscs.pastes.sh/aurvulntest20260611.sh Not my script. It's easy to read/parse. Never pipe a script directly to bash.
Note that pacman supports date locales; searching for '9 Jun' only works in English locales (or locales using similar formatting, I suppose).
After correcting, for me, it flagged "jd-gui", but I had actually installed "jd-gui-bin" about two hours before the compromise. As far as I can tell, I was lucky that I felt lazy that night and went for the -bin package instead of waiting for the source to be compiled.
Re: AUR packages compromised with Infostealer and Rootkit
#46Wow, this is effectively the end of the AUR model. There's been a malicious package or two before, but an attack this widespread shows things are fundamentally broken. Guess I'll be switching to a new OS this weekend across multiple machines.
Nothing here is "fundamentally broken". Any usage of AUR was always one step above executing random shell scripts from the net, and any official Archlinux guides were explicit about it. That's why there are no AUR helper tools in official repos and their usage was always discouraged in forums/wiki.
PKGBUILDs are easily readable/reviewable and rarely go beyond a single page. Just take a moment and be responsible and review before running executable files you download from the net. Common sense stuff. That's always been the trade-off and it hasn't really changed much in last 20 years (even though every few years everyone seems to freak out over it).
Re: AUR packages compromised with Infostealer and Rootkit
#47Thanks for the link. It contains link to list of the affected packages, that will be useful.
Re: AUR packages compromised with Infostealer and Rootkit
#48Here's an easy script to scan for compromised packages: https://cscs.pastes.sh/aurvulntest20260611.sh Not my script. It's easy to read/parse. Never pipe a script directly to bash.
Note that pacman supports date locales; searching for '9 Jun' only works in English locales (or locales using similar formatting, I suppose). After correcting, for me, it flagged "jd-gui", but I had actually installed "jd-gui-bin" about two hours before the compromise. As far as I can tell, I was lucky that I felt lazy that night and went for the -bin package instead of waiting for the source to be compiled.
Same situation for me. "alvr-bin" instead of "alvr". I'm a week out of date too.
Re: AUR packages compromised with Infostealer and Rootkit
#49Re: AUR packages compromised with Infostealer and Rootkit
#50So what's a solution to this? Install packages like this in Docker containers without network access? I don't think we should assume it's limited to AUR. Every software source should be considered suspect in 2026, particularly with the adoption of vibe coding, and closed software is a bigger mess than open source because it's a black box.