multiple malicious AUR updates

loqs · Yesterday 21:39:33

@silensys if you want the AUR moderators to see it I suggest you post on the aur-general mailing list. Somewhat similar post already exists https://lists.archlinux.org/archives/li … SNI7JSKPR/

wonderworld · Yesterday 21:42:32

I don't know about normal package adoption rates, but I guess there was a massive spike.
Maybe at least this kind of suspicious activity could trigger a warning in the future.

loqs · Yesterday 21:44:56

silensys wrote:

> "You *have* to vet the build. Every. Single. Time."
Correct, but still, reducing the attack vectors to a minimum is the best way to prevent such things to happen. Ever. Again.

After the xz incident a double digit number of new posters made suggestions on the Arch's gitlab for how Arch should be handling the xz package. As far as I am aware none of those posters ever made any contribution to Arch linux xz related or otherwise.

confusedwiseman · Yesterday 21:57:53

First, thank you to all of those who are addressing the issue of the malicious actors over the last couple of days.

Is there a good way to help validate if I've installed one of the malicious packages?

I've done grep -r "lockfile-js|js-digest" and run clamscan.

There was a script by lenucksi on github referenced, which I've not been able to fully review yet. It seems very helpful at first pass, but let's not just run scripts without understanding.
I know and understand the use of the AUR is at my own risk. I do vet packages that get installed, but like many humans, I do make errors. Many of you are FAR better at coding than I am.

seth · Yesterday 21:58:15

1. automated how? How is a good commit distinguished from a bad commit? If someone acts malicious, why not ban them outright?
2. a solution about what to do when an account gets silently compromised? Assume the system compromised until proven different (ie. vet the PKGBUILD)
3. you've missed the xz-disaster? And the AUR maintainers are supposed to track in some cases hundreds of upstreams? How closely?

like, new registered users seriously shouldn't be able to adopt packages

So I register 100 users, build up some reputation by genuinely packaging stuff (AI slop generated with my other hat on, or maybe some fun tools, fractional ASCII animations) and after 30 days have your blind trust when I launch my attack?

The point is, you're trying to introduce some faux trust. Don't. There're way to many links in this chain to ever trust it and that needs to be clear and no diluted by some completely unreliable trust system.

I'd track the AUR commits for fuzzy patterns (the attackers may learn and introduce randomized noise) for internal alerts, not mislead the users about the nature of the AUR at large or any specific user or package there.

silensys · Yesterday 21:58:22

loqs wrote:

@silensys if you want the AUR moderators to see it I suggest you post on the aur-general mailing list. Somewhat similar post already exists https://lists.archlinux.org/archives/li … SNI7JSKPR/

Thanks. Good to know others are also brainstorming about the preventions, and yes I am planning to reply there, I just can't because I subscribed to the mailinglist after that mail landed there, sadly so it's not in my inbox for me to reply to. I hope someone who has it, will reply to it so it lands in my inbox so I can reply to that thread. It's a shame that postorius webmail doesn't allow direct replies from the browser

loqs wrote:

silensys wrote:
> "You *have* to vet the build. Every. Single. Time."
Correct, but still, reducing the attack vectors to a minimum is the best way to prevent such things to happen. Ever. Again.
After the xz incident a double digit number of new posters made suggestions on the Arch's gitlab for how Arch should be handling the xz package. As far as I am aware none of those posters ever made any contribution to Arch linux xz related or otherwise.

Fair point, and I get the frustration with post-incident noise. I’m not a coder myself, so you won’t see me spamming with empty talk, but high-level strategy and architectural ideas are still valid pieces of the puzzle, even if they come from the 'ideas' department rather than the 'commits' department.

silensys · Yesterday 22:28:53

seth wrote:

1. automated how? How is a good commit distinguished from a bad commit? If someone acts malicious, why not ban them outright?
2. a solution about what to do when an account gets silently compromised? Assume the system compromised until proven different (ie. vet the PKGBUILD)
3. you've missed the xz-disaster? And the AUR maintainers are supposed to track in some cases hundreds of upstreams? How closely?
like, new registered users seriously shouldn't be able to adopt packages
So I register 100 users, build up some reputation by genuinely packaging stuff (AI slop generated with my other hat on, or maybe some fun tools, fractional ASCII animations) and after 30 days have your blind trust when I launch my attack?
The point is, you're trying to introduce some faux trust. Don't. There're way to many links in this chain to ever trust it and that needs to be clear and no diluted by some completely unreliable trust system.
I'd track the AUR commits for fuzzy patterns (the attackers may learn and introduce randomized noise) for internal alerts, not mislead the users about the nature of the AUR at large or any specific user or package there.

1. You asked what is handing out points, automated was my answer only on points, nothing else, how it decides, I can't tell, I'm not a coder, just a theorycrafter. The idea is that untrusted people will have their submissions to be manually vetted by AUR mods at the earlier stages, hence why I said "and secure against abuse via combining it with further manual interventions".
2. Btw I thougt you'd know: 2FA
3. I wasn't affected, but didn't miss the news, I was an MX-Linux user back then it happened, but they weren't affected thankfully. Now I'm an Arch base user (Garuda); Thankfully I'm still unaffected by these new attacks, because I use IgnorePkgs, and only have 2 AUR pkgs for my printer, which was updated in ... forever But still, there should be some extra safety layer, at least some bare minimum, for people who don't know how to read or what to look for in the PKGBUILDs or how to understand them.

So I register 100 users, build up some reputation by genuinely packaging stuff (AI slop generated with my other hat on, or maybe some fun tools, fractional ASCII animations) and after 30 days have your blind trust when I launch my attack?

Ok, then we're full ears of what idea can you throw in to the common bin to mitigate that.

The point is, you're trying to introduce some faux trust. Don't. There're way to many links in this chain to ever trust it and that needs to be clear and no diluted by some completely unreliable trust system.

You're totally missing the point, which - still - is, that I'm giving ideas, to reduce the attack surface, and that's why I said the list is an as-is proposal. One thing I know is that every problem has a solution, although not a 100% perfect one. Since brainstorming is open to everyone, we're not here to shoot down each other's ideas, but to build a safer computing environment for everyone's daily life.

I'd track the AUR commits for fuzzy patterns (the attackers may learn and introduce randomized noise) for internal alerts, not mislead the users about the nature of the AUR at large or any specific user or package there.

That sounds cool but preventing automated sybil attacks or long-term sleeper accounts requires multiple layers, which is why a trust system must be combined with active anomaly detection (and manual inspection too) rather than relying on a single silver bullet, it is true that no system creates absolute blind trust, but reducing the volume of low-effort malicious adoptions allows both mods and users to focus their manual vetting where it actually matters imho.

256 · Yesterday 22:38:30

seth wrote:

The AUR is not trustworthy and cannot be w/o stopping to be the AUR.
The PKGBUILDs there are suggestions/inspirations to build a package.

I agree the AUR can't be trustworthy over all, but I think the conversation here should be seen as a matter of degree rather than a binary "should we or should we not make it secure". The fact that people are trying to revert these changes and ban the accounts indicates that they are already trying to make it secure to some (albeit limited) extent.

Also, some people in this thread have mentioned the existence of people who don't read the warnings about the AUR, and won't learn how PKGBUILDs work before using the AUR. I think those people simply shouldn't use Arch, at least not without changing their mindset about it. Trying to idiot-proof the AUR misses the point of what Arch is supposed to be, in my opinion. (I'm not saying nobody should do anything about the attacks, I'm just saying we shouldn't go too far with it.)

silensys wrote:

Thanks. Good to know others are also brainstorming about the preventions, and yes I am planning to reply there, I just can't because I subscribed to the mailinglist after that mail landed there, sadly so it's not in my inbox for me to reply to. I hope someone who has it, will reply to it so it lands in my inbox so I can reply to that thread. It's a shame that postorius webmail doesn't allow direct replies from the browser

The mailing list site has "download" buttons that apparently give you gzipped .mbox files. I haven't tried them but they'd presumably work if your mail client supports those.

loqs · Yesterday 23:23:51

.SRCINFO was added due to the security risk of Arch parsing PKGBUILDs which illustrates one of the constraints. The situation may have improved since then. AIs should be able to parse through all layers of complexity and obfuscation but then Arch would need to be paying for that and they will still make mistakes or you have to trust external reviews. Human expert review is constrained or limited by how experts are selected and the volume of reviews each expert can manage. See the delay on aur-requests. Automated reputation based systems risk being gamed.

Last edited by loqs (Yesterday 23:24:12)

noesoespanol · Yesterday 23:55:46

progandy wrote:

Sidekick wrote:
Wait how can this happen? Arch has a very good trusted user system - to the point where it has so far deterred me from getting involved as I do not have the time for that. How can some random accounts just push code changes *and* let those go live without any kind of review system in place?
Packages in the official repository are not affected, only a limited group of verified users (developers, trusted users and so on) can push there.
Someone is taking over orphaned AUR packages automatically and adding the malware. Orphaned means there is no maintainer for these packages and anyone with an AUR account can accept that maintainer role and submit updates.

What an unbelievably idiotic (excuse my French) system. It's basically open for business, just come in and install virus and whatever you want in that case. It's like watching a horror show now. Jesus.

I mean, even random forums have at least one moderator keeping an eye on things. In this day and age of bots and nut jobs all over place, I think time to put some kind of watch system on AUR at least.

I agree with the mod, reputation system and such is nice in theory but easy to game as well.

Bottom line is, it's a hard problem to solve actually.

Last edited by noesoespanol (Today 00:08:02)

cryptearth · Today 01:48:47

silensys wrote:

2. Btw I thougt you'd know: 2FA

sorry for going off-topic, again, in this quite reasonable topic, but ...

just yelling "2FA" into the room doesn't cut it and is thaught too simple about
as proper implementing proper multi-factor auth isn't as easy as to just "add some rng on your phone to some account"
yes, it is better than just the old user-id + password - but when talking about supply-chain you need to dig deeper
remember when LinusTechTips got compromized? it wasn't any of their high value accounts but an active token got stolen from a low-level account whoch had way too powerful privileges - and it took Linus and YT staff hours to figure out what really happened - and even after the real compromize was identified itvwasn't easy to fix due to googles own tools

just slapping "you need another factor to authorize" does not help if you steal an already authorized token - which is what these credential stealers after
many of my accounts are highly secured - but what does this hdlp me when someone breaks into my homenetwork and abuses a legit token from within my network? 2FA doesn't help here!
it's in its name: authentication! it doesn't prevent abuse of valid authorized tokens!

in fact one would need to go full ham: use a hardware token like a yubikey or similar on which a on-device generated key lives - and only it should be allowed to sign commits
single-point-of-failure: although one can import software generated keys onto such tokens a on-device key can never be extracted - and pgp doesn't really know the concept of hierarchy like x509 does: it's hard to properly setup the same sign key on multiple hardware tokens - and require said key to be generated in software on an air-gapped pc - which contradicts the idea of "key generated on-device"

also: MANY pgp keys used today are decades old, were generated in software on potential unsecure hardware - how could i possible be sure of, let's say, grommit's key without meeting them in-person as pgp was originally intented to be used? just because a dozen other people unknown to me trust it?

gist is: there're too many loopholes to make user created content ever secure - let alone official repos (fun fact: although available pacman by default doesn't even verify signatures of a repos current database)
where shall we start? by having each and every AUR user manually verified by AUR mods? who verfies those mods? who guarantees the arch keyring doesn't get compromized?
in the end we all trust some random solely based upon other randoms trust them - that's the nature of how web-if-trust works

the linux kernel was written by some finnish student - today it contains code of thousands of people - yet we blindly trust it and those thousand devs unknown to us the very same as we blindly trust the AUR

2FA? web-of-trust? these are just buzzwords completely missing the underlying issues

Last edited by cryptearth (Today 02:03:56)

waitnsea · Today 05:28:05

Hi,
Using @Kidev/check_aur_infected.sh I obtained 3 malicious :
-coolreader
- grpn
- vidcutter
Immediately removed of course, looked at them in pacman.log :
- grpn installed once on [2024-11-20T17:28:07+0100], -vidcutter upgraded on [2026-01-10T20:32:43+0100] [ALPM] , maybe these two were healthy ?
But - coolreader has been updated recently :
[2025-08-30T20:48:26+0200] [ALPM] upgraded coolreader (3.2.59-7 -> 3.2.59-8)
[2026-04-12T09:54:11+0200] [ALPM-SCRIPTLET] foreign coolreader
[2026-05-23T08:06:35+0200] [ALPM-SCRIPTLET] foreign coolreader
How to know malicious package which could have been brought to my system ?
(edit : I launched @Compagnon commands - no bad files)
Clamscan full system is running - may be it will be very long to give results
Thanks for help

Last edited by waitnsea (Today 05:47:45)

gofree · Today 07:07:02

I had similar results with libgdata hopefully its clear as the malicious campaign lasted last 2 days - this is something I really miss from official information. Hopefully I'm right about this one and I understand it correctly that the packages we're compromised only if built/updated for the last two days or so.

waitnsea · Today 07:09:52

@gofree - Thank you,feeling better

seth · Today 07:18:11

silensys wrote:

Ok, then we're full ears of what idea can you throw in to the common bin to mitigate that.

256 wrote:

the conversation here should be seen as a matter of degree rather than a binary "should we or should we not make it secure".

#1 Whatever hypothetically done about this must NEVER suggest there would be any degree of trust users could invest into the AUR.
#2 Making the registration (or defacto participation) a frustrating PITA like the gitlab bugtracker might limit the attack surface on the AUR but will choke it and ultimately shift it elsewhere (distributed AUR alternatives, github repos of PKGBUILDs)
#3 you cannot secure an open system. The internet is not "safe", it relies on your brain (should I click on that) and local nannying by your browser (curated gray/blacklists) to shield you from bad things happening
The curated blacklist is the currently ongoing moderation.

Let's assume I had tried to install/update an affected package. It would have required me to install npm as dependency and my response would have been "Most certainly not. Why the fuck does this depend on npm?" and that alone have the PKGBUILD subjected to copious scrutiny.
Why would someone ever allow a package to introduce such dependency out of the blue? Esp. after npm was *just* in the news again.
The honest answer is "Because you didn't notice. Yay just did that."

The situation simply exposes a fundamental misconception of what the AUR is resp. what you're looking for.

One could add a hierarchical system where some dude™ gets to approach one of 69 AMUR (arch moderated user repository) authorities "here, I'd like to package this and have come up w/ this PKGBUILD" and the AMURAs then review the PKGBUILD and decide whether they want to add that to the AMUR (or whether it maybe needs adjustments or is shady or just not worth the effort)
But of course that doesn't shield user users from any upstream manipulations after the AMUR package was added. Also it seems kinda insane to have every user compile the same package locally and a solution of that could be that the AMURAs just build it and provide the precompiled and signed package.
Oh, wait… I think I just invented a better name for the official arch repos.

gofree · Today 07:19:19

I'm not 100% sure, just reading between lines that it was for the last 2-3 days. Somebody with better insight should confirm. I felt naked after running first scans aginst the list https://md.archlinux.org/s/SxbqukK6IA finding libgdata installed ( hopefully luckily it was installed on february.

seth · Today 07:35:16

https://lists.archlinux.org/archives/li … E4QJAFJJ2M is from late May

gofree · Today 07:51:47

Ok, might be unrelated to the recent(?) attack ? browsh-bin its not even on the published list https://md.archlinux.org/s/SxbqukK6IA. So, honestly I miss kinda more information of timeframe of this situation. Guess thats why there is ...propably more packages, the list might not be complete....

P.S. The info is out, people are panicking...trying to keep calm, doing recommended checks. Still the timeframe in some official info would calm a lot of people I guess.

frihet · Today 08:04:03

I have a idea to keep privacy for maintainers (no id requirements or sth), but to increase the security when updating AUR packages on systems that are running Arch Linux. What about implementing a feature into the yay command, so that if a maintainer changes, you will immediately get a warning like "[ATTENTION] The Maintainer of the package XYZ has changed since the last execution.". I would then as a user go onto the package and check if he or she is trustworthy. The package update will not continue, until I by myself press "y". The status for each package maintainer could be stored and updated locally, and be retrieved within the update process. Also we could do things like warn users, if the PKGBUILD had been changed, or other dependencies added, that weren't there before.

Why not doing such things? Even if non-technical people don't want these messages, there could be such implementation for tech affine people, that can be activated.

If not, maybe I will build a Bash script or something for that.

Cheers and stay safe..

wonderworld · Today 08:17:55

What I did trying to confirm if a bad package was installed or not is this:

Identified dangerous packages with: https://github.com/lenucksi/aur-malware-check
Used the updated package list from here -> https://md.archlinux.org/s/SxbqukK6IA (might be outdated now, did it yesterday check if you can find a fresher list)
Referenced from the mailing list here -> https://lists.archlinux.org/archives/li … 2JHYB7ZS4/

Script will parse your pacman.log and tell you if and when a bad flagged package has been installed.

After that you can check the AUR activity of the package in Github
https://github.com/archlinux/aur/activity
(click All Branches, type name of package)
You will see the changes for the package
Use the three-dot menu to the right to see changes
Identify the commit that introduced the malware

Now compare the install date from pacman.log with the date of the malware commit.

As @Sidekick said before at least some of the malicious packages did not have updated version numbers, so you might be lucky and it wasn't installed at all.

I was affected by a single package but it wasn't updated, because it's version number did not change after the malware injection.

So it looks like at least some, maybe all? packages must be installed for the first time to install the malware?
Would be nice if others could confirm that.

Last edited by wonderworld (Today 08:18:44)

Whoracle · Today 08:28:22

frihet wrote:

Why not doing such things? Even if non-technical people don't want these messages, there could be such implementation for tech affine people, that can be activated.

That would be a feature request at yay (or other aur helpers), not here in the arch support forums. For some reason this doesn't get into peoples heads (and I blame "following youtube tech guys for this, mainly, because the docs are pretty clear):

The AUR is unsafe, AUR helpers are not officially part of ArchLinux and are not supported here. If you use yay/paru/anything other than pacman/makepkg etc., you are in two separate ways in unsupported territory: You are using AUR packages, and you are using an unsupported package manager wrapper.

That's OK, I also use yay, but it's high time people learned the damn difference and made informed choices... [/rant]

SimonJ · Today 09:17:33

What made me laugh was the test script was offered as curl |bash, I just hope everyone read through and did not actually just copy and paste the one liner.

Sidekick · Today 12:35:59

wonderworld wrote:

So it looks like at least some, maybe all? packages must be installed for the first time to install the malware?
Would be nice if others could confirm that.

I don't think so. At least when running makepkg, it will compile/build the package and only pacman itself will then check the version of the package. I'm not sure when this

install=[packagename]-deps.install

is executed and depending on that a system would already be infected even if the same package version is already installed. I'm guessing yay checks the package version before downloading and building a AUR package, but I don't know that.

Last edited by Sidekick (Today 12:37:31)

noesoespanol · Today 13:24:10

seth wrote:

...you cannot secure an open system. The internet is not "safe", it relies on your brain (should I click on that)...

100%! I think that sums up the entire situation well.

Also as someone said here, AUR isn't part of Arch. As a matter of fact, I had some issues updating VMware and yada yada yada, long story short, I needed to use AUR... and after pondering a little bit, I chose to not run VMware rather than using AUR.

I think people, me included, sometimes forget that things like AUR, is basically "a random FTP server somewhere on the internet", as in, don't randomly download things and run them into your systems. It's not a curated "app store" (heck, even Google Play probably isn't fully safe and has had issues).

wonderworld · Today 15:03:51

Sidekick wrote:

I don't think so. At least when running makepkg, it will compile/build the package and only pacman itself will then check the version of the package. I'm not sure when this
install=[packagename]-deps.install
is executed and depending on that a system would already be infected even if the same package version is already installed. I'm guessing yay checks the package version before downloading and building a AUR package, but I don't know that.

Yes, that seems to be the question. Does it identify and download every new commit or every new version only?
How can we find out?

edit:
OK, a screenshot in their Github readme shows a update to "latest-commit". This sadly might point to the worse option? It's for a git package though.
https://camo.githubusercontent.com/7d69 … 312e737667

edit2:
I asked the yay guys. Let's see if they will answer.
https://github.com/Jguer/yay/issues/2849

Last edited by wonderworld (Today 15:34:58)

Arch Linux

#51 Yesterday 21:39:33

Re: multiple malicious AUR updates

#52 Yesterday 21:42:32

Re: multiple malicious AUR updates

#53 Yesterday 21:44:56

Re: multiple malicious AUR updates

#54 Yesterday 21:57:53

Re: multiple malicious AUR updates

#55 Yesterday 21:58:15

Re: multiple malicious AUR updates

#56 Yesterday 21:58:22

Re: multiple malicious AUR updates

#57 Yesterday 22:28:53

Re: multiple malicious AUR updates

#58 Yesterday 22:38:30

Re: multiple malicious AUR updates

#59 Yesterday 23:23:51

Re: multiple malicious AUR updates

#60 Yesterday 23:55:46

Re: multiple malicious AUR updates

#61 Today 01:48:47

Re: multiple malicious AUR updates

#62 Today 05:28:05

Re: multiple malicious AUR updates

#63 Today 07:07:02

Re: multiple malicious AUR updates

#64 Today 07:09:52

Re: multiple malicious AUR updates

#65 Today 07:18:11

Re: multiple malicious AUR updates

#66 Today 07:19:19

Re: multiple malicious AUR updates

#67 Today 07:35:16

Re: multiple malicious AUR updates

#68 Today 07:51:47

Re: multiple malicious AUR updates

#69 Today 08:04:03

Re: multiple malicious AUR updates

#70 Today 08:17:55

Re: multiple malicious AUR updates

#71 Today 08:28:22

Re: multiple malicious AUR updates

#72 Today 09:17:33

Re: multiple malicious AUR updates

#73 Today 12:35:59

Re: multiple malicious AUR updates

#74 Today 13:24:10

Re: multiple malicious AUR updates

#75 Today 15:03:51

Re: multiple malicious AUR updates

Board footer