Am 12. Juni 2026 veröffentlichte das Arch-Linux-Team eine offizielle Sicherheitsmeldung: Im Arch User Repository (AUR) gab es eine Welle von schadhaften Paketübernahmen und -updates. Unbekannte Angreifer hatten es auf AUR-Pakete abgesehen und versuchten, Schadcode in PKGBUILD-Skripte einzuschleusen.
Die Meldung war knapp, aber unmissverständlich:
We are currently experiencing a high volume of malicious package adoptions and updates in the Arch User Repository.
Das Arch-Team war aktiv dabei, schadhafte Commits aufzuspüren und weitere Angriffe zu unterbinden. Gleichzeitig waren vorübergehend einige AUR-Funktionen eingeschränkt — darunter das Erstellen neuer Accounts, das Pushen von Paket-Updates und das Übernehmen von Paketen.
Meine Reaktion: Kurz tief durchatmen, dann systematisch prüfen.
Warum mein Workflow sicherer ist#
Ich nutze keinen AUR-Helper wie yay, paru oder ähnliches. Alles läuft
manuell. Das ist etwas mehr Arbeit, aber genau in Situationen wie dieser zahlt
es sich aus.
Mein üblicher Ablauf sieht so aus: Ich habe ein Verzeichnis ~/builds, in das
ich AUR-Pakete mit git clone herunterlade:
cd ~/builds
git clone https://aur.archlinux.org/brave-bin.git
cd brave-binBevor ich irgendetwas baue oder herunterlade, lese ich das PKGBUILD durch:
less PKGBUILDDabei achte ich besonders auf die source=-Zeilen: Woher kommt der Code? Gibt
es verdächtige curl- oder bash-Aufrufe, die nachträglich Schadcode nachladen
könnten? Erst wenn alles plausibel aussieht, wird gebaut und installiert:
makepkg
sudo pacman -U brave-bin-1:1.79.123-1-x86_64.pkg.tar.zstUpdates laufen über git pull, danach manuell neu kompilieren und installieren.
Kein Automatismus, kein blindes Vertrauen.
Dieses manuelle Vorgehen ist genau das, was das Arch-Team in seiner Sicherheitsmeldung empfiehlt und es ist die erste Verteidigungslinie gegen unbemerkt eingeschleusten Schadcode.
Hinzu kommt, dass ich generell sehr wenige AUR-Pakete einsetze. Je kleiner die Angriffsfläche, desto überschaubarer ist auch die Prüfung im Ernstfall.
Die eigene AUR-Historie rekonstruieren#
Auch wenn man sicher ist, dass man selbst kein verdächtiges Paket installiert
hat, ist es beruhigend, das schwarz auf weiß bestätigt zu sehen. Dafür bietet
pacman einige nützliche Befehle.
Welche Fremdpakete sind überhaupt installiert?
pacman -QmDieser Befehl listet alle Pakete auf, die nicht aus den offiziellen Repositories stammen, also AUR-Pakete und manuell installierte Pakete.
Wann wurde jedes Paket zuletzt angefasst?
pacman -Qi $(pacman -Qm | awk '{print $1}') | grep -E '^(Name|Install Date)'Das zeigt den letzten bekannten Zustand: entweder das Installationsdatum oder das letzte Update.
Die komplette Historie aus dem pacman-Log:
Der Befehl pacman -Qi zeigt nur den aktuellen Zustand. Wer die gesamte
Zeitlinie sehen möchte, also Erstinstallation und alle darauffolgenden
Upgrades, greift direkt ins Log:
grep -E "(installed|upgraded) ($(pacman -Qm | awk '{print $1}' | paste -sd '|' -))" /var/log/pacman.logUnd wenn man nur den jeweils letzten Eintrag pro Paket sehen möchte, ohne die gesamte Verlaufsgeschichte dazwischen:
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]}' | sortMeine Auswertung: Kein betroffenes Paket#
Hier ist die gefilterte Log-Ausgabe meines Systems mit Stand vom 13. Juni 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)Das Ergebnis der Analyse:
Keine kompromittierten Pakete. Ein Abgleich der Paketliste mit den offiziell gemeldeten schadhaften Paketnamen zeigt: Keines davon ist auf meinem System.
Saubere Update-Zeitfenster. Meine letzten Paket-Aktivitäten fanden alle am 2. Juni 2026 statt, also vor dem Bekanntwerden des Vorfalls am 12. Juni und außerhalb des kritischen Zeitfensters. Die Versionen und Zeitstempel stimmen mit den bekannten, sauberen Upstream-Releases überein. Keine Geister-Updates, kein unerklärliches Rauschen in der Timeline.
Manuelle Kontrolle als Schutzschicht. Da ich jedes PKGBUILD vor dem Bauen lese, ist das Risiko, unbemerkt Schadcode einzuspielen, ohnehin deutlich geringer als bei einem automatisierten AUR-Helper.
Das Log bestätigt: Mein System ist von diesem Vorfall unberührt geblieben.
Was man jetzt tun sollte#
Falls du auch Arch Linux mit AUR-Paketen nutzt, empfehle ich folgende Schritte:
- Paketliste prüfen mit
pacman -Qmund mit der Paketliste im Community-Tool auf GitHub abgleichen, dort wird die Liste der über 1.500 betroffenen Pakete gepflegt und ist stets aktuell. - Log-Historie auslesen mit den oben genannten Befehlen, um zu sehen, wann welche Pakete installiert oder aktualisiert wurden.
- PKGBUILDs manuell prüfen: Jetzt und in Zukunft. Der Befehl
less PKGBUILDkostet zwei Minuten und kann viel Ärger ersparen. - AUR-Helper mit Bedacht einsetzen. Wer
yayoderparunutzt, sollte sicherstellen, dass die Diff-Anzeige bei Updates aktiviert ist, damit Änderungen am PKGBUILD sichtbar sind, bevor sie ausgeführt werden.
Wer viele AUR-Pakete installiert hat oder den Abgleich lieber automatisieren möchte, kann das Python-Tool aus dem Community-Repo nutzen und es erledigt den Check gegen die Liste der über 1.600 betroffenen Pakete automatisch:
# Einfacher Check
python -m aur_check
# Vollständiger Scan mit allen optionalen Prüfungen
python -m aur_check --full
# Liste aktuell halten und dann scannen
python -m aur_check --refresh --fullDas Tool benötigt Python 3.14+ und keine weiteren Abhängigkeiten.
Zu Windows wechseln? Auf keinen Fall. Vorfälle wie dieser gehören zum Leben mit einem Community-Repository und wer seinen Workflow im Griff hat, schläft auch danach ruhig. Arch Linux bleibt ❤️
Liebe Grüße
Sebastian
