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
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.
It was never perfect from a security PoV, but in 2026 this kind of trust model feels increasingly scary.
>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....
And yes, this is an AUR issue, but npm being used to host and dissiminate malware is also [a chronic] one, even if separate.
Internet archive URL: https://web.archive.org/web/20260611213640/https://aur.archl...
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.
https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...
UI_at_80x24•1h ago
https://cscs.pastes.sh/aurvulntest20260611.sh
Not my script. It's easy to read/parse. Never pipe a script directly to bash.
sva_•1h ago
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.
matheusmoreira•1h ago
datakan•9m ago
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.
sph•1h ago