The Arch Linux AUR had over 400 packages compromised with malware

Quoting: Breizh

the Arch Linux AUR (Arch User Repository) needs some better security and package checks […] for some improvements to the packaging processes to prevent this from happening in future.

Well, there is no check at all currently. The AUR is just a way for user to share what they use personnally, it shouldn’t be trusted.

People that use AUR recipes without checking them before can only be angry against themself, it’s like getting a random script on GitHub and running it blindly…

Of course, cleaning the AUR as it’s going now is a good thing, but Arch could simply close the AUR and ask people to share their PKGBUILDs elsewhere instead.

That's my point though - it *needs* some checks. Otherwise, the people responsible for keeping the AUR online become responsible for helping to spread malware. Just telling people to check whatever code or recipe isn't going to cut it.

Quoting: Liam Squires-Hand

Quoting: Breizh

the Arch Linux AUR (Arch User Repository) needs some better security and package checks […] for some improvements to the packaging processes to prevent this from happening in future.

Well, there is no check at all currently. The AUR is just a way for user to share what they use personnally, it shouldn’t be trusted.

People that use AUR recipes without checking them before can only be angry against themself, it’s like getting a random script on GitHub and running it blindly…

Of course, cleaning the AUR as it’s going now is a good thing, but Arch could simply close the AUR and ask people to share their PKGBUILDs elsewhere instead.

That's my point though - it *needs* some checks. Otherwise, the people responsible for keeping the AUR online become responsible for helping to spread malware. Just telling people to check whatever code or recipe isn't going to cut it.

While you are rising a valid point, I don't see how that could happen. AUR packages can pull sources from anywhere and run any kind of script, and thus automated checks do not seem possible. And if they manually check them, well, they would just not be AUR packages, they would be normal packages.

IMO they should implement a system to report packages, but other than that I think there's little they can do other than closing AUR entirely (and IMO that would be a great loss, I am currently using 54 AUR packages on my system, and I maintain 14 of them: https://aur.archlinux.org/packages?SeB=m&K=doragasu).

Also note that IMO this problem is not that big for power users using Arch, but for users of Arch derivatives that incorporate tools that automatically install and update software from AUR without the user understanding the risks. On standard Arch, for you to install an AUR packages you have to follow the wiki to manually build at the very least an AUR helper, and understand the risks.

Quoting: doragasu

Quoting: Liam Squires-Hand

Quoting: Breizh

the Arch Linux AUR (Arch User Repository) needs some better security and package checks […] for some improvements to the packaging processes to prevent this from happening in future.

Well, there is no check at all currently. The AUR is just a way for user to share what they use personnally, it shouldn’t be trusted.

People that use AUR recipes without checking them before can only be angry against themself, it’s like getting a random script on GitHub and running it blindly…

Of course, cleaning the AUR as it’s going now is a good thing, but Arch could simply close the AUR and ask people to share their PKGBUILDs elsewhere instead.

That's my point though - it *needs* some checks. Otherwise, the people responsible for keeping the AUR online become responsible for helping to spread malware. Just telling people to check whatever code or recipe isn't going to cut it.

While you are rising a valid point, I don't see how that could happen. AUR packages can pull sources from anywhere and run any kind of script, and thus automated checks do not seem possible. And if they manually check them, well, they would just not be AUR packages, they would be normal packages.

IMO they should implement a system to report packages, but other than that I think there's little they can do other than closing AUR entirely (and IMO that would be a great loss, I am currently using 54 AUR packages on my system, and I maintain 14 of them: https://aur.archlinux.org/packages?SeB=m&K=doragasu).

Also note that IMO this problem is not that big for power users using Arch, but for users of Arch derivatives that incorporate tools that automatically install and update software from AUR without the user understanding the risks. On standard Arch, for you to install an AUR packages you have to follow the wiki to manually build at the very least an AUR helper, and understand the risks.

If they cannot do any checks - that's just a glaring flaw in the entire design of the AUR and so yes - it should be shut. If it's just going to repeatedly be a huge security issue like this, then why should it exist? It's dangerous.

don't panic. all of your aur packages are fine, if you use a dozen of popular ones, that were not orphaned. still, check the mailing list just in case.

i wish official arch linux repos included packages that other distros do, even some arch based repos include apps like heroic launcher and vesktop. debian has vmtouch.

meanwhile arch repos have some half broken image viewers and similar abandonware, that should be removed

Quoting: doragasu

Quoting: Liam Squires-Hand

Quoting: Breizh

the Arch Linux AUR (Arch User Repository) needs some better security and package checks […] for some improvements to the packaging processes to prevent this from happening in future.

Well, there is no check at all currently. The AUR is just a way for user to share what they use personnally, it shouldn’t be trusted.

People that use AUR recipes without checking them before can only be angry against themself, it’s like getting a random script on GitHub and running it blindly…

Of course, cleaning the AUR as it’s going now is a good thing, but Arch could simply close the AUR and ask people to share their PKGBUILDs elsewhere instead.

That's my point though - it *needs* some checks. Otherwise, the people responsible for keeping the AUR online become responsible for helping to spread malware. Just telling people to check whatever code or recipe isn't going to cut it.

While you are rising a valid point, I don't see how that could happen. AUR packages can pull sources from anywhere and run any kind of script, and thus automated checks do not seem possible. And if they manually check them, well, they would just not be AUR packages, they would be normal packages.

IMO they should implement a system to report packages, but other than that I think there's little they can do other than closing AUR entirely (and IMO that would be a great loss, I am currently using 54 AUR packages on my system, and I maintain 14 of them: https://aur.archlinux.org/packages?SeB=m&K=doragasu).

Also note that IMO this problem is not that big for power users using Arch, but for users of Arch derivatives that incorporate tools that automatically install and update software from AUR without the user understanding the risks. On standard Arch, for you to install an AUR packages you have to follow the wiki to manually build at the very least an AUR helper, and understand the risks.

Although certainly not perfect an automated hash check for known [malware signatures](https://github.com/Yara-Rules/rules) would greatly help.
Malware writers are a lazy bunch they tend to automate their injection and reuse code.
This at least limits their scale.

Quoting: GrishnakhNot panicking, for now, as I don't use npm or have any apps that do. But I agree with the sentiment: Oh dear.

You don't have to use npm to be affected. If you use any of the affected aur packages and you updated them in the last week or so then you might want to check your repos.

The AUR isn't inherently any more dangerous than the official repos, the maintainers there could easily miss a malicious change like this by not checking out the npm packages that are downloaded. This only affects orphaned packages, that's where the problem lies. Quite frankly I think they should suspend or even delete PKGBUILDs that become orphaned instead, only allowing them to be claimed after going through a verification process. I'm sure helpers would be able to check for a flag that says the entry has been suspended and inform the user.
It would be different if the AUR operated more like Gentoo where you have to build the packages yourself, but PKGBUILDs abstract almost all of the process away to the point where the AUR isn't just a place to share scripts, it's a repository of automated installs.

It seems I'm unaffected, but WOW what a disaster. With all the newbies flocking to CachyOS and other Arch based distros, there are definitely going to be some bad outcomes here.

I hope the Arch community comes up with something that isn't just victim blaming newbies for not having their security dialed. The AUR is universally easily accessible and recommended with caveats that disavow responsibility. So Arch fans gave their fair warnings, sure, but then threw newbies to the wolves.

This will go down as AURgate

I seem to be alright, the one AUR package on this entire install is clean to my knowledge, but I'm getting rid of it anyways as it didn't work at all.

Although, this is pretty much why I don't mess with the AUR typically, it's too... laissez-faire, and me no likey.

Added the Arch Linux statement.

Quoting: StellaThis highlights how AUR cannot be the future of Linux Desktop. It's totally unregulated, mostly limited to a single distro family (unless wrappers like distrobox are used), and requires a lot of user input (reading PKGBUILDs) as well as ensuring packages are up-to-date on the system at all times. In contrast, there hasn't been a single case of malware found on Flathub so far, mostly due to the strict requirements to publish on Flathub, and every app being manually reviewed before it's published. Also Flatpaks are available on every distro.

Was anyone saying AUR could be the future of Linux Desktop? I don't think so.
Flathub has better security but it's not a great example for packaging for the Linux Desktop either. A huge amount of duplication and massive waste of disk space, which is the result of some flatpaks that require downloading enormous amounts of data, this needs to be addressed if flatpak is to succeed in any meaningful way, in my opinion.

Quoting: Liam Squires-Handthe Arch Linux AUR (Arch User Repository) needs some better security and package checks […] for some improvements to the packaging processes to prevent this from happening in future.

That's like saying "people who can't swim can drown in the sea, so we should have every single access to the sea guarded and protected at all time".
That is insane...

for anyone who doesn't use an AUR helper, I made this basic little bash script:

for dir in ~/AUR/*/
do
dir=${dir%*/}
echo "${dir}"
cd ${dir}
cat PKGBUILD | grep $1
cd ~/AUR/
done

if you don't keep your AUR packages in ~/AUR/, you will need to change that in the code.

run it with `./<script-name>.sh <bad-package>`. so for this one, if you do `./script.sh atomic` and any of them print anything, you have been compromised. If none of them do, you're hopefully safe.

I'm sure you could probably do this more elegantly and if your AUR helper stores its packages predictably, you could also use it for that - but this is what I just made (and luckily none of mine are affected as far as I can tell) and it works for me.

It is worrying, and I'm torn - I find the AUR incredibly helpful, as it means that the only packaging system I have on my PC is pacman. AUR has filled every gap I've ever needed, compared to when I ran Ubuntu and had flatpak, apt, snap, manual `.deb` packages, and full git repos to compile from source. However clearly it is a flawed system, and this is a huge disgrace - I sincerely doubt the majority of users read through PKGBUILDs, so undoubtedly this is going to have some severe impacts. I'm also a little disappointed in the response, as I feel like there are systems they could have put in place to handle this quicker - like turning off all adoptions, for starters. Easier said than done though I'm sure.

Last edited by Turkeysteaks on 12 Jun 2026 at 7:41 pm UTC

Phew, I just used the list of affected on the report thread on the mailing list and compared it (via meld) to the output of pacman -Qqm and it looks like I dodged a bullet.

Several helpers come with a feature that warns you about changes to a PKGBUILD, or .install script/additional files.

If you use an AUR helper, it's still wise to review build scripts just like any other bash script. Malicious edits are usually painfully obvious, even for someone who doesn't know much more than a line of code like myself.

The crux of the problem seems to be the post-install .install scripts that run after a package has been installed; people probably don't have the presence-of-mind to look at those too often, they just check the PKGBUILD.

Quoting: ExplosiveDiarrhea

Quoting: Liam Squires-Handthe Arch Linux AUR (Arch User Repository) needs some better security and package checks […] for some improvements to the packaging processes to prevent this from happening in future.

That's like saying "people who can't swim can drown in the sea, so we should have every single access to the sea guarded and protected at all time".
That is insane...

That is not even remotely the same. It’s more like: this one pond is shark infested and they’re hungry so don’t enter.

Anyway, the fact that the AUR clearly has no verification of any sort is very clearly a problem that needs to be dealt with properly.

Quoting: Liam Squires-HandIf they cannot do any checks - that's just a glaring flaw in the entire design of the AUR and so yes - it should be shut. If it's just going to repeatedly be a huge security issue like this, then why should it exist? It's dangerous.

The AUR is basically a convenient wrapper around a forum where people share scripts to easily build software from source. It is dangerous in the same way that the Arch forums are dangerous. The Arch team should probably appoint some moderators to check the AUR, but then you get to the point where those people will have a really difficult time checking every single package. You're welcome to your opinion that 'it should be shut down', but I'd sooner say 'people shouldn't be using Arch (and derivatives) unless they understand the risks of the AUR and are willing to take responsibility for what they do on their computer'. Some may call that elitism, but to me it's like saying stores selling cooking supplies shouldn't be allowed to sell knives because people who can't handle them may injure themselves.

Quoting: tmtvlIt is dangerous in the same way that the Arch forums are dangerous.

That comparison is interesting. The Arch team would never let some random new account edit the forum posts of an inactive user. So why are they letting them do it on the AUR? IMO the ophaning system should be eliminated entirely and abandoned PKGBUILDs archived or deleted. If someone wants to reintroduce an abandoned PKGBUILD they should have to write it entirely themselves as a new entry.

Sorry, which part of arch user repository is that hard to understand?

In special when both the aur webpage and the arch wiki are explaining that all AUR-Repositories are user-provided packages that aren't checked / monitored / reviewed?

The AUR is from / for the community, not maintained, no QA or anything else. If you use it you have to understand what's happening.

And - that's for all distributions and all operating systems: Never ever should one blindly install any software packages without a bare minimum of understanding what's going on with the installation script.
If you blindly trust your 'best budddy' and just click install - sorry not sorry.

BTW: arch itself and responsible derivates are forcing you to manually enable the AUR. Or - as for e.g. I handle it myself for 2-3 pkgbuilds - I download and build them manually on my computer. Regular updates are done with pacman, AUR-repos disabled. I'm on arch since 2005, btw

This is pretty bad. Luckily, I don't have too many packages from the AUR. I think I'm fine, thank God.

Quoting: doragasuAUR does not have package checks by definition, it puts that weight on the user.

As I always say, I have been using Arch as my main distro for 10+ years, and despite that (maybe because of that) I never recommend Arch!

We all start off as beginners. You don't have to not recommend it. If you do recommend it, just explain the reasons for why someone would want to try Arch. Arch is for people who are interested in really learning how to do things on their own, and don't mind scraping their knees a bit by learning things the hard way. It's also good for people that just want to be aware of every package on a clean install.

My first distro was Slackware, and I reckon it's much harder to get into as a beginner than Arch is, especially during the mid 2000s. If I can learn my way through it, anybody can.

Quoting: JugglingJesterSorry, which part of arch user repository is that hard to understand?

And this is a user comment section. I, as the person who runs it, still have a duty to ensure nefarious crap isn’t shared and spread. The same applies to the AUR and who run it, the same applies to literally any online service. Is that hard to understand?