Das Arch User Repository geriet im Juni ins Visier eines gezielten Angriffs: Im großen Stil wurden verwaiste Pakete übernommen und mit Schadcode infiziert. Ein Schreckmoment für alle, die viel Software auf diesem Weg installiert haben. Ich gehöre zwar nicht dazu, aber ein einziges falsches PKGBuild reicht, um den Rechner zu kompromittieren. Mein Glück war allerdings: Ich war im Urlaub und keiner meiner Rechner in dieser Zeit überhaupt an. Doch das Geschehen wirft die grundsätzliche Frage auf: Software aus dem AUR installieren oder besser nicht?
Man muss auch mal Glück haben: Als ich am 4. Juni in den Urlaub gefahren bin, war (vermutlich) alles noch in Ordnung. Mein Gaming-PC und mein Notebook waren ausgeschaltet als der großangelegte Angriff auf das AUR anlief. Als ich meine privaten Rechner vor zwei Tagen das erste Mal wieder hochgefahren und aktualisiert habe, war das Schlimmste bereits vorbei. Die kompromittierten Installationsanleitungen sind entfernt (und zwar hoffentlich alle). Aber selbst dann war mein Risiko gering, denn ich installiere nur selten Software aus dem AUR.
Eins muss nochmal betont werden: Die offiziellen Paketquellen von Arch Linux oder CachyOS waren nicht betroffen. Die Vorfälle beziehen sich nur auf das Community-verwaltete AUR.
Was ist das AUR?
Das AUR – kurz für Arch User Repository – ist keine offizielle Paketquelle von Arch Linux, sondern ein zusätzliches Verzeichnis, das von der Community verwaltet wird. Es enthält keine Pakete, sondern sogenannte PKGBuilds. Das sind kleine Textdateien, die dabei helfen, Software zu installieren. Sie weisen Installationstools wie yay oder paru an, welche Software sie wo herunterladen sollen, ob und wie der Code kompiliert werden soll und welche zusätzliche Software dafür installiert werden muss. Das AUR ist also eher eine Art Rezeptesammlung aus der Community.
Anders als die Software in den Repositories einer Linux-Distribution wie CachyOS oder Arch Linux gibt es für die Installationsrezepte, also die PKGBuilds im AUR keine Qualitätsprüfung. Es bleibt allen selbst überlassen, zu prüfen, ob die Quelle zuverlässig ist und ob in den Installationsanweisungen etwas steht, das da nicht hingehört.
Wer auf der AUR-Website einen Blick auf die Infos eines PKGBuilds wirft, kann zwar nachsehen, ob viele „Stimmen“ und eine hohe „Beliebtheit“ vorhanden sind, doch beim aktuellen Vorfall hätte das nichts geholfen. Dabei wurden verwaiste PKGBuilds übernommen, die nicht mehr betreut werden, frühere Daten zum Ansehen blieben dabei erhalten.
Wie sieht ein PKGBuild aus und was steht da drin?
Auf der AUR-Website lassen sich Paketdetails zu jedem PKGBuild einsehen, etwa wer sich darum kümmert. Über den Link „PKGBuild ansehen“ kann man die Datei vollständig abrufen und auf verdächtige Post-Install-Skripte oder anderes prüfen. Bei der Installation sollte man sich immer das PKGBuild anzeigen lassen und bei Updates insbesondere auf Veränderungen achten, die als solche gekennzeichnet sind. Mein Verdacht ist allerdings: Die meisten Menschen klicken die Überprüfung einfach weg und hoffen das Beste. Gefährliche Veränderungen im Code zu finden dürfte außerdem für die meisten Leute gar nicht so einfach sein.
Auch in der Kommandozeile lassen sich Infos zu PKGBuilds aus dem AUR abrufen: So listet paru -Qi PAKETNAME wichtige Infos zu installierter Software auf, etwa den Maintainer („Packer“, ob das Paket als Abhängigkeit für eine andere Software installiert wurde („Benötigt von“) oder wann es zuletzt aktualisiert wurde. Der Befehl paru -Gp PAKETNAME zeigt das ganze PKGBuild an.
Wie riskant ist es, Software aus dem AUR zu installieren?
Wie groß das Risiko ist, Software aus dem AUR zu installieren, demonstriert der aktuelle Fall. Die Angreifer:innen ergänzten die Installationsbeschreibungen um eine zusätzliche Abhängigkeit für die Javascript-Paketmanager npm oder bun und sorgten dafür, dass npm dann ein Malware-Paket herunterlädt und installiert. In diesem Fall hatte es die Malware vor allem darauf abgesehen, Zugangsdaten abzugreifen, andere Szenarien sind aber ebenfalls denkbar.
Das Risiko, mit einem kompromittierten System Daten zu verlieren oder Unbekannten gar Zugriff auf die eigenen Konten bei Online-Diensten zu geben, ist also hoch. Ich persönlich verzichte deshalb wo möglich auf das AUR und greife eher zu Alternativen. Außerdem schaue ich bei jedem Update, ob die wenigen Dinge aus dem AUR weg können und prüfe nach bestem Wissen die PKGBuilds.
Wer nach dem 11. Juni 2026 Updates aus dem AUR eingespielt hat, sollte nachlesen, was nun zu tun ist. Das beschreibt das CachyOS-Wiki im Thread „Compromised – Almost 2000 packages affected“. Einen ersten Überblick gibt der Befehl pacman -Qm, der Pakete auflistet, die nicht aus den offiziellen Repositories stammen. Diese kann man dann mit der Liste der betroffenen Software vergleichen. Dafür steht auch ein Skript bereit.
Das einmal kompromittierte System lässt sich allerdings nicht so einfach säubern, mit etwas Pech hat man sich dabei auch ein Rootkit eingefangen. Steht ein Snapshot des Systems von vor dem 11. Juni 2026 zur Verfügung, ist es empfehlenswert, zu diesem zurückzukehren und anschließend Updates einzuspielen. Zwar kann man prüfen, ob es Hinweise auf ein eBPF-Rootkit gibt (ls -la /sys/fs/bpf/hidden_*) und nachsehen, ob Systemd-Dienste hinzugefügt wurden (systemctl list-units --type=service --state=running). Doch wirklich sicherstellen, dass das System in Ordnung ist, lässt sich damit nicht. Meine Empfehlung ist: Im Zweifelsfall Daten sichern und neu installieren.
Sichere Alternativen
Das Problem mag vorerst weitgehend behoben sein, weitere Angriffe können aber jederzeit folgen. Ob sie dann ebenso schnell bemerkt werden, muss sich zeigen. Diesmal fiel vor allem die hohe Anzahl der veränderten PKGBuilds auf. Einzelne Beschreibungsdateien könnten noch immer Malware installieren.
Besser ist es deshalb, Software generell nur aus den Paketquellen der Distribution zu installieren und weder Installationsskripte von irgendwelchen Websites auszuführen noch Software aus dem AUR zu verwenden. Wenn mir eine Anwendung in den Paketquellen fehlt, dann prüfe ich, ob es sie als Flatpak oder AppImage gibt. In beiden Fällen läuft die Anwendung in einer Art Sandbox und hat nur begrenzt Zugriff auf das System, die Hardware und die Verzeichnisse auf der Festplatte. Über Konflikte mit unterschiedlichen Bibliotheken muss man sich keine Gedanken machen, Flatpaks bringen alles nötige in der passenden Version mit oder greifen auf gemeinsam genutzte Platform-Flatpaks zurück.
Oder man lädt sich ein Programm direkt beim Hersteller herunter. Sinnvoll finde ich das zum Beispiel bei der Videoschnittsoftware DaVinci Resolve. Die habe ich lieber mit einer Installationsdatei von BlackmagicDesign installiert als mit paru aus dem AUR.
Es lohnt sich, darauf zu achten, Software nur aus vertrauenswürdigen Quellen zu installieren und auch immer mal wieder zu entrümpeln. Auch ein Linux-System ist nur dann möglichst sicher, wenn man diesen Hinweis beachtet.
Schreibe den ersten Kommentar