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!
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.
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…
But it is a repo. It’s just an unofficial one. I don’t know how you use it without understanding this. It’s not far from perfect, but it is useful.
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.
Expecting user to inspect install scripts is retarded. And this is the result.
Then dont use arch and the aur easy as that
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.
Is this the first time AUR has been compromised to this degree?
Given how changes are often unvetted, I am surprised this hasn’t occurred before.
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
sourcepreventing 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.
it looks like youre infected…EVERYBODY STAND BACK
Welp if nothing else at least this has helped me to replace jack1 with jack2 (out of my 4 total Aur packages)
Wow, I have 229 AUR packages installed but none of them is on the infected list!
Am I just lucky?
i have a few machines and lots of aur packages and none of mine have a single hit either
Same here. Just checked against the new list with 1937 packages and still don’t have a match.
can i get a link to the list youre using, or where you found it?
I just checked the new list with 1937 infected packages, not a single match. Again, am I just lucky or are all these 1937 packages barely used by people?
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
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.
Pnpm for the win
I wish Arch packages as much in their repos as Debian.
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 system -
CTRL+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
pacseekI think I’ve discoveredwine-ninehasn’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.
pacseekwould 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 whatwebkit2gtkis
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.
Ironic, given the name.
I’m very new to Arch so I’m still confused as to where I stand. Hopefully I haven’t been pwned. Sadly, my distro includes AUR packages by default.
My distro (Garuda) included a couple back when I originally installed it, but doesn’t use them currently (namely wine-nine - which was affected) but the built-in system update didn’t touch AUR unless you explicitly tell it to, so that saved my bacon in this situation (my AUR packages hadn’t been updated in 2 months).
How do I check to see if that’s the case for me too?
As I showed above, I also had wine-nine, but I can’t tell if that log is listing all the times wine-nine was updated or all the times I updated with wine-nine installed.
I’m leaning toward the latter given it was just listing
wine-nine 0.10-1repeatedly, implying it never updated past that in the dangerous period, right?I am not at home (and work is stuck on windows) so I can’t verify with 100% certainty… But I believe what I did was pacman -Qm to list the AUR packages. Then I did pacman -Qi <package_name> to list the details about why it was installed, what dependencies it has, what depends on it, and when it was last updated. Mine showed like 2 years prior (whenever I installed the OS) because there hadn’t been any update to it in years (until the attack). If your date for last updated is recently, you probably have a problem.
-
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.
Can’t load the article but I assume Arch’s rolling release way of doing updates makes this quite the disaster.
It makes a big headline and a small impact. It’s not official arch packages that were compromised.
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.
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.
yay (-Syu)
