Ich war nie ein Fan vom AUR. Genauso wenig wie von PPAs, von Copr oder von irgendeiner anderen Konstruktion, bei der sich ein anonymer Dritter zwischen dich und das Upstream-Projekt schiebt und dafür ungefragt Code auf deinem System ausführen darf. Was ich mir aber immer verkniffen habe, war die generelle Warnung, weil das Gegenargument lange plausibel klang: Wer weiss was er tut, wer die Build-Skripte liest, dem passiert schon nichts. Diese Zurückhaltung gebe ich hiermit auf. Das Argument war schon immer bequem, seit Juni 2026 ist es schlicht falsch, und zwar nachweislich widerlegt von genau jenen Leuten, die PKGBUILDs beruflich lesen.
Seit rund sieben Wochen läuft eine Angriffswelle nach der anderen über das AUR. Nicht ein Zwischenfall, nicht ein unglücklicher Einzelfall, sondern eine durchgehende Kampagne mit mehreren Stufen, wachsender Raffinesse und einer Verteidigung, die jedes Mal einen Schritt zu spät kommt. Am 30. Juli hat das Arch-DevOps-Team die Paketadoption abgeschaltet, am 1. August dann alle Pushes ins AUR. Das ist keine Vorsichtsmassnahme mehr, das ist eine Notbremse. Und für mich ist es der Punkt, an dem aus meinem privaten Unbehagen eine klare Empfehlung wird.
Was tatsächlich passiert ist
Fangen wir chronologisch an, denn die Kette ist wichtiger als jeder Einzelvorfall.
Bereits 2018 wurde ein verwaistes PDF-Viewer-Paket im AUR übernommen und mit Schadcode versehen. Das Muster war damals schon dasselbe wie heute: nicht ein neues Paket mit ähnlichem Namen anlegen, sondern ein bestehendes, vertrauenswürdiges Paket adoptieren und dessen Reputation erben. Im Sommer 2025 folgte die nächste Runde. Am 16. Juli 2025 lud ein Angreifer die Pakete librewolf-fix-bin, firefox-patch-bin und zen-browser-patched-bin hoch, die einen Remote Access Trojaner nachgeladen haben. Die Pakete waren rund 46 Stunden online, bevor sie entfernt wurden. Im selben Jahr überstand das Projekt zusätzlich einen zweiwöchigen Denial-of-Service-Angriff auf die AUR-Infrastruktur.
Das eigentliche Erdbeben kam am 11. und 12. Juni 2026. Die Sicherheitsfirma Sonatype taufte die Kampagne "Atomic Arch". Angreifer hatten über den regulären Adoptionsprozess verwaiste AUR-Pakete übernommen und in deren PKGBUILD ein Post-Install-Skript eingebaut, das per npm ein Paket namens atomic-lockfile nachlädt. Anfangs war von über 400 betroffenen Paketen die Rede, kurz darauf von mehr als 1500. Die Nutzlast war kein Scherz: ein in Rust geschriebener "Credential Stealer", der es auf Browser- und Electron-Daten, Slack, Microsoft Teams, Discord, Telegram, GitHub-Zugangsdaten, npm-Tokens, HashiCorp-Vault-Tokens, Docker- und Podman-Konfigurationen, SSH-Keys, VPN-Daten und Shell-Historien abgesehen hatte. Lief das Ganze mit Root-Rechten, kam optional ein eBPF-basiertes Rootkit dazu, das Prozesse, Dateien und Netzwerkschnittstellen versteckt.
Besonders perfide: Einer der Accounts gab sich als bekannter, legitimer Maintainer aus.
Kaum hatte Arch am 13. Juni Entwarnung gegeben, kam am 14. Juni die zweite Welle. Der Entwickler "a821" meldete eine neue Runde infizierter Pakete, diesmal mit obfuskiertem Code. Betroffen waren unter anderem diverse Node.js-Pakete, ein Plasma-6-Applet, mehrere Firefox-Pakete, der Aura-Browser, LibreWolf-Erweiterungen und ein NeoVim-Plugin. Nicolas Boichat fand kurz darauf weitere Fälle, in denen der Aufruf über bun statt npm versteckt wurde. Gefunden hat er sie mit einem lokalen KI-Modell, nicht von Auge. Das ist ein Detail, auf das ich später zurückkomme.
Danach wurde es kurzzeitig albern und trotzdem lehrreich: Ab dem 14. Juni tauchten in über 70 AUR-Paketen Commits auf, die russischsprachige Beschimpfungen in die .bashrc, .zshrc und Fish-Konfiguration der Nutzer schrieben. Harmlos in der Wirkung, verheerend in der Aussage. Wer beliebigen Text in deine Shell-Konfiguration schreiben kann, kann dort auch beliebigen Code hinterlegen. Der Unterschied zwischen einem Trollkommentar und einer Backdoor ist an dieser Stelle exakt null.
Die dritte Welle begann laut dem Independent Federated Intelligence Network am 29. Juli mit dem Paket openconnect-sso. Sie ist die bisher sauberste Arbeit. Die erste Stufe ist ein gestripptes x86-64-Ladeprogramm, das aktiv prüft, ob es in einem Debugger, einer Sandbox, einer virtuellen Maschine oder einer CI/CD-Umgebung läuft. Erst wenn nichts davon zutrifft, richtet es systemd-Services und Cronjobs für die Persistenz ein, startet einen als dbus-daemon getarnten Tor-Client und holt die zweite Stufe von einem Onion-Server.
Diese zweite Stufe ist wieder ein Rust-Infostealer, diesmal mit Fokus auf Browser-Zugangsdaten, Krypto-Wallets, Passwortmanager-Datenbanken, Cloud- und Entwickler-Secrets, API-Keys von KI-Diensten, SSH-Keys und Messenger-Tokens. Dazu kommt Remote Command Execution über den verschlüsselten Tor-Kanal und eine Wurmfunktion, die sich mit den erbeuteten SSH-Keys selbst auf weitere Systeme kopiert und dort ausführt. Der Clou: Weil diese Variante nicht mehr über npm läuft, greifen die Erkennungsskripte aus der Juni-Welle nicht.
Community-Tracking auf Reddit sprach am 31. Juli von über 200 betroffenen Paketen, darunter boringssl-git, icloudpd, windscribe-cli-v2-bin, stirling-pdf-desktop-bin, arduino-language-server-noclang-bin, pgadmin4-server, i915-sriov-dkms, rtk-git, warp-terminal-git, weather-display und astro-box. Bestätigt ist diese Liste nicht. Und genau das ist das Problem: Arch hat für diese Welle bis heute keine vollständige Liste betroffener Pakete veröffentlicht. Am 30. Juli schaltete Robin Candau für das DevOps-Team die Adoption ab, am 1. August folgte die Sperrung sämtlicher Pushes.
Nebenbei bemerkt: Es liegen immer noch rund 13'000 verwaiste Pakete im AUR. Das ist die Angriffsfläche, die weiterhin dort liegt und auf den nächsten Adoptionsversuch wartet.
Warum ich abrate, und zwar generell
Meine Empfehlung lautet ab sofort: Finger weg vom AUR. Nicht "sei vorsichtig", nicht "prüfe die PKGBUILDs", sondern schlicht: nutze es nicht mehr, wenn es irgendeine Alternative gibt. Und es gibt praktisch immer eine. Dasselbe gilt sinngemäss für PPAs und Copr-Repos, auch wenn dort bisher niemand in dieser Grössenordnung zugeschlagen hat. Der strukturelle Fehler ist derselbe, das AUR ist nur das erste Beispiel, an dem man ihn in aller Deutlichkeit sehen kann.
Das klingt hart, ergibt sich aber direkt aus der Bedrohungslage. Ein AUR-Paket führt bei der Installation fremden Code auf deinem System aus, mit deinen Rechten und über die Install-Skripte faktisch mit Root. Es gibt keine Sandbox, keine Signatur, keine Prüfstelle, keinen Review-Prozess und keine Garantie, dass der Maintainer von gestern derselbe ist wie der von heute. Der einzige Schutz, der je existiert hat, war der aufmerksame Nutzer. Und dieser Schutz hat gerade in aller Öffentlichkeit versagt.
Wenn du einmal ein infiziertes Paket mit Root-Rechten gebaut hast, reicht ein pacman -Rns nicht mehr. Bei einem eBPF-Rootkit reicht auch ein sorgfältiges Aufräumen nicht. Die ehrliche Empfehlung nach einer Kompromittierung lautet: alle Zugangsdaten rotieren und das System neu aufsetzen. Das ist ein Aufwand, den kein Feature der Welt rechtfertigt, schon gar nicht der Komfort, einen Nightly-Build ohne Umweg installieren zu können.
Die Verantwortung liegt bei Arch, nicht bei dir
Hier wird es unbequem, und hier widerspreche ich einem grossen Teil der Community. In jedem Forenthread zu diesen Vorfällen steht innerhalb von zehn Minuten der Satz: Wer PKGBUILDs nicht liest, ist selber schuld. Das AUR sei nun mal unsupported, das stehe schliesslich im Wiki, RTFM.
Dieses Argument ist aus einem einzigen Grund nicht haltbar: Es funktioniert nicht einmal für die Profis. Die Juni-Welle wurde nicht von einem Nutzer beim Lesen des PKGBUILDs entdeckt, sondern von Sicherheitsfirmen, nachdem über 1500 Pakete bereits kompromittiert waren. Die zweite Welle fand ein erfahrener Arch-Entwickler, und die obfuskierte Bun-Variante entdeckte Nicolas Boichat mit einem lokalen KI-Modell, weil sie von Auge eben nicht mehr auffiel. Die dritte Welle bemerkte man erst, als sie schon lief, und eine vollständige Liste der betroffenen Pakete gibt es bis heute nicht.
Wenn Leute, die diese Build-Skripte täglich lesen, mit Werkzeugen, Erfahrung und Motivation ausgerüstet sind und trotzdem Tage brauchen, um eine Kampagne dieser Grössenordnung zu erkennen, dann ist die Erwartung an einen normalen Nutzer, das nebenbei um 23 Uhr im paru-Diff zu leisten, schlicht lächerlich. Sie ist nicht anspruchsvoll, sie ist unehrlich.
Dazu kommt: Ein PKGBUILD zu lesen bringt gar nichts, wenn der eigentliche Schadcode nicht darin steht. Das PKGBUILD ruft npm install auf, und das npm-Paket enthält die Nutzlast. Oder es klont ein Git-Repository, dessen Inhalt sich nach deinem Review ändert. Oder es lädt einen Tarball, dessen Prüfsumme der Maintainer selbst gesetzt hat. Das Skript kann vollkommen sauber aussehen und trotzdem eine Kette in Gang setzen, die auf einem Onion-Server endet. "Lies das PKGBUILD" ist eine Sicherheitsmassnahme aus einer Zeit, in der Angreifer ihr curl | bash noch in die erste Zeile geschrieben haben.
Ein Verteilsystem, dessen einziger Schutzmechanismus die Aufmerksamkeit von Freiwilligen ist, hat kein Nutzerproblem. Es hat ein Designproblem. Und Designprobleme verantwortet, wer das Design gebaut hat und betreibt. Die Freiwilligen, die jetzt aufräumen, trifft keine Schuld, im Gegenteil. Aber das Projekt als Ganzes hat jahrelang ein bekanntes strukturelles Risiko mit einem Wiki-Hinweis abgedeckt statt mit Technik. Es ist bezeichnend, dass KDE Linux das AUR aus Sicherheitsgründen gar nicht erst in seine Builds aufgenommen hat.
Jede Alternative ist heute die bessere Wahl
Damit meine ich wirklich jede. Auch die, über die wir uns sonst gerne streiten.
Flatpak ist der offensichtlichste Ersatz. Die Anwendung läuft in einem Sandbox-Kontext, die Berechtigungen sind sichtbar und mit Flatseal anpassbar, das Paket ist signiert und auf Flathub gibt es Verified-Badges für Uploads direkt vom Upstream-Projekt. Ja, die Sandbox ist nicht perfekt, und ja, ein Paket mit --filesystem=home ist deutlich weniger isoliert, als der Marketingtext suggeriert. Trotzdem: Ein unvollkommener Käfig ist unendlich viel besser als gar keiner.
Snap mag man wegen des zentralen Stores und der Canonical-Abhängigkeit kritisieren, und ich habe das selber getan. Aber genau dieser zentrale Store bedeutet eben auch: ein Betreiber mit Namen, mit Prozessen und mit Haftung, statt eines Systems, in dem jeder anonyme Account jedes verwaiste Paket adoptieren kann. AppArmor-Confinement kommt gratis dazu.
AppImage hat keine Sandbox und keine zentrale Instanz, ist also sicherheitstechnisch das schwächste Glied dieser Liste. Aber selbst hier gilt: Die Datei kommt in aller Regel direkt vom Upstream-Projekt, sie wird beim Start als normaler Nutzer ausgeführt und es gibt keinen Build-Prozess, der ungefragt mit Root-Rechten Skripte ausführt. Wer AppImages mit Firejail oder in einer Distrobox startet, hat ein Setup, das dem AUR in jeder Hinsicht überlegen ist.
Distrobox ist für mich die eleganteste Antwort auf das eigentliche Problem, nämlich fehlende Pakete. Du brauchst ein Programm, das es nur als DEB gibt? Dann nimm einen Debian- oder Ubuntu-Container, installiere es dort aus dem offiziellen, signierten und tatsächlich gepflegten Repository und exportiere die Anwendung ins Host-System. Du bekommst offizielle Pakete statt Community-Build-Skripte und obendrein eine Isolationsschicht. Das ist in fast jeder Hinsicht der bessere Deal.
Selber kompilieren klingt paradox als Sicherheitsempfehlung, ist aber genau der Punkt: Wenn du den Quellcode direkt vom Upstream-Projekt holst, ein Release-Tag mit Signatur oder zumindest einem fixen Commit-Hash verwendest und in einem Container ohne Root baust, dann kennst du deine Vertrauenskette. Beim AUR vertraust du einem anonymen Dritten, der zwischen dich und den Upstream getreten ist, ohne dass du je gefragt worden wärst.
Und der wichtigste Punkt zum Schluss dieser Liste: In sehr vielen Fällen brauchst du das AUR gar nicht. Die offiziellen Arch-Repositories sind nicht betroffen und bleiben ausgezeichnet. Prüf zuerst dort, dann Flathub/Snap, dann Distrobox. Was dann noch übrig bleibt, ist meist Software, die du auch überleben kannst.
Was das AUR bräuchte, um eine Zukunft zu haben
Ich will nicht nur meckern. Ich sehe für das AUR durchaus eine Zukunft, aber nur unter einer Bedingung: Sicherheit muss auf Systemebene passieren, nicht auf Aufmerksamkeitsebene. Solange der Schutzmechanismus "der Nutzer schaut halt hin" heisst, wird die nächste Welle kommen. Konkret sehe ich diese Baustellen:
Bauen in einer Sandbox ohne freien Netzwerkzugriff. Der Build läuft in einem Container per systemd-nspawn oder bubblewrap, ohne Root und ohne offenes Netz. Erlaubt sind ausschliesslich die Quellen, die in source=() deklariert und per Prüfsumme fixiert sind. Ein PKGBUILD, das mitten im Build npm install oder curl aufruft, würde damit schlicht scheitern statt Schadcode nachzuladen. Arch hat mit devtools und Clean-Chroot-Builds die halbe Technik dafür bereits im Haus, sie ist nur nicht verbindlich.
Install-Skripte massiv einschränken. Die .install-Dateien laufen als Root und sind derzeit vollwertige Bash-Skripte. Sie müssten auf deklarative Aktionen reduziert werden: Systembenutzer anlegen, Caches aktualisieren, Dienste registrieren. Alles andere gehört verboten oder wenigstens beim Push automatisch markiert.
Pflicht-Diff mit Zwang zur Bestätigung. paru und yay können Diffs anzeigen, aber die Konfiguration ist optional und wird routiniert weggeklickt. Ein Update, bei dem sich der Maintainer geändert hat oder bei dem build(), prepare() oder das Install-Skript angefasst wurden, dürfte nicht ohne explizite, separate Bestätigung durchlaufen.
Adoption mit Quarantäne und Cooldown. Wechselt ein Paket den Besitzer, gehört es für 14 Tage in einen Sperrzustand, in dem Commits zwar möglich, aber nicht auslieferbar sind. Zusätzlich müsste der Paketmanager beim ersten Update nach einem Maintainer-Wechsel eine unübersehbare Warnung anzeigen. Genau dieses Zeitfenster hätte die Juni- und die Juli-Welle grösstenteils entschärft.
Automatisches Scanning beim Push. Kein Ersatz für Review, aber eine billige erste Hürde: Muster wie curl | bash, base64 -d, eval auf heruntergeladenen Daten, npm install oder bun install in Build- und Install-Phasen liessen sich beim Push flaggen und in eine manuelle Prüfschlange schicken. Dass in dieser Krise ein einzelner Entwickler mit einem lokalen KI-Modell mehr gefunden hat als die gesamte Plattform, ist ein vernichtendes Urteil über den Status quo.
Verpflichtende Zwei-Faktor-Authentisierung für Maintainer-Accounts und ein Verifikationsverfahren für Accounts, die Pakete mit hoher Nutzerzahl übernehmen wollen. Wenn ein Angreifer sich als bekannter Maintainer ausgeben kann, ist die Identitätsschicht kaputt.
Aufräumen bei verwaisten Paketen. 13'000 herrenlose Pakete sind kein Archiv, das ist ein Munitionsdepot. Wer nach 12 Monaten ohne Maintainer keinen Übernehmer findet, gehört archiviert und aus dem normalen Suchindex genommen, statt weiterhin als adoptierbare Reputationshülle bereitzuliegen.
Quellen auf Commit-Hashes pinnen statt auf Branches. Ein -git-Paket, das einfach HEAD von master zieht, ist per Definition nicht reviewbar, weil der Inhalt zwischen deinem Blick ins PKGBUILD und dem Build ein anderer sein kann.
Provenance und reproduzierbare Builds. Signierte Commits, nachvollziehbare Herkunft, im Idealfall verifizierbare Rebuilds über eine Infrastruktur wie rebuilderd. Das ist die einzige Antwort, die langfristig trägt, weil sie Vertrauen von Personen auf überprüfbare Artefakte verschiebt.
Fazit
Das AUR war eine grossartige Idee für eine kleinere, ruhigere Welt. In einer Welt, in der Angreifer Lieferketten industriell abernten, ist ein Repository ohne Sandbox, ohne Signaturen, ohne Review und mit offener Adoption verwaister Pakete kein Feature mehr, sondern eine offene Tür.
Bis Arch Sicherheit auf Systemebene einzieht, lautet meine Empfehlung ohne Einschränkung: Nutze die offiziellen Repositories, nimm Flatpak/Snap, nimm Distrobox, nimm im Zweifel sogar ein AppImage, oder kompiliere selber aus einer Quelle, der du wirklich vertraust. Und wenn dir jemand sagt, du müsstest halt einfach die PKGBUILDs lesen, dann zeig ihm die letzten sieben Wochen.
