I keep my system up to date. If you don’t feel safe using the AUR then don’t use it. However don’t have programs on your system with out updating them (can be just as bad as the malware by allowing other security issues)
Well, some software I use, like the browser, is essential, and on Arch, it’s only in the AUR. For Brave, it’s not best to switch from the AUR to the flatpak version, since, if I remember correctly, it’s not directly managed by the team and isn’t an “official” version.
I might not use other software, but it’s not that I’m unsure, it’s just that I need some of that software, and it’s only in the AUR, on Arch.
With Debian, for example, I wouldn’t have this problem, since it adds a dedicated repo.
I don’t think the issue is “still going on.” Sure, the AUR can be risky if you’re not careful. It’s always been that way. But the original issue of rogue pakcages being infected has died down tremendously. I’ve had no issues updating all AUR packages since this all began.
The problem with the malicious packages attack seems to have been caused by newly registered accounts and lasted about 2 or 3 days. Only less then 2% of the packages where infected, and during the “cleanup” of the AUR, maintainers stopped the registry of new accounts onto further notice. That stopped the malware attack, as far as I know. Only recently they allow the registration of new accounts again, but there are some safety checks added.
Main thing is not to consider the AUR as “just another” repository, and … well you know the rest.
EXACTLY. Just as most Arch users have done for years.
As far as I’m concerned, if someone is worried enough to not upgrade already installed AUR packages, Arch (or an Arch -based distro) may not be for you.
Thanks.
Also because the AUR packages I have seem to be unaffected by the problem, and in any case, the checks I ran with the scripts at the time to see if I was infected showed that my system was clean.
Out of caution, I re-ran one after the update. As before, there are no problems.
[sermor@archlinux e29e68d9ed1513ddd80ae9cc4a6c9f0e-79464ce9d55b1d50b5fb013fd243bc8d5018957f]$ ./atomic-arch-check.sh
Atomic Arch / atomic-lockfile AUR check
Locating AUR helper caches...
using: /home/sermor/.cache/yay
Note: AUR activity since the campaign began (2026-06-09):
Installed/upgraded AUR package(s) in the campaign window (Worth checking) :
2026-06-09 lmstudio-bin
2026-06-10 brave-bin
2026-07-23 bottles
2026-07-23 brave-bin
2026-07-23 coolercontrol-bin
2026-07-23 coolercontrol-bin-debug
2026-07-23 coolercontrold-bin
2026-07-23 coolercontrold-bin-debug
2026-07-23 fvs2
2026-07-23 fvs2-debug
2026-07-23 lmstudio-bin
2026-07-23 patool
2026-07-23 protonup-qt
2026-07-23 python-setuptools-reproducible
2026-07-23 ventoy
2026-07-23 ventoy-debug
2026-07-23 weasis-bin
2026-07-23 yay
2026-07-23 yay-debug
[1/2] Looking for the malicious dependency or its delivery...
- Local scan (scriptlets, hooks, AUR caches)... NOT FOUND
- Check against known impacted AUR packages list... (Uses curl|wget, but can be skipped)
Download from https://md.archlinux.org/s/SxbqukK6IA/download ? [y/N]: y
ON REPORTED LIST:
├─ vidcutter 6.0.5.3-5
│ built 2026-02-15 23:54 ([OK] built before 2026-06-09)
│ installed 2026-02-15 23:54
│ recipe /home/sermor/.cache/yay/vidcutter
│
└─ [OK] All built before the campaign: likely safe.
[2/2] Checking for payload leftovers...
- Scan for systemd persistence fingerprint... NOT FOUND
- Check /usr/bin/monero-wallet-gui (cryptominer staging target)... NOT PRESENT
- Scan for eBPF rootkit maps (hidden_pids/hidden_names/hidden_inodes)... (needs root)
Will use 'bpftool' if available, else direct stat(), to dodge a compromised getdents64().
To run it yourself instead:
sudo bpftool map list # Review suspicious maps
sudo bpftool map list | grep -E 'hidden_(pids|names|inodes)' # Known IOC names
Run it now? (you'll be prompted for your password)
[y]es / [s]how exact command / [N]o skip: y
[sudo] password di sermor:
Method: bpftool map list (asks the kernel directly)
5 map(s): 5 known-good (systemd/NetworkManager/bpftool), 0 to review.
(all maps belong to known system services; nothing unexpected)
No known-IOC map names matched; all maps belong to known system services.
=============================================================================
LIKELY CLEAN: no Atomic Arch payload found.
-----------------------------------------------------------------------------
- You updated AUR package(s) in the campaign window.
=============================================================================
That’s true, but I quote verbatim from their website:
“Brave is available as a Flatpak package from Flathub. While it is maintained by Brave Software, it is not yet working as well as our native packages. In addition, it modifies Chromium sandboxing in ways which have not been vetted by the Brave or Chromium security teams. We currently recommend that users who are able to use our official package repositories do so instead of using the Flatpak.”
So I don’t think it’s a good choice to use the flatpak version, at least of Brave.
If you don’t trust flatpak, use the AUR version. But imho honestly it’s fine. There are immutable distros with tons of users who use Chrome, Chromium or Brave through flatpak on a daily basis. It’s a responsible disclaimer and I’m glad they make it, but it has to be considered in context.
But overall, if you don’t trust flatpak (or AUR) that’s personal, responsible behavior too. Hate to gatekeep here, but don’t use one of the distros depending on these packaging if you don’t want the burden of vetting them yourself.
Archcanary is a layered security detection stack for Arch Linux — scanning for malicious AUR packages, systemd/eBPF persistence, npm/bun cache poisoning, kernel module tampering, library injection, and more.
It started from lenucksi/aur-malware-check under the name aur-malware-check, originally focused on the June 2026 AUR supply-chain attack. As the tool grew to cover a much broader set of system checks — integrating a GUI frontend, automated systemd timers, and multiple detection layers — the scope outgrew the original name.
aurscan, an LLM-based PKGBUILD scanner, is an optional add-on; archcanary works fully without it.
ps: search forum-scout — archcanary [mabox]. how it started.
It’ll probably stay in beta for a while — it still needs testing.
Right now there are 2 Mabox users testing it: one running the system-wide (root) install, one using the per-user install.
It would be helpful if you tested it too.
Read-only by design. The scanner detects and reports — it never deletes, quarantines, or disables anything. Remediation is left to you. The only writes are its own logs and config lists. install.sh, --refresh, and the allowlist editors (DKMS, systemd, bpftool) are the exceptions — all explicit.
I plan to take it out of [BETA] once roughly half a year passes without major changes and most bugs have been ironed out.
Not planning to build that myself for now — needs a server, hosting, abuse protection, someone to keep it running, that’s a real commitment.
Current setup stays simple: when you hit a false positive or a miss, report it (GitHub issue or here) and I fold it into the detection lists.
Someone’s welcome to fork it and build the online service on top if they want to take that on.
I think there should be more tools like this available. They help make the work easier and lighter, or at least guide it correctly. It saves time and effort, and it’s more efficient. At least in my opinion.
