The “Atomic Arch” campaign compromised over 1,500 AUR packages between June 10-12, targeting SSH keys and API tokens. If you updated via yay or paru during that window, you need to audit your local system.
I’ve built a client-side tool to help with this.
Local Processing: Your package list never leaves your browser. All comparisons are done client-side.
Live Data: It fetches the verified malicious list directly from the official Arch servers (md.archlinux.org) to ensure it’s always current. Zero Bloat: No trackers, no ads, no cookies. How to use:
- Run pacman -Qm
- Paste the output into the tool
I’d nuke and pave if I were an Arch btw user. Then rotate keys and passwords everywhere impartant.
I would recommend to firstly check the update window for the package. It seems that these packages only contained the malware PKGBUILD for a certain time period, before the commit was reverted back by the arch/air devs.
Then if you find youself infected, try
Even if you are not affected?
How do I know I’m not affected? I have to be fairly certain the packages identified are the only ones that were affected. That assesment could be wrong. If I 100% trust it, then yeah, I can trace if any of those packages/versions touched my machine. I would trust the package manager.
Here is an example with searxng-git: https://aur.archlinux.org/cgit/aur.git/log/?h=searxng-git
Look at the recent changes, inclusive the dates. The last change is from February. Let’s open it: https://aur.archlinux.org/cgit/aur.git/commit/?h=searxng-git&id=24cc08c8aad50f5114db2d85251bde918b017cb8 with a description of “new ver”:
diff --git a/.SRCINFO b/.SRCINFO index 3d2546ff3229..7ff006da7650 100644 --- a/.SRCINFO +++ b/.SRCINFO @@ -1,6 +1,6 @@ pkgbase = searxng-git pkgdesc = A privacy-respecting, hackable metasearch engine - pkgver = r9110.3f91ac4 + pkgver = r9201.ad42b55 pkgrel = 1 url = https://searxng.github.io/searxng/ arch = any @@ -11,6 +11,7 @@ pkgbase = searxng-git makedepends = python-wheel makedepends = python-setuptools makedepends = python-msgspec + makedepends = python-yaml depends = valkey provides = searxng conflicts = searx diff --git a/PKGBUILD b/PKGBUILD index 6f8aa8e7938a..ab4f903ea4c9 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -2,7 +2,7 @@ pkgname=searxng-git _pkgname=searxng -pkgver=r9110.3f91ac4 +pkgver=r9201.ad42b55 pkgrel=1 pkgdesc="A privacy-respecting, hackable metasearch engine" arch=('any')Nothing has anything to do with the attack we experience right now. That is how you know that you are not affected by the current attack. Use scripts to check if you are attacked, and then lookup every single AUR package and verify yourself. If you can’t be sure that you are under attack, then sure, reinstall and do not trust it. But if you can be sure, like I am, then you have nothing to worry. At least speaking of this specific attack.
In example if you don’t use the AUR at all, or the packages you installed are not affected. In example the packages from the AUR I have installed have no such changes that could affect me from this malicious attack. Also if the packages you have are not updated in the last couple of days (or weeks) and are not even orphaned packages, then it is unlikely that you are affected by this attack. I am not talking of specific packages only, but a systematic logic you can follow.
The script https://github.com/lenucksi/aur-malware-check does a good job and not just check for known infected packages.
Seems a bit extreme.
Most dipshits tend to go straight for the nuclear option so honestly checks out.
It’s a Windows user habit.
This dipshit (me) hasn’t reinstalled their OS since 2014. Not Arch btw.
But if my OS was affected by a supply attack like this, I wouldn’t trust the analysis on which packages were affected and which weren’t so I’d likely nuke and pave as all my and my family data is here.
I wouldn’t trust the analysis either; luckily most PKGBUILD scripts are quite short and simple. It would take significantly less effort to hand-audit every single file I’ve gotten from the AUR than it would to reinstall Arch.
As long as you’re using a slower release cycle, ie something like Debian, then you shouldn’t need to be concerned.
I think anyone riding the crest of the wave with Arch (& esp. the AUR) would likely be aware that things break, so, supply chain attacks are likely to be seen here quicker.
I honestly wouldn’t be surprised if PPAs had similar issues, but might take longer to be noticed.
Personally, I have a lot of Ansible building my stuff, so actually rebuilding things wouldn’t be an issue, but, would I then be installing everything with all the current latest malware…?
If your current system were affected by a supply attack, then you would reinstall your system too. I use Arch[1], BTW and did not reinstall the system.
1: Arch=EndeavourOS
I’m an Arch user. I check the diffs when I update a package. I won’t do anything as I’m obviously not compromised.