And yes your are right the table wasn’t accurate, that’s one of the reasons I decided to delete it.
No problem. I still completed writing my part as I generally have the impression that not everybody understood in which way the AUR has been compromised.
So over on reddit I saw an post in which someone took the time and cross referenced that list of known affected packages within that malware campaign to the actual package statistics.
But I really should point out that it’s uncertain if these statistics include all the known packages affected.
Personally, I only can report that the python-future package catched my eye, simply because I remember that I myself removed it when it was flagged as an orphan. Can’t even tell which other package pulled it as a dependency. But it was safe to remove without any issues, obviously not required anymore.
Package Popularity Affected Reverted
libgdata 16.98% (2026-06-11 14:59+00:00) (2026-06-11 17:30+00:00)
qt5-3d 8.40% (2026-06-11 13:05+00:00) (2026-06-11 13:18+00:00)
python-future 5.38% (2026-06-11 15:58+00:00) (2026-06-11 16:54+00:00)
gdl 3.36% (2026-06-11 13:35+00:00) (2026-06-11 17:32+00:00)
lld19 2.43% (2026-06-11 13:18+00:00) (2026-06-11 13:33+00:00)
libquvi-scripts 2.31% (2026-06-11 15:05+00:00) (2026-06-11 17:33+00:00)
libquvi 2.22% (2026-06-11 15:04+00:00) (2026-06-11 17:33+00:00)
gtkimageview 2.19% (2026-06-11 13:44+00:00) (2026-06-11 17:33+00:00)
python2-pyparsing 2.02% (2026-06-11 14:23+00:00) (2026-06-11 17:40+00:00)
python2-appdirs 1.96% (2026-06-11 14:22+00:00) (2026-06-11 17:26+00:00)
compiler-rt19 1.95% (2026-06-11 14:23+00:00) (2026-06-11 17:30+00:00)
python2-packaging 1.90% (2026-06-11 14:21+00:00) (2026-06-11 17:38+00:00)
wine-nine 1.86% (2026-06-11 15:48+00:00) (2026-06-11 21:36+00:00)
clang19 1.86% (2026-06-11 15:36+00:00) (2026-06-11 21:24+00:00)
clang15 1.76% (2026-06-12 12:34+00:00) (2026-06-12 12:54+00:00)
mono-addins 1.69% (2026-06-11 15:33+00:00) (2026-06-11 21:34+00:00)
python2-chardet 1.68% (2026-06-12 12:42+00:00) (2026-06-12 14:48+00:00)
python-monotonic 1.55% (2026-06-11 15:43+00:00) (2026-06-11 21:37+00:00)
python2-cffi 1.47% (2026-06-12 12:44+00:00) (2026-06-12 15:10+00:00)
alvr 1.26% (2026-06-11 13:54+00:00) (2026-06-11 16:50+00:00)
python2-gobject 1.23% (2026-06-12 12:44+00:00) (2026-06-12 14:47+00:00)
vidcutter 1.03% (2026-06-11 13:24+00:00) (2026-06-11 17:43+00:00)
Full post on reddit, posted 2 days ago and may only looked at the lower number (520 packages) that have been affected.
Additionally, I can’t really tell in which way the popularity score is generated. But in essence, the majority of packages targeted within the campaign had an popularity score smaller than 1% and the author of the post on reddit excluded these directly.
The script, which was luckily created by CSCS from Cachy OS, allowed us to check which foreign packages were installed to see whether they were downloaded or updated between the start of the attacks on June 11 and today. So far, none of the packages on my list are affected, and I haven’t and won’t perform any updates or installations from AUR as long as attacks on AUR continue.
As far as I understand, that’s what I can do right now to be reasonably safe, right?
Exactly. Let the dust settle a little. Updates via pacman should be unproblematic.
Even if the detected malware injection attempts have been not only been discovered, they also should be rolled back already, as far as I know. The recommendation is still to don’t update the AUR as it is not strictly required most of the time. There might be new attack vectors which haven’t been discovered yet.
a full list:
While it’s true that we should be cautious until we fully understand the scope of the situation, I think the most important thing right now is to stay informed and stick to the facts without falling into alarmism. Overreacting to a problem can be just as harmful as ignoring it.
I’m seeing comments suggesting that people should avoid updating their systems altogether for a while, often without clarifying that the issue concerns AUR packages specifically. Some users are mass-removing AUR packages, including ones that haven’t received updates in weeks or even months, and replacing them with alternatives that may be less suitable or, in some cases, even less secure.
There are also comments from users who have decided to migrate to Flatpaks, remove Chaotic-AUR repositories, stop using CachyOS kernels, or even temporarily move to distributions that are not Arch-based. Some comments also mention AUR helpers (yay and paru) being unsafe and unofficial (and yes, they are unofficial but they have been with us and will continue to be with us, hopefully for a long time to come), or avoiding tools like downgrade. While everyone is free to make their own choices, for newcomers to Linux or Arch-based distributions these reactions can be quite alarming and may give the impression that the situation is broader than what has been confirmed so far.
At this point, in my opinion, the most sensible approach is:
- Continue using EndeavourOS (or any other Arch-based distro) and the official repositories as normal, unless further evidence suggests otherwise.
- Avoid updating AUR packages for a few days, or update them individually and carefully, reviewing PKGBUILDs and diffs before proceeding.
- Stay informed and follow developments over the next days as more information becomes available.
- Only be genuinely concerned if you updated AUR packages during the affected period. In that case, use the community detection script and the published package lists to verify whether any of your installed packages were compromised.
- Take this as a reminder that depending too heavily on the AUR is not ideal. Having a relatively small number of AUR packages that you can comfortably keep track of and audit is likely the best scenario.
But please, let’s not panic or overreact. Otherwise, the attackers will have achieved even more than they originally intended.
Just my humble opinion.
all good aside not updating will not prevent from malicious packages you may have installed to act onto your system.
Gonna doublecheck all the python and ruby stuff on the list to the eos filesystem. nothing else worried me too much but the gtk themes. thanks for linking this joe
Exactly right? And funny thing is that I was literally thinking the same, but at day zero, when things weren’t this f***ed up… There’s absolutely no reason for Arch team not to close down AUR, like, immediately - that would be the sanest move to just “unplug” until things settle down a bit. There were 400 packages at first day, now we’re hitting the 2k marker, and now this, a new form of approach… And still, AUR is up, welcoming all the bad actors. Well okay, Arch closed down registrations, but still, at this point it could be anyone who’s “trusted” (long term infiltration) maintainer, because they still have registrations (or accounts got compromised).
As per news here:
We are actively working to track down existing malicious commits and attempting to prevent additional malicious commits from being pushed. While this is happening, and while we work to create a more permanent solution, users may see issues with the following:
Creating new accounts on the AUR Pushing package updates Adopting or creating new packagesWe continue to encourage all users of AUR packages to review all PKGBUILD and install script changes when updating, especially during this time. If you notice suspicious commits to a package that you use, please reach out to Arch staff via the aur-general mailing list with more information.
Despite the amount of packages within the AUR, of over 100000,
the actual number of package maintainers is actually quite low. There might be 140000 registered users. But only 69 package maintainers.
Additionally, keep in mind that the Arch devs do have other obligations to fulfill. And it may take some time until they’ve addressed this, analysed the whole campaign and that they most likely don’t have the means to enforce new policies as fast as other commercial entities are able to act. In short, they’re working on a more permanent solution and will make their decisions sooner than later.
I can totally understand that some are concerned due to the sheer number of packages that have been hijacked. But in terms of their popularity and usage… it’s less severe than some security issues or data leaks that has affected some of the commercial entities in the past. Arch is still open source and pretty transparent about all the challenges the distro is facing. Therefore you’ve got access to all of it security related issues and the community shares security related insights openly, unfiltered.
Last but not least, the rule and hint towards use the AUR at your own risk & check the PKGBUILDS before installing is still a result of limited manpower for the most part. If the Arch devs would have the capabilities and financial assets that an commercial entity is able to throw at the problem, they would already a have implemented a much more resilient system.
AUR software in the EndeavourOS repo
Please note that the EndeavourOS repo includes this software as-is from the AUR:
bashdb # debugger for bash scripts
downgrade # downgrades native Arch packages
paru # AUR helper
yay # AUR helper
zfs-dkms # kernel modules for the zettabyte file system
zfs-utils # userspace utilities for the zettabyte file system
So far I haven’t seen them on any malware list.
But if you do, please report it here.
Just clarifying, that number represents recognised package maintainers, who are given a higher level of trust in the AUR and are listed here:
They’d only be maintainers for a fraction of the (currently) 107,359 packages. The rest would be maintained by standard users.
I work with MacOS daily and seeing stuff like this happen really cements for me the superiority of its security model. I think something like SELinux should probably be default on all major distros. Accidentally installing a compromised package shouldn’t give it any power over your system except for those you give it explicitly. Now, even the MacOS model doesn’t prevent incompetent users from granting Full Disk Access or even access to other app data to any program that asks, but it would be a solid extra layer of security.
If you update your system, another just pushed package update may brake. In a rolling distro you can, at every second, have this one package that can suddenly break. Waiting won’t fix that.
Topic .. lets stay in the topic, i let it open for comments and may questions to resolve, but that’s not for general discussion.
5 Likes
Few months ago I switched to using an alias of parur='paru -Syu --repo'; so I still update frequently with that command that excludes AUR updates as usual and fortunately I was not hit with this AUR attack
I occasionally try normal paru (-Syu) to get AUR updates sync but even then I mostly update each package at a time as need arises for them, for example if something broke because of core package dependency updates.
just did the same for yay (alias with the --repo flag) because I like yay as it is more cenvenient over pacman but do not want AUR to be available.
One can always use plain
eos-update
i.e. without the AUR related options (--aur --yay --paru).
Or:
sudo pacman -Syu
Uhhh… I’m away for a weekend and all hell breaks loose. Not updating AUR until it’s safe to do so.
If you’re wondering which of your installed packages from the AUR may have been affected, this command shows your packages from the AUR that have been updated in June 2026:
for pkg in $(pacman -Qqm); do grep "^\[2026-06.*upgraded $pkg "'(' /var/log/pacman.log | tail -1; done | sort
The results show some detail about the most-recent update.