Does CachyOS take packages from AUR and re-bundle them into their own repositories? I can see there is a space for a security-focused Arch downstream derivative or fork if Arch refuses to redesign its security approach. Keeping AUR at arms length and saying “it’s not our problem” is no longer sufficient or responsible.
there are many packages that are built from the AUR PKGBUILDs, I have asked this many times, is there verification when a package receives an update? Can you guys link some proof?
There’s no conflict here. Your txt file is excellent and more than Arch developers seem to be doing to support the broader Arch user base where they are providing very little communication. The broader concern is the lax Arch culture around security. Your executable is trusted because you are trusted. As a general security approach, it might be better to only provide users non-executables. You can see how users might trust your script and then a bad actor comes along and repeats the process with a script that broadens an attack like this. Thanks for maintaining this .txt list and for what you’re doing.
Maybe I can help out here. I believe the main reasoning is that the original *.sh approach has people actually executing shell script from - please excuse - some random dude on the internet, whereas the current approach just browses a text file with on-board capabilites, compares it to the result of a pacman command and echoes the count of matches. No script execution involved.
Hope that clarifies the situation a little.
Yes it does
I like it when other people understand modern OPSEC 
guys I’m new with arch, what I hava to do to verify if my setup is infected?
This is a safe, non-executable script that will allow you to accomplish this:
local=$(pacman -Qqm | sort); curl -s https://cscs.pastes.sh/raw/aurvulnlist20260611.txt -o /tmp/aur.txt; remote=$(sort /tmp/aur.txt); m=$(comm -12 <(echo "$local") <(echo "$remote")); echo "Installed AUR packages flagged: $(echo "$m" | sed '/^\s*$/d' | wc -l)"; [ -n "$m" ] && echo "$m" || echo "None detected."; echo "Total packages in vulnerability list: $(wc -l < /tmp/aur.txt)"
You can install jack2 from extra to replace jack from AUR.
@Noemy-Amelie I’d rather go with a version that does not involve running some *.sh script in bash. 
What @cscs writes in the first post:
echo "Affected Packages Found:"; comm -12 <(pacman -Qqm | sort) <(curl -s https://cscs.pastes.sh/raw/aurvulnlist20260611.txt | sort) | { read -r l && printf '%s\n' "$l" || echo "None. No known compromised packages are installed."; }
Also ask yourself if you ever installed AUR packages and/or use pacman -Qm to find out.
Actually, they weren’t. I’m fact, that “attack” was similar to some of the packages on the list this time around.
Basically, they were disguised to appear like official AUR packages in order to trick people into downloading them instead.
See here:
The affected packages were firefox-patch-bin, librewolf-fix-bin, and zen-browser-patched-bin. None of which were the actual browser packages firefox, librewolf-bin, or zen-browser-bin. So, not serious at all unless someone was fooled by the “fix” or “patch” in the names and made no effort to check whether what they were installing was the real thing.
That you thought it was the actual browsers is unfortunately a byproduct of modern internet news reporting and social media. Amplifying alarm drives engagement.
Even the article I linked is guilty of this(the owner of Phoronix jumps through a lot of hoops to keep the lights on). The article title “Arch Linux AUR Packages For Firefox & Other Browsers Removed For Containing Malware” is misleading clickbait. It’s only once you get into the body of the article that you see that the packages are really just phishing attempts rather than compromised packages that people actually use.
Which leads us back to today’s AUR “attack”, which is just more of the same only more packages in a shorter amount of time. As you surmised in your post “If the list consists mainly of unused and/or obsolete packages, the situation isn’t that serious”, the afflicted packages are not widely used and are mostly either old or fringe abandoned personal projects that were orphaned and taken over.
The truth is, this AUR attack happens every single day only in more isolated doses. Nobody pays any mind to it because it affects the same types of fringe packages that nobody in their right mind actually touches. That it happened to so many of those types of packages all at once is certainly newsworthy, but hardly worth going to red alert over.
It does speak to an architectural design of Arch that could benefit from being modernized with security top of mind. A community-driven project is always going to have a competing tension between welcoming new contributors and making it easy for them to contribute and security. Red Hat/Fedora and Debian/Ubuntu have an enterprise revenue stream and staff that can mitigate security risks. OpenSUSE has a rolling release model that does security testing across packages differently than Arch because it has enterprise revenue. Arch is such a dominant distro in the Linux community, creating all kinds of great downstream projects like CachyOS, EndeavourOS, SteamOS, that it does need to re-think its approach to security for the benefit of all Arch projects. Atomic Attack was avoidable.
Ah, I get it… a weird rationale; because many people are very stupid, they will just run the script whether they know you or not and blindly trust that it works.
Meanwhile, the agenda is being pushed that AUR is bad because there are risks involved…
So this is the protective stance coming out.
Look, for folks that feel that way - I recommend you go grab an immutable distribution and get out of this kitchen…
There are sharp knives in here.
Now I’m not saying you shouldn’t look at the script and judge for yourself, but I’ve seen CSCS around for quite a long while… and have seen wobbles and occasional flawed behaviours.
But with this script - nah, never in a million years would it get posted here if it wasn’t 99% likely to work for you, or fail miserably without success (as was the case with figuring out the fishy issues).
But here we come to an important point, a VERY old mantra:
Only install software from TRUSTED SOURCES.
When those sources aren’t trusted, we must dig in and investigate - this is why we need to analyse PKGBUILDS.
If you aren’t confident or qualified for the task, there’s a forum here where you can ask questions…
I really am finding it very difficult to understand some of the mindsets here.
GitHub - linx-systems/clamui: ClamAV Desktop application ( GUI ) · GitHub is this enough for aur malware scan?
No, ClamAV would not have protected against this attack.
@cscs code is “safe” too - lots of eyes on it confirming it looks good. Someone who doesn’t understand either blindly copy/pasting one vs tge other doesn’t build safer habits. If we really want “safe” and conservative habits we’re probably looking at a separate list and processing that’s explained step by step instead of a 1-liner.
the script is less opaque to a non-savvy user than your one-liner by far.
Bit if a lesson for some people is to install clamAV on their machines after a security incident that’s a win!
How about the incident at this moment? Are things already back to normal? Can I update safely now?
I think I’ll still wait a few more days.