You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. This really has always been the case; we've had discussion about this for well over a decade. People are always asking why there's no official AUR helper like yay - this is why.
A lot of people complain about Arch Linux being elitist, but the simple reality is it's a distro built for people who know what they are doing and don't need or want their hand held at every step of the way. This also means that if you break or compromise your own system by installing random AUR packages, it's your own damn fault.
All of that being said, the era of allowing anyone to adopt AUR packages might be coming to an end. If for no other reason then the effort of rolling back every affected package every time is too high. I'm not sure what the alternative would be, reviewing every adoption request seems like too much effort and wouldn't necessarily even help every time.
But isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package, etc? (Unless you are running them somewhere without internet access or without access to anything you don’t mind being public?)
Maybe it’s not the case for aur, but the others could theoretically be improved with better permissions, sandboxing, etc. I guess browser extensions basically have those options, even if no “normal” users use them.
Unfortunately 99.99% of people can’t or don’t have the time to review everything. :-(
I guess distro packages where there are trusted maintainers, or places like the iOS App Store where there are both permissions and somewhat of a review process, are the safest.
Yes, and all of those have supply chain hacks in them, and have happened within the last year? In this specific case, it's a malicious npm package being installed with official npm tooling in the PKGBUILD.
The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing, they are very simple bash scripts. It'd be great if more people would donate resources to help verify and validate AUR scripts, but the AUR specifically exists for packages that the trusted users and devs of arch don't have time to personally maintain.
Ultimately, the way we're doing permissions on the OS level is fundamentally broken on desktop OSes, and we're increasingly feeling the effects of that. Ideally everything should be sandboxed by default, and only given access to it's own files, instead of everything the user has.
But we're a long way away from that, and that's not something a single project could enforce.
It's also a good thing that Arch Linux has people hawking it, so if these things happen they get caught on insanely quickly. I wonder if there's sane ways to protect your dotfiles from rogue processes just touching them.
I don't really think this is a solution- the usual workflow for these attacks has been to hide your payload in some dependency. This one is somewhat unusual in that it's just a very lazy `npm install` in the pkgbuild. Pretty much every package repository even outside of AUR has this issue now, and it's not really viable to audit the entire dep chain by hand. Mind you, I don't have a solution either.
This is different though. The attackers of the AUR don't have access to do anything to upstream and any malicious dependency they add would have to be either 1) already built as an official package or 2) also taken from the AUR... in which case the person building it would need to audit the dependency as well.
So you have two "AUR hygiene" principals at play: One, know what software you're even installing, and Two, know that the PKGBUILD does what it says on the tin. If you neglect either of these and YOLO then it's kind of on you.
Arch users should really know that the AUR is something to approach with a massive amount of caution. It's better than "curl bash" from some rando web site, but that's only due to the fact that you can easily audit and diff the payload of the install recipe yourself.
Having code reviewed the PKGBUILD doesn't mean the upstream software is safe to use, having reviewed the upstream software and it's dependency tree doesn't mean the PKGBUILD is safe to use.
When you `makepkg -s`, makepkg will get the dependencies it can from the vetted and maintained pacman repos. Only the dependencies that are not present there would have to be obtained from the AUR the same way as the package you're currently reviewing: git clone, manually review, makepkg, etc.
Having dependencies in the AUR is not that common in my experience. I think I've had rarely 1 or 2 deps in the AUR; maybe once or twice I had like 6 deps. It can happen, and it's a bit of a chore, but it can be done.
Believing that even a small fraction of users actually do this is deeply detached from reality.
It is not that hard with small amount of pkgbuilds:
find ~/.cache/yay -maxdepth 1 -type d
/home/virt/.cache/yay
/home/virt/.cache/yay/google-chrome
/home/virt/.cache/yay/ngrok
/home/virt/.cache/yay/rancher-k3d-bin
/home/virt/.cache/yay/simplescreenrecorder
/home/virt/.cache/yay/ttf-comfortaa
/home/virt/.cache/yay/cursor-bin
/home/virt/.cache/yay/yay
/home/virt/.cache/yay/volta-binThe point is that the onus is on you to do it, and if you don't then the consequences are yours to bear. Personal responsibility seems to be in short supply these days.
AUR isn't just some download site. It has been actively marketed by Arch for at least the 17 years I've used Arch as it's user repository. (that's kinda the acronym)
That creates the expectation, rightly or not, that the Arch User Repository provides some degree of protections for Arch Users against the build sources hosted there being compromised.
The AUR is a great resource for Arch and the wider Arch community and it was put together by some really talented folks at a time when the threat environment was completely different. Times have changed, and it's a sad testament for humanity.
AUR will get through this, and be better for the additional guardrails to be put in place, but blaming the victim and CYA never gets you there.
Is that much different from the entire pypi ecosystem, and npm, and dockerhub (people disable Selinux, --privileged turns off seccomp and apparmour, sandbox escape CVES exist)?
The entire dev ecosystem has terrible security hygiene, largely because of the pressure to move fast and real security controls by their nature limit flexibility and can slow most processes down.
The difference is that Arch got a trusted reputation throughout the years, while in AUR even the packages that also have a reputation can suddenly change their owner - which produced the current issue.
That's basically what the AUR is.
Should have never been a thing.
I hope we end up with something more like username/packagename-bin|git
That'll make it way more obvious to people what they're really installing and from who.
While that may be true, is the AUR not moderated or operated by arch devs? On Gentoo, I can't just push "npm install malware" to 400 packages in guru without someone else's approval.
> You have to review the source of every PKGBUILD from the AUR you install, full stop.
With a semi official repo, I would expect the people with push access to not upload malicious packages... while its still possible, and things do happen, completely pointing the finger at arch users for simply using arch isn't very helpful.
Expecting users to manually review every single change, for every single AUR package they are using, every single time they do an update or installation is just unreasonable if you want to AUR to be useful at all for the general user.
How many AUR packages are you assuming people are installing?
That is the burden of arch linux, and the beauty. you have to go through it and you have to learn.
Now just hoping that people are reading (and learning from) the arch wiki going forward, not just agents. sigh.
hmm... I guess people insulate themselves after a while with stuff like yay
My favorite Aur helper (pikaur) also asked you to check the PKGBUILD on every install or update, back when I used Arch.
As far as Arch goes, I wonder if Arch-based CachyOS is a factor as it's seen the high performance desktop linux.
Even the most primitive LLM review workflow would have caught this compromise.
Adding or modifying any invocation to a PKGBUILD that may download something from the network and execute it (whether using npm, pip, curll|bash, or whatever else) -> automatically quarantine the PR and flag for 2 human reviews required. Same for anything that looks like obfuscation. Same for anything that adds dependencies on the wrong language ecosystem (like new use of javascript ecosystem tools in a c++ based package).
I have no idea why they don't do this already.
Maybe doing automated LLM reviews would help, but this is a large infrastructure investment. And it's not clear that it helps at all, after all models are quite vulnerable to prompt-injection type attacks.
On balance, the false sense of security that the automated check would provide might actually be detrimental.
Eg. change AUR API URL slightly so yay/yaourt users need to look up what is going on. New API should have infrastructure for informing users and making sure they've read the message before proceeding. Especially when they're not even sure that all malware was found.
Also there should be database of revoked/compromised AUR commits and there should be mechanism to warn user if they had it installed.
It's right there in the name, and it's clearly announced in all the wiki materials that AUR is user repos, and trust shouldn't be given blindly.
It's literally in a giant red box right up front: https://wiki.archlinux.org/title/Arch_User_Repository
There are lots of things on AUR that I absolutely won't install, and I don't really think spamming the mailing list with all of them is the best policy.
And while I don't exactly hate the idea of warning users who installed a malicious package... it turns out that's not a particularly feasible thing to implement, because AUR doesn't have the kind of install tracking that's present in the commercial tools... ex - how exactly are they supposed to know who installed a package? AUR is basically just a phonebook of package locations, and they don't require any login/auth info.
So the warning comes from tooling the user can run if they're paying attention, and they ask you to pay attention (ex - https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...)
> New API should have infrastructure for informing users and making sure they've read the message before proceeding.
How would that even work? AUR packages are just git repos, everything that AUR helpers are doing or not doing is not under the control of the arch maintainers.
Are you seriously asking how would sharing short text notes over internet work?
If you need to be 100% git-centric, you can have git repo for messages. Client will then remember last commit displayed to user and refuse to continue unless latest message was displayed.
BTW some AUR clients displayed ArchLinux RSS feed before... Too sad the issue is not even mentioned in the RSS feed...
If a package is compromised, I think most people would prefer their workflow be broken than risk installing that package.
If you don't want to list all known effected packages, at least recommend the official position that anyone using a AUR package should be reading every file of every package they use.
Other than this — I don't know how many there are affected people in total, but AUR team probably has an exact number. I am also sure, they're doing their best to handle it accordingly to the impact.
I know its all volunteer work and extremely not fun at the moment, but it feels weird to not even have some sticky-no-reply on the AUR sub forum with a list of compromised packages. You have to instead try and scrape them up from around threads like here or reddit.
https://cscs.pastes.sh/aurvulntest20260611.sh
Not my script. It's easy to read/parse. Never pipe a script directly to bash.
comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/3f768dce7331618310f016d975bf8547/raw/beef579f8a8efeed6ccf60788e5b768775550095/packages | sort)
It seems like the AUR should change the orphan recovery process, and helpers should probably offer a minimum package age feature like pnpm.
Goddamit, don't make me reinstall Arch, took me a week last time.
Update: archinstall rocks, back in business after like 15min.
Always check PKGBUILD and sources, AUR is not to be trusted for the most part. I'm actually more surprised that such compromise hasn't happened earlier.
it happens all the time
Just not always on this scale and doesn't always end up on HN.
Similar to how you don't see every npm supply chain attack or malicious github action or similar on HN.
In general you _have to_ manually review every PKGBUILD update by hand (by diff). Everything else is neglect IMHO. Luckily for most packages this is reasonably doable, IFF you trust the upstream sources they fetch from. (As in: Most packages are a small amount of glue between pacman and a upstream source.)
As consequence AUR packages with AUR dependencies are in general "uh..., lets not do it" cases for me, as on one hand the review overhead can be a pain and on the other hand it's easy to make a mistake overlooking a change in AUR dependencies.
Still the policy which allows relatively easy adoption of orphaned packages is IMHO a problem. A adoption should be treated as a new package which just happen to have the same name. (It can be fine to not have that if arch maintainers "bless" the adoption, but IMHO that would only matter for a view very widely used packages which are candidates to be included in the official repo but aren't for e.g. license reasons.)
This is like the 3rd or 4th time. It's been ongoing and persistent for the last 2 years with frequent AUR downtime as a result.
The AUR should be deprecated in its current state, simply can't be trusted and is a blemish on an otherwise great distro.
After correcting, for me, it flagged "jd-gui", but I had actually installed "jd-gui-bin" about two hours before the compromise. As far as I can tell, I was lucky that I felt lazy that night and went for the -bin package instead of waiting for the source to be compiled.
This is a bit of an odd response. Arch very explicitly separates the AUR from everything else and doesn't make it easy to work with, because its security model has always been fundamentally broken and requires you to do your own vetting. It exists to facilitate sharing of package recipes between untrusted users. You should treat it like a pastebin.
I disagree that "These packages are provided as-is. No work has been done to determine their safety or fitness for purpose. Use at your own risk!" is a "fundamentally broken" security model. It's one that places the burden of verification and validation on the system administrator and -in the case of the AUR- fully informs them of this fact. Treating system operators like the adults that they are isn't "fundamentally broken", but it is _much_ more work for that operator than if they relied exclusively on distro-vetted packages.
I do agree that it'd be fucking silly of OP to switch away from Arch because some of the packages in the collection of packages that are explicitly provided as "as-is and unvetted" got some malware in them.
PKGBUILDs are easily readable/reviewable and rarely go beyond a single page. Just take a moment and be responsible and review before running executable files you download from the net. Common sense stuff. That's always been the trade-off and it hasn't really changed much in last 20 years (even though every few years everyone seems to freak out over it).
I have 1,135 packages installed. Only 3 top level packages are from the AUR and 2 of those 3 are from the same author, they just happened to split their packages into a client / server architecture.
[0] ...which is -IIRC- Gentoo's term for a user-provided and entirely-unvetted collection of packages...
You can check the build and install date with `pacman -Qi <package>`.
I run Arch Linux in a container (within Fedora Silverblue), but my plan for the future:
- consider switching away from Arch Linux for my dev container, with great sadness. A rolling distro is a terrible idea in the current security climate. I loved using Arch for my dev container exactly because of AUR.
- switch to Fedora Stable, perhaps the previous release which still gets security fixes but no other updates. I am still on Fedora 43, I guess I have no rush to update to 44. - be even lazier in updating my workstation. I used to update daily when I was running Arch, then I moved to weekly last year when I got stuck with slow internet, now consider updating monthly or more (of course, unless there are critical security bugs)
- Flatpak and Flathub terrify me, it's only a matter of time until malware appears. I have had automatic upgrades disabled for a while.
- for the love of God don't touch anything that uses npm
Previously: https://news.ycombinator.com/item?id=48458931
I thought Flathub has a review and approval process. Does it fall short in some fundamental way?
Any review process is more than the AUR and NPM are doing.
If your manifest is covertly injecting malware into the build it could be easily missed. Consider some of the manifests are simply downloading deb packages and unzipping them.
>The result is a rather long list of ~408 packages all doing npm install atomic-lockfile something something
[0] https://lists.archlinux.org/archives/list/aur-general@lists....
https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...
Inconvenient, but perhaps instead of allowing adoption of someone else's abandoned package, the AUR forces a new submission instead and regularly purges orphaned packages older than a certain age?
If you want to change it, fork it!
I think we are well past (1) but (2) could be mitigated by tighter controls on AUR accounts and potentially additional safeguards from AUR helpers. Maybe show a big scary warning if the package has changed owners recently. I know there will still be people that will "y" their way forward but it's better than nothing.
Or just avoid AUR helpers altogether and inspect/build the packages you need yourself from their PKGBUILDs directly.
The AUR helpers actually make it easier to integrate the review step into your workflow IMO; they actively prompt to review and let you know when a change is present since you last accepted the risk.
But "AUR considered harmful" is not a novel take. Everybody using it should understand the risk here, it's really just one step removed from curl/bash'ing something you found on StackOverflow.
Right now, this is the most up to date, consolidated utility to check for infection:
https://github.com/lenucksi/aur-malware-check
Also, the aur-request mailing lists has many delete/orhan requests coming through to undo the malicous commits:
https://lists.archlinux.org/archives/list/aur-requests@lists...
There's a lot of voodoo in that script, i can't easily tell it's safe by reading the code.
I'd expect some reaction/solution from official Arch developers...
All of the packages I have triaged involved the atomic-lockfile npm package, so this is something you could try:
npm cache ls | grep atomic-lockfile
Really conveys that sense of urgency + the stakes tied to a major malware attack like that.
It is an officially maintained package and I always assumed these were built on a dedicated build server instead of some a random volunteer/home computer. Don't know if Arch still builds the same way but this event scared me enough to switch distros.
There's warnings in place if a .so dependency is detected, but it's up to the maintainer to notice and act on it.
For safety/security concerns, Arch Linux has been one of the driving forces in the reproducible builds project, and for large parts of the operating system it's possible to independently verify that those binaries have in fact been built from source code. It's auditing story for official packages is stronger than that of NixOS (and on par with Debian):
https://reproducible.archlinux.org/
All of this is entirely unrelated to the AUR incident however.
I'd really prefer to see a model where a 'community' repository contains user submitted packages which have at least one Trusted User review the package before it's merged in. This doesn't just prevent malware, but also common mistakes in general.
A large number of "an Arch Linux update broke my system" is very likely due to incorrect AUR use that AUR helpers don't handle for you. There's an elaborate writeup here from just 2 months ago: https://lists.archlinux.org/archives/list/arch-dev-public@li...
AFAIK I'm pretty likely owned if all of this is true:
- The following line shows at least one affected package:
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."; }
If I did not update AUR, in the last 2 days, it should be ok (at least for this specific problem).
If I don't see affected packages from the line above, it is probably ok, but maybe there are malicious packages that are not listed and yet I'm still be owned, so I have to be careful.
Is that correct and if not, what did I get wrong? And are there any checks that I can perform, that proof the status of the system?
The headline got my heart going pretty good this morning.
It was never perfect from a security PoV, but in 2026 this kind of trust model feels increasingly scary.
Yup. Every time, I guess it's one of the most common attack vectors, can we do anything to secure NPM more against these supply chain attacks? I swear NPM is always involved in all sizable attack vectors these days.
It's honestly more trouble than it's worth to get your package deleted, instead leaving orphaning as the more optimal way to relinquish control. This should be the opposite in my opinion, or at the very least the users should be made very aware that an orphaning has occurred. Perhaps that burden is more on the AUR helper like paru and yay (who I would encourage to make such a change).
https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
I toyed with the idea that someone should write a binary that simply emails, or alert you when it's been run... as a canary... and call that `npm`.
At this point, not renaming the npm binary is a big risk.
https://news.ycombinator.com/item?id=17501379 https://news.ycombinator.com/item?id=44607740
Internet archive URL: https://web.archive.org/web/20260611213640/https://aur.archl...
- I run arch on the host. The host runs qemu.
- Qemu VM 1 runs my work machine.
- Qemu VM 2 runs my financial stuff.
It took me about 2 days of work to figure out how to virtualized my machine and maybe months of tinkering after that to get it right.
I'm trying to separate general work use and payments to entirely separate security models.
I've also begun moving all dev work to cheap vps's that I run online with AI agents.
https://hn.algolia.com/?dateRange=last24h&page=0&prefix=fals...
I'm thinking more and more that things like sandboxing and compartmentalization are becoming increasingly important on everyday desktop machines. The design of every process having at least read access to almost everything on a machine by default is not appropriate anymore.
It's essentially uncensored platform. I think they can moderate it, but obviously only for high-visibility cases.
Anyone can create package with any name, potentially impersonating any other project.
And that's all on archlinux.org domain, which inherently adds some trust to the whole concept. Trust that is unfounded.
If someone wants to distribute PKGBUILD, they should put it to Github or any other git hosting.
This is good. I'm adapting, as we should.
Headed back to functional/repl languages myself. Might even drop zig.
That their layers should heal cleanly, bereft of info to steal.
So they can yay again with even more zeal, mainly.
No stress! Yes?