On June 12, 2026, the Arch Linux team released an official security announcement: A wave of malicious package acquisitions and updates occurred in the Arch User Repository (AUR). Unknown attackers targeted AUR packages and attempted to insert malware into the PKGBUILD scripts.
The message was brief, but clear:
We are currently experiencing a high volume of malicious package adoptions and updates in the Arch User Repository.
The Arch team was actively involved in detecting problematic commits and preventing further attacks. At the same time, some AUR functions were temporarily restricted, including the creation of new accounts, the pushing of package updates, and adopting packages.
My first reaction: Take a quick, deep breath, and then systematically check everything.
Why my workflow was safer from the start#
I don’t use any AUR helpers like yay, paru, or similar things; everything is
done manually. It takes a bit more time, but in situations like this, it’s
definitely worth it.
My usual workflow goes like this: I have a directory called ~/builds, into
which I download AUR packages using git clone.
cd ~/builds
git clone https://aur.archlinux.org/brave-bin.git
cd brave-binBefore I build or download anything, I read through the PKGBUILD.
less PKGBUILDIn doing so, I pay special attention to the lines containing source=. Where
does this code come from? Are there any suspicious calls to curl or bash
that might potentially load malicious code later on? Only when everything seems
plausible will the code be compiled and installed.
makepkg
sudo pacman -U brave-bin-1:1.79.123-1-x86_64.pkg.tar.zstUpdates are applied via git pull; after that, you need to recompile and
reinstall the software manually. No automation involved, and no blind trust
should be placed in the process.
This manual procedure is exactly what the Arch team recommends in their security bulletin; it represents the first line of defense against malware that is secretly installed.
Additionally, I generally use very few AUR packages. The smaller the attack surface, the easier it is to monitor and secure in an emergency.
Reconstructing one’s own AUR history#
Even if you’re sure that you haven’t installed any suspicious packages yourself,
it’s reassuring to have that confirmed in writing. For this purpose, pacman
provides some useful commands.
Which third-party packages are actually installed?
pacman -QmThis command lists all packages that do not come from the official repositories, namely AUR packages and manually installed packages.
When was the last time each package was touched/processed?
pacman -Qi $(pacman -Qm | awk '{print $1}') | grep -E '^(Name|Install Date)'This shows the last known status: either the installation date or the last update.
The complete history from the pacman log:
The command pacman -Qi only knows the current state. If someone wants to see
the entire timeline – that is, both the initial installation and all subsequent
upgrades – they need to directly access the log files.
grep -E "(installed|upgraded) ($(pacman -Qm | awk '{print $1}' | paste -sd '|' -))" /var/log/pacman.logAnd if you just want to see the last entry for each package, without all the previous history in between.
grep -E "(installed|upgraded) ($(pacman -Qm | awk '{print $1}' | paste -sd '|' -))" /var/log/pacman.log \
| awk '{cron[$4]=$0} END {for (p in cron) print cron[p]}' | sortMy assessment: No affected package#
Here is the filtered log output from my Arch Linux system as of June 13, 2026:
[2025-06-17T19:39:58-0300] [ALPM] installed xautolock (2.2-8)
[2025-06-20T22:19:16-0300] [ALPM] installed python-pywal16 (1:3.8.9-1)
[2025-06-23T17:15:30-0300] [ALPM] installed catppuccin-gtk-theme-git (r62.c961826d0-1)
[2025-06-25T19:06:48-0300] [ALPM] installed mpdris2 (0.9.1-2)
[2025-12-23T11:20:07-0300] [ALPM] upgraded gcc14 (14.3.1+r25+... -> 14.3.1+r416+...)
[2025-12-23T11:20:07-0300] [ALPM] upgraded gcc14-libs (14.3.1+r25+... -> 14.3.1+r416+...)
[2026-01-16T10:08:36-0300] [ALPM] installed lgx2userspace-git (0.3.0.r22.g0547560-1)
[2026-04-02T16:11:50-0300] [ALPM] installed sunshine (2025.924.154138-3)
[2026-04-04T16:55:42-0300] [ALPM] installed mqttx-git (1.13.0.r0.g9c413d9-1)
[2026-05-12T17:35:35-0300] [ALPM] installed llama.cpp-cuda (b9124-1)
[2026-05-12T18:30:43-0300] [ALPM] installed llama-swap (v211-1)
[2026-05-20T17:25:54-0300] [ALPM] upgraded brave-bin (1:1.89.141-1 -> 1:1.90.124-1)
[2026-05-25T12:29:49-0300] [ALPM] upgraded miniconda3 (25.5.1.1-2 -> 26.3.2.2-1)
[2026-06-02T16:13:09-0300] [ALPM] upgraded darkly (0.5.21.r0.gc26d5e6-1 -> 0.5.37-1)
[2026-06-02T17:21:25-0300] [ALPM] installed papirus-folders-catppuccin-git (r30.f83671d1-2)
[2026-06-02T17:37:36-0300] [ALPM] installed catppuccin-cursors-mocha (2.0.0-1)The result of the analysis:
No compromised packages. A comparison of the package list with the officially reported damaged package names shows that none of those packages are on my system.
A clear update timeline: All of my recent package-related activities occurred on June 2, 2026 – therefore, before the incident was reported on June 12, and outside of the critical time frame. The version numbers and timestamps match those of the known, legitimate upstream releases. There are no “ghost” updates, nor any unexplained anomalies in the timeline.
Manual control as a layer of protection: Since I read every PKGBUILD file before building it anyway, the risk of inadvertently introducing malicious code is already much lower compared to using an automated AUR helper.
The log confirms that my system remained unaffected by this incident.
What You Should Do Now#
If you also use Arch Linux with AUR packages, I recommend the following steps:
- Check the package list using
pacman -Qmand also comparing it with the actual package list available. Compare with the community tool on GitHub: The list of the over 1,500 affected packages is maintained there and is always up to date. - Read the log history using the commands mentioned above to see which packages were installed or updated, and when.
- Manually review PKGBUILD files — now and in the future. The command for
doing this
less PKGBUILDtakes just two minutes to complete and can save a lot of trouble. - Use the AUR-Helper with caution. Anyone who uses
yayorparushould make sure that the diff display is enabled during updates, so that changes to the PKGBUILD file are visible before they are applied.
Those who have installed many AUR packages or prefer to automate the comparison process can use the Python tool from the community repository. It will automatically perform the check against the list of over 1,600 affected packages.
# Check if you have any infected packages
python -m aur_check
# Full scan with all optional checks (systemd, eBPF, npm + bun cache)
python -m aur_check --full
# Refresh the package list from the official Arch Linux HedgeDoc, then scan
python -m aur_check --refresh --fullThe tool requires Python 3.14+ and no additional dependencies.
Switch to Windows? Absolutely not. Incidents like this are just part of using a community repository; anyone who manages their workflow properly can sleep well after that. Arch Linux stays ❤️
Best regards,
Sebastian
