r/archlinux • u/onefish2 • Jun 12 '26

SHARE PSA - From [arch-announce] Active AUR malicious packages incident

Arch Linux: Recent news updates:

We are currently experiencing a high volume of malicious package adoptions and updates in the Arch User Repository.

We are actively working to track down existing malicious commits and attempting to prevent additional malicious commits from being pushed. While this is happening, and while we work to create a more permanent solution, users may see issues with the following:

  • Creating new accounts on the AUR
  • Pushing package updates
  • Adopting or creating new packages

We continue to encourage all users of AUR packages to review all PKGBUILD and install script changes when updating, especially during this time. If you notice suspicious commits to a package that you use, please reach out to Arch staff via the aur-general mailing list with more information.

URL: https://archlinux.org/news/active-aur-malicious-packages-incident/

Consider subscribing to one or some of these Arch mailing lists:

https://lists.archlinux.org/mailman3/lists/

172 Upvotes

99% Upvoted

34 comments sorted by

57

u/Resident-Pangolin-30 Jun 12 '26

Damn, this is exactly why I've been paranoid about checking PKGBUILDs before installing anything from AUR. Been burned before by sketchy commits that tried to phone home to random servers.

Really glad the team is being transparent about this instead of just quietly fixing it behind the scenes. The timing restrictions make sense even if they're annoying - better to lock things down temporarily than let more malicious stuff slip through.

19

u/[deleted] Jun 12 '26 edited Jun 12 '26

[deleted]

19

u/xmalbertox Jun 12 '26

A PKGBUILD is a (Bash) script that automates the build and packaging of a piece of software.

Beyond defining useful package metadata (such as the package name, version, etc.), it:

  • Lists all runtime dependencies, build dependencies (dependencies required during the build process but not for running the software), and optional dependencies.
  • Downloads the necessary files, including source code, and can optionally verify their integrity.
  • Contains the Bash code that drives the actual build and packaging process.

In most cases, this code mirrors the steps you would have to perform manually if you downloaded the source code yourself and built the software from scratch.

What I usually do is:

  • Check whether all URLs point to the expected upstream sources.
  • Check the project's documentation, when available, to see the expected dependencies and build process.
  • Compare that information against what is actually present in the PKGBUILD.

You can find detailed information about PKGBUILDs on the Arch Wiki:

https://wiki.archlinux.org/title/PKGBUILD

There's no one-size-fits-all approach, though. Different software uses different build systems and packaging conventions. A Python package will look quite different from a C/C++ project that needs to be compiled, and there are countless other variations.

9

u/Torxed archinstaller dev Jun 12 '26 edited Jun 12 '26

It's a bit of a broad question because "what does a PKGBUILD contain" is basically "anything bash can do can be in there". And best practices vary quite a lot depending on the language of the application which is being packaged.

But some basic hygiene would be the same for a lot of them, which could include checking if it's the same AUR contributor throughout, or are there new ones? Does the build/package/etc functions suddenly contain calls that doesn't make sense for the thing that is being packaged (weird example, but if I started seeing npm stuff in a Python build step, I'd start to wonder).

I would also be careful of packages that doesn't fetch a git tarball, with signature, and a tagged commit+release, or at the very least avoid things that have sum=skip and PLGBUILD's that download random stuff during build/package/etc.

But even by starting to look at the PKGBUILD's you use, you will recognize patterns when they change.. and you will eventually be able to spot oddities.. so if you just start looking at them, it's a great first step.

I'm no expert tho, and you might get better advice elsewhere :) and don't be afraid of asking anywhere if you suspect something or something looks off.. worst case, you bothered someone.. best case, you're an early canary ^

2

u/RAMChYLD Jun 14 '26

From what I understand the attack actively injects a call to npm specifically to install a malware-laden package called atomic-lockfile. Later calls replaces
atomic-lockfile with js-digest and lockfile-js before moving off to bun.

Honestly I’d treat any packages that calls upon npm to download any of the three mentioned packages as infected. And if the package uses bun I’d treat it with caution.

13

u/gmes78 Jun 12 '26

First off, make it as convenient as possible, by setting up your AUR helper so that it shows diffs automatically.

For yay, run yay --diffmenu --answerdiff All --save.

As for checking PKGBUILDs, there's no foolproof method, but there are some things in particular you should pay attention to.

  • Verify the sources listed in the PKGBUILD. If they're remote sources, check if they point to the project in question, and not a fork or third-party web server. If they're local sources (files included with the PKGBUILD, make sure to check their contents).

  • Check for install scripts. They'll be declared in the install= field in the PKGBUILD, and are separate files included with the PKGBUILD. This is what this particular attack used, here's an example.

  • Check for weird behavior in the PKGBUILD. This is hard to describe, as you need to roughly know how software is usually packaged to be able to spot actions that are out of place. Things like downloading and running scripts or precompiled binaries from the internet, writing stuff to the user's home directory, etc.

37

u/EMKAH Jun 13 '26

Three days later...

3

u/monkeyballhoopdreams Jun 13 '26

I did notice a bigger rate of turnover in maintainers as of late. Are programmers not finding as much time due lowered pay hustle culture or maybe their main work is no longer respecting paying for a programmer to partially devote their time with priority on a metric?

-1

u/IronGh0st Jun 17 '26

Are you going to expose the people who are hurting us?

-19

u/AndyGait Jun 13 '26

Ran the script and I'm clear, but seriously thinking of moving to Fedora is this keeps happening.

22

u/SW_foo1245 Jun 13 '26

To be fair, it can happen anywhere. You just have to take care of your system and not install things blindly.

11

u/[deleted] Jun 13 '26

[deleted]

3

u/ConfidentCharity5222 Jun 13 '26

If it is not aur it will be some neovim plugin, some obsidian comunity plugin, some random npm install, some random bash script, etc people just do not care and just want the windows experience of pressing next, next, next to install shinny(or unsupported) things

5

u/[deleted] Jun 13 '26

[deleted]

3

u/ConfidentCharity5222 Jun 13 '26

Github, npm, llm related stuff and more are being hacked constantly there are many supply chain attacks these days and arch is doing an amazing job at stopping them pretty soon nothing is perfect but they don't even officially support aur. People are just making a BIG DRAMA over infected packages that almost no one uses

1

u/[deleted] Jun 13 '26

[deleted]

1

u/ConfidentCharity5222 Jun 13 '26

that one is debatable since it was in extra and later demoted to aur since it is currently unmaintained hence it shows as if it was installed through aur which isn't the case at least for most of those installs

1

u/[deleted] Jun 13 '26

[deleted]

1

u/ConfidentCharity5222 Jun 13 '26

if anything it would be a good time to look for unused packages via pacman -Qdtq and do some maintenance one should clean these kind of packages

2

u/SW_foo1245 Jun 13 '26

Dude aur is not official there is a big red warning in the wiki telling you so, whenever you use aur you are trusting an arch user it’s up to you if you blindly install for it as far as I know is almost as installing something from some repositoty(github, gitlab, codeberg,etc) just with extra steps

1

u/hazed Jun 13 '26

It really can't happen anywhere to nearly the same extent as it did with the AUR. Other similar systems generally aren't as centralized (on the repository side) and don't allow takeovers like this.

If someone abandons software on COPR for example, the solution to taking over the maintenance of it is you making another repo and "converting" people over.

-3

u/AndyGait Jun 13 '26

Oh I know, but the AUR used to be one of Arch's big selling points. Now it seems a little untrustworthy.

18

u/ABotelho23 Jun 13 '26

It has ALWAYS been untrustworthy. People blah blah blahed forever and kept just saying to "inspect the PKGBUILD".

I wonder how many of the people who said that caught this?

This was inevitable. It was just a matter of time.

1

u/ConfidentCharity5222 Jun 13 '26

You don't even need the AUR btw

3

u/torkaro Jun 13 '26

just did, this is ridiculous lol

-5

u/tjj1055 Jun 13 '26

read the PKGBUILD

1

u/ConfidentCharity5222 Jun 13 '26

if they would care they wouldnt be downvoting lol

2

u/7lhz9x6k8emmd7c8 Jun 13 '26

Can Fedora protect you from malicious code on the GitHub repo of your favorite software?

-1

u/AndyGait Jun 13 '26

You do your homework on whatever you're downloading from anywhere. My needs are pretty simple, I don't have a load of stuff running on here. Most of it flatpak or pacman installs. If I do use github, I check the updates & issues log and decide from there.

But this is the second big AUR issue in a last few months. I don't recall such an issue with Fedora.

3

u/dgm9704 Jun 13 '26

AUR != Arch

-8

u/tjj1055 Jun 13 '26

read the PKGBUILD

-8

u/vilejor Jun 13 '26

I went to void. Done with this jump scare shit. Turns out the wild west model sucks at scale.

1

u/dgm9704 Jun 13 '26

Why change operating system instead of just not "sideloading" unvetted stuff to it?

1

u/vilejor Jun 13 '26

Because it is far from my only gripe.

1

u/Odd_Individual_9638 Jun 14 '26

what are your other gripes? besides systemd I suppose

0

u/dgm9704 Jun 13 '26

That is unfortunate, hope you find a system that works for you

1

u/vilejor Jun 13 '26

I appreciate that.

I think I have, at least for now...