- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
Arch Linux’s AUR is experiencing a malware incident involving user-contributed packages with malicious commits that attempt to download npm-based payloads during installation. (…)
Arch users should not update AUR packages without review. Examine PKGBUILD diffs, check any new .install files, and be cautious if updates introduce npm commands or dependencies unrelated to the software.
Users who recently updated affected AUR packages should review package history, examine executed suspicious install scripts, and treat any unexpected npm-based installation behavior as a possible compromise.



Why npm and not python? It’s installed on every arch system and wouldn’t bring unnecessary attention 🤷
Because the NPM is a complete mess and it’s super easy to exploit for supply-chain attacks by sneaking malware into one of the billion dependencies required by most popular packages.
But if you look at some of the packages, they explicitly added
npmas a new dependency. It’d be much easier to sneak in a python script.AUR “packages” are just a recipe file that runs some commands that sources packages from somewhere else and builds them then puts them in the format required by the AUR package manager.
Normally it’s a source tarball downloaded directly from the project’s Git repo. But it can also fetch and install a binary package (for closed source software). Or it can install Node modules, or Python modules etc.
Point is, you can’t inject a script directly in AUR itself. You could add the malicious code directly to the recipe file but it would be obvious. You could also download a zip with the malware directly, but it would also be obvious.
So what they do is add the malware to modules published on another platform, and they’re downloaded indirectly, as a dependency of the Nth grade.
It’s very hard to detect, you can’t really notice this kind of attack with a glance at the recipe.
I see. Thanks for the explanation.
But why would they care about supply chain attacks if they already have hacked into the package you’re requesting? In that case, executing python scripts would be less noticeable
Here’s the AUR recipe (PKGBUILD file) for a random package:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nautilus-git
This is a standard format for the recipe. It’s Bash code used to define variables and functions.
You’ll notice there’s no place to sneak in a Python script. There is some brief Bash code in the functions but any major stuff would stand out immediately. So would an command that fetches a malware zip from a weird URL.
Meanwhile, if you add
nodeorpythonto the dependencies, and then run a command that installs a perfectly legit npm or pip module, nobody would bat an eye. It’s impossible to figure out that among the many upstream dependencies of that module there might be one that was subverted to discreetly run malware.AUR is a very bad idea tbh and should not be used by the faint of heart. It makes it entirely too easy to pull this kind of crap.
AUR itself is fine, the issue in this case is more with the automated system allowing anyone to take over orphaned/abandoned packages. This is a targeted attack leveraging that system.
AUR is a great idea, misusing it is a bad idea.
this is like the 4th npm vulnerability in months, they used that because npm is shit and easy to exploit
deleted by creator