400+ Arch Linux AUR Packages Compromised in a Supply Chain Attack Deploying Infostealers
11 days ago by rafssunny to c/technology
The article has instructions to do exactly that.
Users who regularly install AUR packages should take the following steps immediately:
Run pacman -Qm to list all foreign (AUR) packages installed on your system and cross-reference against the published list of compromised packages
Audit recent PKGBUILD history for any packages installed between June 10–12, 2026
Rotate all credentials — browser passwords, SSH keys, API tokens, and cloud access keys — if any flagged package was installed
Scan for suspicious processes masquerading as kernel threads using tools like rkhunter or chkrootkit
Consider using AUR helpers with PKGBUILD review prompts enabled by default.
Ok, but I was expecting something a bit more automated then opening a list of package in kate and comparing it to my list of installed AUR package... Plus it's 400 package so that's a lot of things to check and plenty of space to miss one package by manually checking.
But I get it I'm lazy and just need to script something myself. This is affecting so many people I thought we would have a script to check quickly if you are "infected".
Edit : thanks for the numerous script sent as reply ! But I'm all set now, thanks !
It took Arch ~19 years just to get archinstall.
Something tells me there won't be a script.
The link is a script
A lot of those 19 years were times where only nerds used arch.
CachyOS community seems to have a detection script, I have not vetted this run at your own discretion.
Here's a script:
I try to not use any, I have 6 and 4 of those are maintained by the developer, not some rando.
One I really dislike is that CachyOS when you install their gaming software bundle...it uses the AUR version of Heroic Games Launcher instead of their own repo and CachyOS does not maintain the Heroic AUR AFAIK. I guess because AUR updates more frequently than their own repo? I think it's bad practice.
I have much more than 20 packages in aur, most of them are dependencies from steam-native-runtime. Since steam is popular, I can understand that many have more than 20 packages.
Now when I was reading the ArchWiki I saw that it is mentioned as an alternative, so I assume I can remove steam-native-runtime and all dependencies. Perhaps the instructions have been updated or I googled for instructions and found another page. But there could be other popular packages with many dependencies.
I'm not home for a few days so I can't check yet.
But I think I have something like 3/4 packages at the most.
But I need to compare that to a 400+ list I'm not sure I agree with you it's that easy to do rigorously.
It's at the bottom of the doc:
echo "Checking for infected AUR packages (${#INFECTED_PKGS[@]} total)..."
echo
found=()
for pkg in "${INFECTED_PKGS[@]}"; do
if pacman -Qi "$pkg" &>/dev/null; then
found+=("$pkg")
fi
done
if [[ ${#found[@]} -eq 0 ]]; then
echo "Clean: none of the known infected packages are installed."
else
echo "WARNING: ${#found[@]} infected package(s) found:"
for pkg in "${found[@]}"; do
echo " - $pkg"
done
fi
Not sure why it uses -Qi instead of -Qm since there's no point in scanning pacman packages, but I'm no expert
I haven't used kate but does it not have some sort of easy search?
ex. pacman -Qm to list AUR packages; should display the 3/4 pkgs you have installed. Then just search in kate for those 3/4 results?
Alternatively cat & grep in the terminal is pretty straight forward.
That is if it's 3/4 pkgs that are from AUR, but if someone has hundreds installed that is a bigger issue on its own.
Am I missing something ?
Just because I have 3/4 package on my system doesn't mean the 400+ list of affected package gets shorter on the other side...
I'm actually pretty cautious with AUR and I only install them when there is no other options.
Yes, we need a kind of Debian for Python.
Part of the solution could be the Guix package manager. Part could be the commercial offerings, like Anaconda.
Well, those are mostly extension libraries, stuff "normally" installed using pip. Arch is kind of unique that they encourage using system aur over pip, npm and other package managers. While it is a big radius, none of the python packages stick out to me, but maybe I just haven't encountered the popular ones.
Arch usually doesn't re-package Python packages that aren't needed for something else, meaning they end up in the AUR. I maintain several there, and when I stop using them I abandon them. I wouldn't be surprised if some of the ones I used to maintain are on the list
Well, nothing to do but start at the first one and work our way down...
Been saying for years that people need to stop treating the AUR like a repo, when it's more akin to curl installscript.sh | bash.
Some packages pull files from personal dropbox...
So, better to use a safe language, and use
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs/ | sh
- right??
(I copied that from https://rust-lang.org/tools/install/ just a second ago....)
cue RuSt Is ThE fUtUrE people.
the problem is exactly the fact that it is a repo; it introduces a layer of unknown between the dev and the user. and the user will unavoidably "trust" it (especially when it's listed amongst official repos in e.g. the graphical version of Pamac), without understanding the risks.
I have always been nervous about this type of thing happening with the AUR. Thankfully many packages I used to need the AUR for have since added native versions or made flatpaks. I hope AUR users don't have too many issues from this!
flatpaks arn't any safer and with how poor the sandbox is handled by 99% of devs. Hell flatpaks have a new issue every other month. Its almost more often to see a new flatpak problem then aur problem.
Its literally no safer in reality sure on paper its safer but reality has proven that flatpaks just are not some magical fix to this problem.
Hell half the time when flatpaks do have issues they go unaddressed or fixed for months after they are found. While AUR problems get smacked real fucking fast after they are found.
I haven't heard about all of these flatpak malware incidents.
I agree that Flatpak’s utilization of sandboxing is weaker in practice than is marketed. I get that many apps ship with home/host filesystem access instead of granular permissions, but it does provide meaningful isolation when used correctly.
I think a lot of people are confusing what the AUR actually IS. It is NOT the official package repository used by Archlinux - it's more like a bunch of community install scripts for stuff that isn't officially supported yet - for popularity or other reasons.
So for all those people complaining and saying "debian does it better" it's very likely that you would not even HAVE a package to install and would have to come up with a build script on your own - the AUR allows you to skip this and instead just verify that the script itself isn't malicious, which is usually fairly obvious.
A lot of people here seem to be under the impression that all of this effort should be abstracted for them - but that's what you chose when you left windows - a system that you control intimately with a necessitation to actually do some upkeep yourself because a giant company isn't doing it for you.
In other words. RTFM and stop expecting other people fix all your problems for you, because that's exactly how windows got to how it currently is.
it’s more like a bunch of community install scripts for stuff that isn’t officially supported yet - for popularity or other reasons.
I'm looking at the list of affected packages and many of them are in official debian repos. Isn't the issue then that the official Arch repositories don't have many packages and people have to use less secure sources? That still sounds like an Arch issue to me.
Arch actually has a large amount of official packages. Maybe some of the packages you're referring to are just slightly renamed or alternate versions?
It's possible that in some areas it has fewer packages of course (e.g. Debian might repackage a larger subset of PyPI as Python packages), but I need the AUR for very few things.
Isn’t the issue then that the official Arch repositories don’t have many packages .....?
Not at all. The official Arch distribution has tens of thousands of packages and the user repository / AUR probably more than 100,000 .
Edit: I looked it up:
- According to distrowatch.com, the Arch Linux distribution has over 17,000 packges by now
- Meanwhile, the number of packages in the Arch User Repository is 114,000 .
I haven't been on my PC that much this week, just Friday night. And our D&D group uses Discord so I needed to make sure it was up to date to ensure it would run. I typically just do a, "sudo pacman -Syu" and that seems to update what I need.
If that is the only thing I did with the PC during this window, is there any concern?
Probably not. The article says that most of it seems to have come from orphaned stuff in the AUR that the threat actors took ownership of via the legit process, then modified to pull down malicious NPM packages when someone went to install them.
So if your Discord package is well maintained you probably have nothing to worry about.
Nah, you're fine the Discord package(https://archlinux.org/...) is in the official repo and it was not affected at all. The only people who should worry are those using AUR helpers to install packages without checking the PKGBUILD
1500+ now https://md.archlinux.org/s/SxbqukK6IA
I was starting to get too confident in AUR. Thankfully I wasn't affected. Just replaced all possible AUR packages to their respective Arch and Flatpak alternatives, with exception of very few or from the ones I had no option. But will definitely check before updating them, and will only install AUR packages as a last resort.
Have a look into the Guix package manager. It works fine on top of Arch, and Guix has 31,000 packages now. Great for cross-language development and also suitable for early sharing of projects. npm support is a bit weak though, but packages written in Python, Rust, or functional languages are well represented.
Yes, Guix is initially a clone of Nix and has still remains of shared code (the build daemon).
Differences:
- Guix packages are defined in a Scheme dialect called Guile, a nice minimal functional language
- Guix was created as a GNU project and stresses the importance of free software with strong copyleft
- strong focus on long-term reproducibility and capability of tracking the sources
- everything is built from source
- very good and well organized documentation
Not even having npm installed as a system package feels like a personal win right now. I'd like to think I would have caught this due to the number of dependencies it would introduce to my system. node_modules seems like it's been the source of most of the recent CVEs I'm hearing about.
Is this the first time AUR has been compromised to this degree?
I do believe so, yes. There was couple of cases in last year, but never to this extend. If I understand correctly, reading arch thread, it something to do with the fact that anyone can "adopt" orphaned package on AUR. Which is kinda wild.
anyone can “adopt” orphaned package on AU
Þis is þe important point. I vet my AUR installs by checking upstream, but I don't vet every package for every upgrade. Or, even, most. AUR could have a little more oversight wiþ relatevely little impact. E.g. a cursory initial check and þen an AUR rule preventing anyone from changing þe source repos on an existing package would make a huge difference. AUR is a centralized package list; a simple diff on source preventing inclusion in þe pkglist, and flagging þe package for review, say. Not foolproof, but it'd prevent þe most trivial exploits.
Frankly, whatever problems GPG may have, AUR is a perfect use case for þe web of trust. Having maintainers have to sign packages would make exploits even harder. Not fookproof, but harder þan "effortless."
You may or may not have commented something useful. I don't know. Your retarded spelling right off the bat makes the whole thing moot.
Or dropbox
So far I've just checked the diff of every package update. But with that many, I think we should maybe start using using the script provided in the article that you evidently didn't read.
typical arch user, doesn't know how to use grep.
Look how every motherfucker complains about arch and the aur but not that their distros blindly use it without contributing back and even suggest to blindly trust it. these same people now complain the aur is to complicated. Never go full retard guys
Tons of clawing at each other's throats in the comments here, largely declaring one another retarded for their use or misuse of AUR or thanking their lucky stars that none of their packages are on the list (so far), but not much that's helpful for those less fortunate. Maybe nobody's saying anything to that end because the article already covered it, but this is the second out of two times I've visited cybersecuritynews.com and been stuck in an "Are you a bot?" loop that never ends no matter how much of my browser's safeguards I peel off.
Here's what steps I did so far, based on following the links I found in this thread (especially the GitHub comments under one of the links):
pacman -Qmin console yielded a list of all the AUR packages that are installed on the systemCTRL+F the results one-by-one in the apparent most up-to-date list: https://md.archlinux.org/s/SxbqukK6IA
I have one on that list, specifically
wine-nine, so I ranbat --style header,snip,changes /var/log/pacman.log | grep wine-ninewhich yielded the following (at the bottom of a very long list of apparent updates I've run since installing the OS):
[2026-06-05T20:37:06-0400] [ALPM-SCRIPTLET] wine-nine 0.10-1
[2026-06-07T21:50:58-0400] [ALPM-SCRIPTLET] wine-nine 0.10-1
[2026-06-08T20:56:54-0400] [ALPM-SCRIPTLET] wine-nine 0.10-1
[2026-06-09T21:38:44-0400] [ALPM-SCRIPTLET] wine-nine 0.10-1
[2026-06-10T21:58:52-0400] [ALPM-SCRIPTLET] wine-nine 0.10-1
[2026-06-12T20:18:37-0400] [ALPM-SCRIPTLET] wine-nine 0.10-1
[2026-06-12T20:18:37-0400] [ALPM-SCRIPTLET] wine-nine 0.10-1
(Like a good little Arch user I've been updating pretty frequently)
- Now what?
I saw something that said "check for suspicious processes running as root" but I have no idea what that would look like.
I saw something that said I need to redo all of my passwords and tokens. Any way to check if that's necessary or should I just assume I've been pwn3d?
In using pacseek I think I've discovered wine-nine hasn't been modified in the AUR since "2024-12-07 - 15:18:31 (UTC)" so can I relax a bit? I'm currently going through my list of AUR packages and deciding whether or not I need them as badly as I originally thought. Sadly my distro is one of those that decided to lean on AUR, because most of my list (apart from two) I don't recognize as something I've installed myself.
pacseek would not let me remove the following AUR packages (which thankfully are not in the list (yet)):
:: removing electron41-bin breaks dependency 'electron41' required by deltachat-desktop - an encrypted chat application I installed (not via AUR) I suppose I could find an alternative for
:: removing electron41-bin breaks dependency 'electron41' required by freetube - a YouTube frontend I installed (not via AUR) I suppose I could find an alternative for
:: removing libsoup breaks dependency 'libsoup' required by webkit2gtk - no idea what webkit2gtk is
I only just now realized that chaotic-aur is probably just as problematic as AUR, both in my decision to use packages at all as well as my searching the list of compromise packages, yes? I have tons more packages under that, most of which I think came with the OS.
Chaotic is not just as problematic, thankfully. They have systems in place to flag suspicious changes for human review before letting them out and it has, so far, prevented them from shipping any compromised updates.
I thankfully hadn't updated anything from the AUR for a couple of months (it doesn't happen by default when I update the rest of my system) and was unaffected, and after looking at the list of things I had from the AUR, I didn't need any of them... So I now have zero AUR packages on either of my systems.
I think there was a word missing.
To respond to what I think you were saying, this event happened in the Arch User Repository, and not the official repositories.
Arch is very clear that they are not responsible for what goes on in the AUR. For example on https://aur.archlinux.org/ :
The Debian equivalent would be somewhere between extrepo and PPAs.
I think the comment makes sense, if more packages were supported on the main Arch repos there would be less of a need to use the AUR or Flatpaks.
There are definitely some big gaps on the Arch repos (web browsers in particular) that I would like to see improved.
Yep an easy agree. Popular browsers like Zen, Helium and (god forbid) Brave should be directly in the official repos. So should be Jellyfin. It just makes sense given that debian repos have far more packages.
You're right, but web browsers can be pretty brutal to build and they are for sure never going to add -bin versions.
I don't understand this argument. Isn't it better to build once and distribute binaries than to make everyone compile it themselves? The vast majority of AUR packages I use are -bin versions.
maybe i went offtopic but i was comparing the AUR To Debian's repos, i see that Debian has more packages in its repos(things like Llama-CPP and Open arena is in debian but arch needs the AUR)
thats what i meant
No. If it came from AUR, it doesnt matter the method you used. You should check all the AUR apps you recently updated (from 9th to 12th June), and compare it to the lists. Only AUR though... Arch official repos are not affected by it.
Nope. Distrobox does not offer any meaningful protection, since its purpose is to integrate with the system. It's basically meant to make downloading and managing packages from different distros, on the same system, much easier... but it's not meant to protect and isolate your device the same way that Flatpak or other type of containers do. That baing said, stop relying on Distrobox as a safety measure, and check your recently installed and updated packages since 9th June, to make sure you were not infected.
Yeah I had a mild panic before realising that I haven't actually used aur for anything yet
Expecting user to inspect install scripts is retarded. And this is the result.
So what would the alternative be? If the resources or desire don't exist to make a package official, how else would you install it?
You're missing the point entirely. I'm talking about inspecting the scripts not about making packages
Sorry if I was unclear. You usually don't inspect the install scripts for official packages since you put the trust in the official team. You don't trust(or at least shouldn't) AUR packages, hence you should inspect the install script for those packages. I don't really see what the alternative would be.
Well, the alternative would be for moderation team to inspect them, with clear signaling of which scripts are trusted and which aren't.
Are you aware how github works, or open source development in general ?
Some users are developers, too.
Some people write code, others may try it out, and a few of the latter might help with developing it. And some of these efforts become popular.
That's how we have Linux or KDE.
That's why Sourceforge was such a big win, why Ubuntu has launchpad and ppas, and why Arch has AUR.
It is all based on open sharing.
And of course you can opt to not run code that you don't know, or don't understand , or don't trust.
flatpak has a sandbox
Be careful with relying on it though since it has more holes than swiss cheese due in part to lazy devs who request unesecary permissions & the sandbox being slightly flawed from a security perspective.
A sandbox that has enough protection to be secure also has enough restrictions as to be too annoying to use, and often is useless. Don't get me wrong, sandboxes can be very good, but only in specific situations. In general you need your applications to be secure without a sandbox.
It's a sandbox in the sense that it is a box to keep the sand in one place under normal circumstances. It was never intended to completely prevent sand from being ejected by an unruly child inside of it. Or perfectly keep outside toys from being brought into it if someone tries to do that.
That's not how that works.
- when you use distribution-provided packages, you trust the distribution maintainers
- when you use the AUR you trust the upstream project and check the PKGBUILD because the maintainer can change
In some cases, upstream also maintains the AUR package, in which case you can probably trust that it'll not be abandoned
Welp, you wouldn't be the first who actually believes what you wrote!
Eh, depends really. The AUR is not the default place to install software from, it's all user created and comes with warnings almost anywhere you have access to it. I've generally used Octopi to install packages and you have to jump through some hoops to even have it show you packages from the AUR. Generally, running updates for the system, from the Arch flavors I've used anyway, by default doesn't update packages installed from the AUR and you generally update them deliberately and separately. As an example, on my Garuda systems I only have 3 packages installed from AUR and they are so rarely used I forget about them a lot... I'm a bad sysadmin for myself and they don't get updated nearly as often as the main system packages.
But, do other people use their system differently? Absolutely. They have likely ignored several warnings (or read them and accepted the risks) to get there though.
Forenote: image text unrelated, but somewhat relevant.
Me, not updating my system in many months due to a box of various issues:
~7Mbps shared internet, Arch expecting regular updates (and me not setting up the timer stuff to prevent those issues), and most recently before this my 1050Ti becoming legacy and Arch moving the legacy driver onto the AUR (I updated stuff from the AUR even less, so this is a blocker for me).
I probably need a new distro at this point, but not convinced by any. In any case an AMD GPU would also help, but also probably not happening on my terms either.
@lemmy.world
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
go to feed...
@lemmy.world
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
go to feed...
I hope all the Arch based distros will do a proper post to inform their users on how to cleanup afterwards.
I'm hoping at least cachyos, the distro I use, will tell me exactly how to check and clean my system.
I remember that when I installed a few of my AUR package, I was well aware that this repo was pretty much unregulated and that I just have to trust it's safe. So I made sure to only use AUR as a last resort. But there was warnings on cachyos that were displayed to tell me to be cautious about it so that's at least a positive.
save