AUR
AUR
Andre Franca ·July 19, 2026 · 3 min read
As an Arch Linux user, I’ve always praised the AUR (Arch User Repository) as one of Arch’s greatest strengths. Actually, it’s one of the reason why so many people recommend Arch.
⚠️ Heads up!This post is over old and may contain outdated information, opinions, or broken links.
As an Arch Linux user, I’ve always praised the AUR (Arch User Repository) as one of Arch’s greatest strengths. Actually, it’s one of the reason why so many people recommend Arch.
Last month, I found out that over 400 AUR packages were compromised in a massive supply chain attack, leaving me feeling the same frustration many of you probably felt as well.
I spent some time researching, running some checks on my system, and figuring out whether my system was affected.
What Was Compromised?
As far as I know, the attack exploited the AUR’s orphan-package adoption process, where attackers took over packages that had no active maintainer. The malicious code included:
- `npm install atomic-lockfile` (malicious npm package v1.4.2)
- `bun install js-digest` (second wave payload)
- Payload stored at: `src/hooks/deps`
Step 1: Checking If I Had Compromised Packages
Listing All My AUR Packages
# Using yay (AUR helper)
yay -Qam > packages_aur.txtCross-Referencing Against Compromised Packages
I downloaded a community’s list of compromised packages:
curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txtThen checked if any of my packages matched:
# Check with yay output
grep -wFf compromised.txt packages_aur.txtIf grep returns nothing, you probably don’t have any compromised packages.
Step 2: I Run Some Additional Checks
Checked for Malicious Build Scripts
# Searched for malicious npm/bun patterns in pacman cache
grep -rl "atomic-lockfile" /var/cache/pacman/pkg/ 2>/dev/null
grep -rl "js-digest" /var/cache/pacman/pkg/ 2>/dev/null
grep -rl "lockfile-js" /var/cache/pacman/pkg/ 2>/dev/nullSearched for the payload path in your home directory
grep -rl "src/hooks/deps" ~/ 2>/dev/nullChecked for eBPF Rootkit
# If the malicious package ran as root, rootkit maps is supposed to appear here
sudo ls /sys/fs/bpf/Checked for Suspicious systemd Services
# Looked for unknown services
ls /etc/systemd/system/ | grep -v "^pacman\|^systemd"
ls ~/.config/systemd/user/Only standard services (printer, bluetooth, network) should appear by default.
Step 3: Action Plan Based on Results
In my case, I found no matches for any of the above checks, even though I decided to replace most AUR packages with official repo versions or Flatpak equivalents.
If You’re Compromised (Matches Found)
⚠️ CRITICAL: If any flagged package was installed/updated, I would as soon as possible:
1. Treat the system as compromised; 2. Reinstall Arch from trusted media; 3. Rotate all credentials immediately: * Browser passwords * SSH keys * GitHub/npm tokens * Slack/Discord/Teams sessions * Vault tokens * Docker/Podman credentials * Cloud access keys * You name it… 4. If the package ran as root, assume the eBPF rootkit is present and reinstall Arch from trusted media.
Managing AUR-Only Packages Securely
If the package is AUR-only, I would inspect the build script and verify it’s safe before installing.
# Download package WITHOUT installing
cd /tmp
yay -G <package-name>
cd <package-name>REVIEW before building:
cat PKGBUILD
cat .install # if existsLook for suspicious patterns:
- npm install from obscure URLs
- bun install from unknown sources
- obfuscated commands
- downloads from random GitHub repos
Verify checksums:
grep -E "sha256sums|md5sums" PKGBUILDI hope this helps!
Tags
Share on Mastodon
Enter your Mastodon instance:
Cancel Share
Recent Posts
| Convocação da Seleção Brasileira | May 31, 2026 | | ---------------------------------------------------------------------------------------------------------------------------- | ------------ | | Brazil Failed (Again) to Confront Organized Crime | May 30, 2026 | | MS cut Game Pass Subscription Prices | May 28, 2026 |
