alt.hn

6/19/2026 at 4:59:16 PM

AURpocalypse now: a look at the recent AUR attacks

 https://lwn.net/SubscriberLink/1077619/f7b07c5489fdd43a/

by jwilk

6/20/2026 at 7:46:18 AM

The AUR really has been known to be low-hanging fruit for bad actors, which makes it somewhat surprising it took this long for it to be taken advantage of.

I have many opinions regarding this situation, but it mostly doesn't matter. AUR staff and AUR helper developers will figure out what they want to do, hopefully they will find a good approach.

But what I personally take away from this is simply that it has become worth it to target desktop Linux with malware. Or at least, moreso than previously. It is perhaps a good sign in some ways that the desktop is starting to be taken more seriously.

The bad news, of course, is that the Linux desktop is a bit of a train wreck in terms of security hygeine. It's getting better, and Linux does have the advantage of having some powerful primitives to exploit, but the desktop suites come from a totally different world, and I fully expect we'll also see more malware propagated through KDE's New Stuff integration (which goes through Pling.)

by jchw

6/20/2026 at 12:41:42 AM

In case anyone missed it, the latest version of yay (v13+) supports being able to skip recently added packages through its new Lua extension system https://jguer.github.io/yay/lua.html#upgrade-selection-hooks. You can control the threshold since it's just user configuration now.

A bunch of common yay commands also return back the last updated time of a package thanks to https://github.com/Jguer/yay/pull/2846.

by nickjj

6/20/2026 at 6:43:22 AM

The thing is that hook is not enough: `UpgradeSelect` only applies to `yay -Syu` so it only filters the upgrade list.

Nothing protect you from a `yay -S foo` install and its dependencies. So this is not a guarantee or enforcement of a minimum release-age.

Actually writing this reply I went ahead and pointed that out in an issue at: https://github.com/Jguer/yay/issues/2883

by kdeldycke

6/20/2026 at 6:27:07 AM

Hope Omarchy will make that a default:)

by dSebastien

6/20/2026 at 1:57:13 AM

Devil's advocate, except partially serious.

This is a good thing, because the warning about checking everything you download from the AUR, which has always existed, is now actually "enforced". People respond to consequences.

by Ferret7446

6/20/2026 at 2:32:30 AM

I love the smell of npm install malware in the morning.

by cozzyd

6/19/2026 at 11:48:19 PM

I'll note that OpenSuse also has Packman which a shitton of people enable (for codecs), has also 'one namespace only' an looser policies than the main distro.

I do not think this something you can escape by switching distro.

by AshamedCaptain

6/20/2026 at 7:49:22 AM

Zypper at least has a notion of "vendor", so you can arrange things so that only the handful of packages you care about will actually come from Packman.

Ubuntu actually has first-party repositories with proprietary codecs.

Nixpkgs is a pretty comprehensive monorepo of packages with a more normal review process than the AUR, and it includes non-free software as well, plus the model with flakes for third-party stuff is that you trust individual publishers for their little repos rather than one giant grab bag repo of unreviewed content like the AUR.

RPMFusion for Fedora kinda has a similar profile, in that it's a shared repo for various things unsuitable for the main one, but it follows more or less normal Fedora packaging and review standards, doesn't it?

Supply chain attacks are possible everywhere and some distros have particular weaknesses, but the AUR really is pretty much uniquely bad here.

by isityettime

6/20/2026 at 9:12:10 AM

Nix also forces builds to be sandboxed. Now you actually need to run an infected build output to be affected.

by eptcyka

6/20/2026 at 5:13:46 AM

I use Gentoo. You have to specifically install "overlays" and every package maintainer would make their own overlay. You can't easily take over an overlay without the original person's permission.

That being said, still one namespace. Once you add an overlay it can replace any package it wants.

It's also Gentoo so too hard for most people to figure out.

by jjmarr

6/20/2026 at 12:14:23 AM

Yes, the only reason this isn't happening in other distros is simply popularity.

Namespacing is the solution, and as mentioned in the article some ditros do indeed have namespaced user repos, like Fedora's Copr. The trust model of a flat namespace user repo is completely broken when the maintaining user can change at any moment.

by cqz

6/20/2026 at 1:48:42 AM

Isn't Arch's AUR flat namespace quite unique? Ubuntu's PPAs are also not flat.

by PalmPilotProMax

6/20/2026 at 8:08:37 AM

openSUSE's OBS and Gentoo's overlays aren't a single shared repo either.

by isityettime

6/20/2026 at 2:09:35 AM

Packman is more akin to rpmfusion, than AUR. OBS is the AUR equivalent for OpenSUSE.

by badreligion42

6/20/2026 at 7:57:38 AM

"One namespace" is also technically true but doesn't work the same way with dnf or zypper as it does with pacman. dnf and zypper both make it easy to be explicit about the priorities of your repos and also to track which packages come from which repos and prevent that from changing. Plus openSUSE has a generously free public instance of the Open Build Service that you can easily use to host your own repos, and which hosts many individual repos you can add for specific purposes. When I ran openSUSE I always just ran my own repo there with only the extra packages I actually wanted, often just "forking" packages from repos hosted by well-known openSUSE developers so that I didn't have to manage updating the source packages myself but still didn't pull in the whole world from those repos and also didn't implicitly trust anything as loose as the AUR.

OBS is more like Ubuntu's Launchpad or Fedora's CO0R than the AUR. Random strangers can't take over the packages of others just because they go idle, and it's a bunch of separate repos, not one. Totally different trust model.

by isityettime

6/20/2026 at 7:58:33 AM

Well all of those attacks are just supply chain attacks, and it is basically exploiting people's trust. With LLMs, the speed and velocity of pumping out malice raised are now significantly faster.

It is so sad that every goodwill eventually got enshittified as well.

by stevefan1999

6/20/2026 at 1:26:31 AM

Despite that official Arch repos weren't affected in this attack, I would not recommend using Arch (or any rolling release distro) for anything that requires security. (Imagine if the xz backdoor targeted Arch...)

An Arch maintainer that I personally know once admitted that he rarely review upstream changes when bumping package versions. He only does that when the build breaks.

I can't blame him for what he did, since it's not reasonable to ask package maintainers to spend all their time on those stuff, especially in this "Age of AI" where more and more software are being aggressively refactored (or rather rewritten) and added more features.

What we can do is choosing a stable distro (like Debian) where packages are more thoroughly reviewed, and apply security practices (such as TOTP, sandboxing browsers and video players, etc.) even though they cause inconvenience.

by AquaWeasel

6/20/2026 at 8:41:59 AM

Alarming. The whole point of official repositories is they're trusted, since they are maintained by trusted people. If one can't trust maintainers to be responsible, then the official repositories are no different than the AUR.

by matheusmoreira

6/20/2026 at 1:54:10 AM

I don't think Arch maintainers are responsible for auditing upstream. They package the upstream only.

by Ferret7446

6/20/2026 at 1:34:11 AM

> An Arch maintainer that I personally know once admitted that he rarely review upstream changes when bumping package versions.

Cool story bro. Assuming that's common, I have trouble understanding why Arch (non-AUR) is any more at risk than Debian--besides the latter being more popular and having more users/incidental testers, which is a real benefit if that's your goal, but has its own drawbacks (like older and known-vulnerable packages lingering for longer before updated releases are made available).

> it's not reasonable to ask package maintainers to spend all their time on those stuff, especially in this "Age of AI"

Aren't Debian and friends similarly at risk of this as well, then?

> security practices (such as TOTP, sandboxing browsers and video players, etc.)

I'm not sure if those are more or less prevalent on Arch; I know that many IDEs and GUI programs I've installed on Arch ran by default in Flatpaks or similar, and Debian/Ubuntu like Snaps, but I'm honestly not familiar with whether those ecosystems have significant and/or equivalent penetration in different distros.

by zbentley

6/20/2026 at 2:45:15 AM

Debian freezes the package versions on release of each Debian version and then cherry picks critical fixes for the rest of the Debian version's lifecycle. So even if they never review the code (and I don't expect them to), they're less likely to release malware before it's discovered by others.

by skjfjnflw

6/20/2026 at 3:16:35 AM

That model is getting increasingly difficult and labor intensive, unfortunately. More and more upstream are abandoning the old school security advisories. Not many are isolating CVEs or security fixes into distinct patches, the fixes come with a version bump and often accompany new features or other bug fixes.

There's also plenty projects that silently fix security bugs without issuing a CVE or even labelling them. So now the maintainer of that packages has to monitor the commit logs, figure out if a particular bug fix has security implications and then backport it to the older version which is becoming harder and harder over time.

Unless you have a massive team or a big enough army of volunteers, the LTS model is becoming less and less viable over time, you are often safer on rolling release or close to it (something like Fedora's pace is good).

by thewebguyd

6/20/2026 at 5:27:26 AM

I like the Alpine model where they have a set of packages they maintain via the core team and everything else is in "testing".

by skydhash

6/20/2026 at 3:29:48 AM

You get a lower risk of them pulling in a bleeding edge vulnerability, but a higher risk that you'll get stuck with an old bug waiting for the maintainer to pull in a patch. Then there's the risk that in their attempt to cherry pick, they don't actually mitigate the issue (or introduce more issues based on how they diverge from upstream).

There's no silver bullets here.

by akerl_

6/20/2026 at 6:09:03 AM

> There's no silver bullets here.

Because it's a trade-off, just like stability is, they're both software bugs in the end so mitigating them has similar pros and cons.

by armada651

6/20/2026 at 5:29:27 AM

> but a higher risk that you'll get stuck with an old bug waiting for the maintainer to pull in a patch. Then there's the risk that in their attempt to cherry pick, they don't actually mitigate the issue

Which is why the whole process is open sourced and you can get easily the source version of a package, edit it and rebuild it.

by skydhash

6/20/2026 at 3:13:54 AM

> where packages are more thoroughly reviewed

Where are you drawing your conviction that non-rolling-release distro maintainers are doing a more thorough review of upstream changes?

> such as TOTP

What?

by akerl_

6/19/2026 at 11:41:08 PM

Who still uses Arch btw after this?

by rvz

6/20/2026 at 12:14:33 AM

The AUR has consistently had warnings around it of 'verify the PKGBUILD', far more so than any other package repository that allows anyone to sign up. Probably the only notable difference is the ease of taking over an orphaned package.

by rcxdude

6/20/2026 at 1:11:22 AM

The AUR is not the Arch package manager or repository. The main Arch package repos are managed similarly to Debian, or Fedora, or whatever--caveat Arch's nature as a rolling release, but in terms of vetting and ownership/security, the approaches are similar. pacman installs from regular, real, vetted repositories by default. pacman will never install from the AUR. pacman is the official Arch package manager and the only one that is provided with the main Arch distribution/install instructions.

The AUR is, as many others have pointed out, a deliberately un-vetted pile of random Git repos. Arch deliberately doesn't even ship with a default one-click installer for AUR packages; their published guidance is "git clone this stuff from wherever it's hosted and build it at your own risk". Plenty of third-party, non-Arch-blessed tools turn that into a one-click process, but it's not "part" of Arch itself--at least not any more than, like, curl | bash or directions on how to add rando websites to /etc/apt/sources.list.d is part of Debian and friends.

I've used Arch as a daily driver for years. At peak, I've had five (5) total packages, with no transitives, installed from the AUR. Today I have one: sublime-text-4. It's perfectly possible--and extremely reasonable for many users, even power users--to live in an AUR-less world, or to use so few AUR packages that the guidance of "read what you're installing, doofus" is manageable and not onerous.

by zbentley

6/19/2026 at 11:53:21 PM

If you want something from the AUR, just don't be lazy, read the pkgbuild.

by anagram666

6/20/2026 at 1:32:05 AM

I was not affected

by QuaternionsBhop

6/20/2026 at 2:08:50 AM

I do. I just keep reading the diffs on the PLGBUILDs.

by beej71

6/19/2026 at 11:55:54 PM

I do, I'm just choosy about aur packages I use

by segfalt_

6/19/2026 at 11:44:53 PM

I still do, I just don't touch AURs anymore.

by giancarlostoro

6/19/2026 at 11:43:51 PM

Is there another distro that has an equivalent of the AUR with handling you think is preferable?

by akerl_

6/20/2026 at 12:01:44 AM

AUR is fast and loose and doesn't do much "handling" by design, so it's hard to find any equivalent repo. But there's always a tradeoff between fresh (nixpkgs unstable, might be the closest) and tested (Debian).

by orbital-decay

6/20/2026 at 12:09:27 AM

AUR isn't just the testing repo of Arch; it's explicitly just an open spot where anybody can put up "here's a PKGBUILD for folks". I don't see how it's like either the Nix or Debian examples.

by akerl_

6/20/2026 at 12:21:34 AM

Well, Nix has NUR which is a direct equivalent but it's not nearly as broadly used and I assume "here's a PKGBUILD for folks" is already too permissive for you if you're asking.

There's no maintainer vetting process in nixpkgs as far as I know, anyone can own a bunch of packages. There are quality standards and it's not "here's a bunch of nix code for folks" but it's the next possible thing in the line after that.

by orbital-decay

6/20/2026 at 8:06:50 AM

The NUR was sort of convenient before flakes were a thing, but now that there's a really common convention for sharing Nix code few use it. I bet most people who came across Nix in the last 4 years have never even heard of it.

by isityettime

6/20/2026 at 12:27:21 AM

It seems like you may have mistakenly inferred that I have issues with the AUR?

I don't; I use Arch on 100% of my personal servers, have done so for something approaching 20 years, and don't see myself changing.

But I treat the AUR for what it is: a place where anybody can say "here's a PKGBUILD for folks" and it's on me to evaluate it on its merits.

I was legitimately asking the person upthread what other distro they felt had a better model for this kind of sharing, because they seemed to think this was a reason for Arch users to jump ship and I was curious what they thought would be the elements of a better system.

by akerl_

6/20/2026 at 12:05:15 AM

Gentoo

But let's hope we get this solved, like peer review model, vouch, or something

It is very good to be able to find build/install files for everything

by guilhas

6/20/2026 at 12:12:32 AM

Gentoo's model appears to be basically the same? Like the AUR, anybody can submit basically anything they want. The requirements amount to containing valid packages, having a bugzilla account, and putting your package definitions in VCS somewhere.

by akerl_

6/20/2026 at 8:50:18 AM

In overlays that need to be explicitly enabled. Not as convenient as yay yolo.

We can also add npm to package.mask.

by butterknife

6/20/2026 at 1:23:26 AM

SlackBuilds.org is pretty sensible.

by dokyun

6/20/2026 at 2:54:44 AM

A side note, isn't package maintenance something that can actually be solved to some extent by LLMs? The prompt would be something like "Clone this repo and build this package while building/bundling as few other packages as possible with minimal code changes."

Then set it in a loop on all the packages for a particular system, I don't have experience in package maintenance and would be curious what kind of issues would come up.

by MintPaw

6/20/2026 at 8:11:59 AM

Packaging for Linux distros is about review, following standards and conventions, authority, and responsibility. (And maybe also sometimes patching for compatibility.) LLMs can sometimes help with some of the mechanical parts, but the curation and trust stuff not so much.

by isityettime

6/20/2026 at 7:47:26 AM

> New user registration was stopped on June 11 and then re-enabled after the project added Anubis to try to foil the attacker's mass account registrations. That did not work

This confuses me - why would a proof-of-work anti-scraping system like Anubis prevent registrations?

by orf

6/20/2026 at 8:35:04 AM

Implementing a bot to do registration is not a "copy as curl " click away anymore, and creating millions of accounts maybe become computationally expensive.

This is not much, but it could deter some low effort adversaries.

by lemagedurage

6/20/2026 at 8:43:35 AM

I see that, but the adversary wasn’t a low effort one, and didn’t need millions of accounts.

by orf