61
votes
Arch User Repository compromised, 1500+ packages affected
Link information
This data is scraped automatically and may be incorrect.
- Authors
- cscs, Sunda-Spirit, johnblaze00, mattsteg, Dirge, Derp_Derpington, HardCode4All, Uncle_Spellbinder
- Published
- Jun 12 2026
- Word count
- 1266 words
I’ve long since been bothered by these blame deflections in the tech world. No one is reading the source for everything they install the same way no one is reading the full terms and conditions for every service they use. But whenever something goes wrong the blame deflection happens and it’s the users fault for not doing the impossible to avoid it.
Realistically we need systematic protections and checks rather than loading all the responsibility on to the user. Programs should be sandboxed as much as possible, all package maintainers should require checks and 2FA, etc. Programs should be given secure storage vaults they can drop things like auth tokens in where other programs can’t read them.
How is this blame deflection? The protections you're describing are reasonable, but they apply to a fundamentally different repo than the AUR, which is very specifically not a trusted distribution channel. This isn't the same as installing from a distro's default repositories. User review is the main security mechanism.
It’s larger than just the AUR, the way the average person uses Linux is deeply insecure, half the projects advise you to pipe curl to bash to install. Distros are built on a security model which hasn’t been useful since the 90s.
Really the advice should be to stay away from the AUR because it’s fundamentally insecure, rather than telling people to review every build script which people just won’t do.
If Linux distros want to be actually secure in the modern day they need to assume the user isn’t auditing every line of code they run and should contain malware so it doesn’t have the ability to steal data from other apps.
I would be 100% agreeing with you if this had happened to literally any other distro, but you cannot tell me an arch user running unvetted scripts is not responsible for their actions. That is ludicrous.
Yes, plenty of things can and should be improved in the broader Linux world, but we're talking about a niche of a niche of a niche that is very different from Ubuntu or Fedora, for example, where there is a claim of trust to precompiled packages in their repos. The documentation surrounding Arch and the AUR is very explicit in it being the user's responsibility to cover their own ass. I would be much more willing to have this conversation around the xz fiasco, for example.
Arch User Repository - ArchWiki
I think it's very important to note, that while yes, the AUR is unofficial etc., there's an astronomical difference between
and
There is no justification for this sloppy of a process. At the very least, a new maintainer claiming packages people have installed needs some approval process, even if it's community driven. I.e, if it gets X downvotes in a week, it doesn't go through. Something MusicBrainz does for example.
I agree the process is terrible; I never tried to justify it. I am simply pointing out that it is a complete misunderstanding of arch and its ethos to claim an arch user is not responsible for their system, especially when they use the AUR. That's all.
On the other hand, the compromised PKGBUILDs do two things: add
npmas a dependency and use it to installatomic-lockfilein a post-install script. So unless someone is the type of user who actually scrutinizes every line of code from a git repo (or is rightfully distrustful of npm dependencies), that person would not notice the malware injection.It's like blaming Tesla drivers for crashes when the autopilot randomly fails and the driver didn't respond in the 3 second window between autopilot's disengagement and the accident. The larger issue is that the AUR is fundamentally insecure but works well in >99% of cases, luring users into a false sense of security; it's a design problem.
More like blaming the user if they installed unsupported packages from source and then their autopilot failed because of that.
I don't use arch . but i wonder if there should be some kind of pop up on a first install of a AUR package or downloading the script. that at least gives people the indication they are seeing something important.
in the AUR website it says:
But it is written in a small way at the bottom of the package (like how TV commercials write all the shady stuff in small letters).
People compare this to terms of service. but at least for terms of service there is tosdr which can provide some feedback.
The aim should be getting something like informed consent.
There would be no pop-up - it's entirely a terminal thing. The official way to install AUR packages is quite complex. You can't do it if you don't understand how to do it (or copy a few lines of code from the internet). Unsupported (and discouraged) AUR helpers make it really simple, but you have to do that yourself.
I would say it's already very informed consent, it's just that people ignore the warnings.
Also AUR helpers are not in the arch package managers specifically for this reason - if you want to get one you'll have to at least manage to do the process manually once.
Unfortunately, some arch derivatives ship AUR helpers out of the box. Cachyos for example, ships with paru. They also ship with GUI package installers, like octopi, which allow you to select AUR packages (though it's clear you're doing so).
not really? AUR is like PPA or COPR
Yes, they also take additional steps to utilize because they are community provided with all the risks associated with that. The point I was trying to make is that an arch user is expected to be a full sysadmin and attracts a very different userbase than Ubuntu/Fedora. Sorry if that was unclear, I should have framed it differently.
I don't think there's really a secure way of getting software that doesn't involve trust. It goes beyond distros as most developers will just pull down code and run it on their usually highly privileged machines. Since you can basically get code execution going by someone running
git statusin a repo (commonly done to get a nice status line), you can't even trust an "inert" repo. That is essentially the first command I run after git clone and it's basically muscle memory at this point! TBH for most users at this point never leaving the walled garden for the bazaar is probably advisable. For devs I think we need to rethink dependency management fundamentally. The supply chains attacks the last few months should be enough to convince even non paranoid CTO/CIOs that dependencies are bad. It's either that or maybe run organisations with an acceptance that you are breached (which might be a good idea anyway).We need secure OS design that protects the users important data even in the case of malicious software running. Sandboxing applications is absolutely essential.
Currently the security model of Linux relies on the user auditing every line of code running on their computer, which is impossible so no one does it.
Corollary: stay away from arch for anything serious, because you will eventually need something that's only on the AUR.
I strongly disagree. I have precisely one AUR package installed and it's this one for adding a weather widget on my desktop. I do nearly all of my work on my computer (mostly creative work and audio programming) and I can do it all through regular Arch packages. If I desperately needed something that wasn't in the official repos I could easily get a flatpak. This is the case for virtually every distro out there. It's not like the official Arch repos are far more limited than other package managers and users are forced to go to the AUR where they otherwise wouldn't be on other distros; the AUR is a bonus option for package installation on top of Arch.
Like what? This may have been an issue at one time but I would guess most people's needs would be met by flatpaks for anything that isn't in the repos.
Many things like DEs and WMs aren't workable as Flatpaks. I see a lot of compiz and other WMs and forks and variants in this list of affected packages as well.
Yes, this is exactly why Arch does not provide a package manager for the AUR; PKGBUILDs just provide a reference that you have to manually clone and build.
Notably, none of the "AUR helpers" are available in the official repositories, either; you have to manually build and install them, signifying how they are fundamentally unsupported and potentially insecure.
Back when I used Arch, I would avoid the AUR as much as possible and pin my packages to a specific version (there's no way I could properly vet a slew of random PKGBUILD updates).
I 100% support the need for sandboxed mechanisms for Linux distributions in general, though; it's horrifying how normalized
curl | bashscripts are. But this is a feature for a different distro, as Arch forgoing this and offloading it to the user is a core part of the distro's design. Every user is expected to be a sysadmin for their system. You are meant to review every PKGBUILD update and monitor the news feed for alerts.Unfortunately, this fact has been dismissed as performative elitism rather than the legitimate warning it is.
I've been using Arch since at least 2005; the AUR has been a known potential exploit vector that whole time. There have only been a couple of known instances of something like this happening in the past to my knowledge. Unfortunately, the last few years has seen it happen more than once. This one is on a scale that is larger than anything I've heard of before. The big deal that I see here is that orphaned packages were adopted, and a compromised update was pushed en masse. So anyone who happened to install an updated PKGBUILD of a package they've been using for years was at risk.
Unfortunately, due to the design of the AUR, I can't think of any good potential solution. The point of the AUR is for users to share a PKGBUILD to install packages that no maintainer has the capacity to maintain. If a known maintainer did have the capacity to moderate and maintain that PKGBUILD, it would be in an official repository. That is the whole point.
That leaves us with maybe two official options that I can think of:
As a user, uninstalling any orphan packages is probably for the best. Aside from that, reviewing the PKGBUILD is the official recommendation, and for good reason.
Does the AUR provide a mechanism to determine package/
PKGBUILD(if even applicable?) “orphanaged status” (or if the user providingPKGBUILDrecently changed)?That way, in a next step users could set up rules for e.g. warning, then blocked execution for orphans over a given number of months (or the reverse and requiring a cooldown-before-use for the case of submitter-not-maintainer user having changed).
This is one of the reasons why developers and distro maintainers are going big on containerized applications like Snap and FlatPack.
Everyone using even a remotely competent AUR helper sees the diff of every package automatically by default. It is reasonable, I did it for a over decade. 99% of aur diffs are just hash + version bumps, and any that aren't deserve scrutiny. The point of the AUR is no permission, no vetting no control. I packaged things I thought were useful and if it has been turned into a full time job by some kind of background vetting process I wouldn't have bothered.
In some respects I welcome this, not because I think the AUR should change but because it will force people to wake the fuck up and confront what they are doing. Do you want to be in charge of your computer or not? If you don't, buy a mac and let Cupertino decide (or Redmond / windows, I don't care). If you do and you want to use the AUR, read the diffs. If you don't then use something else. This isn't deflection. You can only make the experience of using a computer so safe before it becomes a phone. I don't want a phone.
Ubuntu has app armour, fedora ships with selinux ootb. Flatpak has its sandboxing, Wayland has completely locked down the compositor. Landlock, bubble wrap, namespaces, systemd service hardening, the whole trend is moving towards better security, and better security primitives.
I'm not sure I agree. I don't use arch, but isn't this basically akin to downloading and running a script or a binary someone shared online? Yeah, it's pretty expected that you either verify the source or the content and it's always been that way. Except it's even worse, you will get updates for these programs and they will also pull dependencies of their own...
On Windows you’d have SmartScreen and Authenticode/Signing. On Mac you’d have signing, notarization, and Gatekeeper. On Mac I think if your using homebrew is bypasses a lot of that though.
So it’s not impossible, just harder and maybe expensive. In a world where AI accelerates discovery and exploitation maybe the era of “buyer beware” as the only protection isn’t going to cut it anymore?
On my personal Windows laptop, I have so much hacky stuff in place to flip fingers all over to MS's attempt to "save" me. That being said, my last infection was something I suspected would cause it, and that was over 20 years ago. My phone as well is hacky but I'd bet secure: running GOS which limits options, and yes, I have a number of installed apks from non-Play repositories, and honestly I feel more comfortable with me being the police than the police taking over every aspect that they should not necessarily need.
(Btw, not only do I use Arch but I also read ToS. People are too easily wooed by convenience. That is the problem.)
It has since been resolved.It has not. See hereA list of affected packages is here.
This won't be resolved until there is some kind of moderation process surrounding the adoption of orphaned packages.
Replies like this indicate that the AUR should not be given to anyone who downloads Arch. You should have to complete a written test to prove you understand what it is (i.e., almost no one in this thread knows what they're talking about)
Thanks, that list just keeps ballooning out. I thought I had checked my PKGBUILDS, but this made me question my sanity. I happened to update literally right after the attack occurred, so the paranoia was strong. 🤢 Thankfully it doesn't seem like I got hit.
I'd like to just throw my dumbass out here and ask where this mailing list is?
Here you go:
https://lists.archlinux.org/mailman3/lists/
Arch Linux AUR Hit By Another Wave Of Now More Sophisticated Malware Attack
Here we go again! The sophisticated bit is, IMO, clickbait/sensationalized. I see that and it screams malware; the opposite of obfuscated.
I was actually thankful to see that! I review PKGBUILD diffs when updating packages, but I sometimes wonder if I really know what to look for. This is so obvious, I definitely would have caught it.
I found this one before. As @bitshift mentioned, I look over the PKGBUILD diffs, but... I also probably would have caught it. Can't guarantee though.
It's curious as to how many affected packages I have but in some other version. E.g. my
bpytopvsbpytop-qt...I wonder if differences in orphaned status would have influenced which packages got infected? I would assume the "simple" package name would be more likely to be installed, less likely to be orphaned, and thus less likely to be taken over and infected. Whereas specialized versions of the package (
-qt, etc) might have the opposite trend? Just a guess, haven't counted.On the subject of getting good: this article had a few tips on how to review AUR packages, written following a different AUR incident in 2025. Some of it is basic stuff, but I learned/was reminded of at least a couple things.
I wonder if the compromise involved taking over orphaned packages? A lot of the compromised packages look old - there's a lot of python2 packages for instance. And I know for a fact that
neovim-nvim-treesitterwas recently abandoned due to a ahem slight feud.Yes, as far as I understand it any account can adopt a package and push out changes. Until there is some kind of vetting process, timeout, or moderation, this isn't resolved.
Brodie posted a good overview of it here.
See also “Atomic Arch”: Nearly 900 AUR Packages Backdoored with a Developer-Targeting Infostealer and eBPF Rootkit
Perhaps LLMs could be leveraged in some way to protect a user from these compromised packages? Like for example, whenever you install a AUR package, a script pulls up an agent that quickly checks the AUR’s script, and then warns the user if there’s some weird code in there.
Edit: I’m thinking a small local model that can run in most PCs and was trained specifically for this task. Doesn’t need to be smart enough to build its own complex PCKGBUILD scripts, just enough to understand if something makes sense or not being in the script
The moment any system like that is deployed in an official capacity, it will be defeated. They'll find prompt injections, comments with valid-seeming excuses, and just styles of writing that won't raise the alarm of any particular model used.
LLMs aren't good at classification (or much of anything) in adversarial environments. Malware authors have started shoving instructions/requests for biological warfare into their source to trigger refusals in analyzing models.
Good point, didn’t think about that.
Perhaps another way could be to strip the PCKBUILD of all comments and only keep the code that actually does anything - and only send that to the LLM.
Still, I’m sure this could create a cat & mouse situation anyway and the hackers would get more creative with prompt injection.
Yeah, you can easily just throw whatever you like in an
echo "Evil"and bypass that. It's untrusted input and there's no real way around that. It's old at this point, but see Gandalf.I don't use Arch, BTW.
Honestly it feels like AI is basically about to kill open source. Or at least open source that isn't a small, tight niche of trusted people, which in a lot of ways is how it should be.
At a complete guess, maybe we'll see key signing parties and webs of trust become more commonplace? Those wound up being unnecessary in an era where one could trust the integrity of the average contributor, but if the internet is all LLM bots ...
I could honestly see the web of trust gaining some prominence. I believe Bluesky uses something kind of similar to this for its verification system with its “Trusted Verifiers” feature. Key signing parties sound tedious, if I’m being honest.
In all fairness, you only strictly need to attend a key signing once or so to create an initial trust chain (so to speak), after which you rely on the web of trusted individuals to establish identities. Kinda like how we currently trust the CA chain structure, even though you only ever register your cert with a single authority.
That said, the topic of loneliness and lack of community seems to come up a lot around these parts. A key signing party seems like a great ice breaker for assorted nerds to get out and ask personal questions about other, local people with similar shared interests!
Was AI involved in the compromise in some way besides AI API keys being one of the targets being scooped up?
My presumption anymore is that the bad actors used AI unless explicitly stated otherwise. I may be mistaken in this case, but it's hard to imagine the scale of the breach was accomplished entirely by humans working alone. It may just be me assuming that a botnet controlled by AI was brought to bear on this and in fact it was just 10 or 15 people with 100 or so packages to target apiece. Speculation on my part, for sure.
It looks like this exploit wasn't particularly complex, the AUR just lets anyone take over a package without active maintainers. Someone, perhaps with a simple script could have taken over all these inactive packages and automated adding the malware dependency to them.
That seems like less a security hole and more a security open front door with a welcome mat...
That's just about the AUR's slogan. Nearly entirely unmonitored and at-your-own-risk. If AI were involved, in the current climate, it surely would have been mentioned.
AI could be a very effective protection against most supply chain attacks though.