400 AUR-Pakete mit Malware: Was der Arch-Linux-Angriff lehrt

6 Min. Lesezeit

Mehr als 400 Pakete im Arch User Repository trugen Mitte Juni 2026 Schadcode. Angreifer übernahmen verwaiste Projekte, bauten einen Infostealer und einen eBPF-Rootkit in die Build-Skripte ein und warteten, bis Nutzer sie installierten. Der Fall trifft formal Arch Linux. Das Muster dahinter betrifft jede Organisation, die Software aus offenen Paketquellen bezieht.

Das Wichtigste in Kürze

Verwaiste Pakete als Einfallstor: Die Angreifer adoptierten herrenlose AUR-Pakete über den regulären Übernahmeprozess und veränderten deren Build-Skripte. Über 400 Pakete waren laut Berichten betroffen.
Zwei Stufen Schaden: Die Skripte luden nachgelagerte Pakete, die einen in Rust geschriebenen Infostealer ausführten. Mit Root-Rechten lud die Schadsoftware zusätzlich einen eBPF-Rootkit, um sich zu verstecken.
Das Risiko ist übertragbar: Dasselbe Muster gilt für npm, PyPI und andere offene Quellen. Wer Abhängigkeiten ungeprüft in seine Pipeline lässt, hat dieselbe Lücke, ganz ohne Arch Linux.

Verwandt:API-Security: der blinde Fleck hinter jeder Integration / Geteilter Kernel als Lücke

Was im Arch User Repository passiert ist

Was ist ein Software-Supply-Chain-Angriff? Bei einem Supply-Chain-Angriff manipuliert ein Angreifer nicht das Zielsystem direkt, sondern eine Komponente, der das Ziel vertraut: eine Bibliothek, ein Paket, ein Build-Skript. Die Schadsoftware kommt über den regulären Update- oder Installationsweg, vorbei an Abwehrmaßnahmen, die nur den direkten Zugriff prüfen.

Das Arch User Repository, kurz AUR, ist eine von der Community gepflegte Sammlung von Bauanleitungen, nicht das offizielle Arch-Repository. Nutzer laden sogenannte PKGBUILD-Skripte, die Helfer wie yay oder paru beim Installieren ausführen. Genau diese Skripte waren das Ziel.

Nach Berichten von Sicherheitsmedien wie BleepingComputer und The Hacker News suchten sich die Angreifer verwaiste Pakete, also Projekte ohne aktiven Betreuer, und übernahmen sie über den regulären Adoptionsprozess des AUR. Dann veränderten sie die Build-Skripte so, dass beim Installieren nachgelagerte Schadpakete geladen wurden. Diese führten einen in Rust geschriebenen Infostealer aus, der Entwickler-Geheimnisse abgriff. Lief der Vorgang mit Root-Rechten, lud die Schadsoftware zusätzlich einen eBPF-Rootkit, um ihre Spuren im System zu verbergen. Den Berichten zufolge haben die Arch-Linux-Betreuer nach Bekanntwerden begonnen, die betroffenen Pakete zurückzusetzen und die verantwortlichen Konten zu sperren.

Warum das Muster jede Lieferkette trifft

Arch-spezifisch ist daran wenig. Das Risiko liegt im Prinzip offener Paketquellen. Ein verwaistes Paket, das jemand übernimmt, gibt es in npm, PyPI, Crates und jedem anderen offenen Ökosystem. Die Übernahme eines aufgegebenen Projekts ist in vielen dieser Quellen ein vorgesehener Mechanismus, der sich gegen die Gemeinschaft wenden lässt.

Für ein DACH-Unternehmen heißt das: Jede Abhängigkeit, die ein Entwickler oder eine Pipeline ungeprüft zieht, ist ein potenzieller Eintrittspunkt. Der Schaden bleibt dann nicht auf eine private Linux-Installation begrenzt. Er erreicht Build-Server, Entwickler-Maschinen und im schlimmsten Fall die Produktion. Ein Infostealer greift genau die Zugangsdaten ab, mit denen sich weitere Systeme öffnen lassen.

Was Sicherheitsteams jetzt konkret prüfen sollten

Die Gegenmaßnahmen sind bekannt und brauchen kein Spezialwerkzeug. Sie verlangen vor allem Disziplin in der Pipeline.

Was schützt

Abhängigkeiten auf feste Versionen pinnen
Neue oder neu übernommene Pakete prüfen
Builds ohne Root und in Isolation laufen lassen
Geheimnisse aus Build-Umgebungen heraushalten

Was trügt

Vertrauen allein auf den Paketnamen
Automatische Updates ohne Prüfung
Build-Skripte als Blackbox behandeln
Annahme, ein bekanntes Paket bleibe sicher

Hinzu kommt der organisatorische Teil. Wer eine Stückliste seiner Software pflegt, eine sogenannte Software Bill of Materials, kann nach einem Vorfall in Minuten beantworten, ob eine betroffene Komponente im eigenen Bestand steckt. Das ist auch der Punkt, an dem NIS2 ansetzt: Die Richtlinie verlangt von betroffenen Einrichtungen, Risiken in der Lieferkette aktiv zu steuern, nicht erst nach dem Vorfall.

Häufige Fragen

Sind auch die offiziellen Arch-Linux-Pakete betroffen?

Nach den vorliegenden Berichten betraf der Angriff das Arch User Repository, eine von der Community gepflegte Sammlung von Build-Skripten, nicht die offiziellen Arch-Repositories. AUR-Pakete werden lokal aus PKGBUILD-Skripten gebaut, was sie für diese Art der Manipulation anfällig macht.

Wie viele Pakete waren betroffen und wann?

Laut übereinstimmenden Berichten waren über 400 Pakete betroffen, der Vorfall wurde um den 11. Juni 2026 bekannt. Die Arch-Linux-Betreuer haben begonnen, die Schadpakete zurückzusetzen und die verantwortlichen Konten zu sperren.

Was hat die Schadsoftware konkret getan?

Die manipulierten Build-Skripte luden nachgelagerte Pakete, die einen in Rust geschriebenen Infostealer ausführten. Dieser griff Entwickler-Geheimnisse ab. Mit Root-Rechten lud die Schadsoftware zusätzlich einen eBPF-Rootkit, um sich im System zu verbergen.

Betrifft das auch Unternehmen, die kein Arch Linux einsetzen?

Ja, das Muster ist übertragbar. Verwaiste oder übernommene Pakete gibt es auch in npm, PyPI und anderen offenen Quellen. Jede Pipeline, die Abhängigkeiten ungeprüft zieht, trägt das gleiche Risiko, unabhängig vom Betriebssystem.

Welche Maßnahme bringt am schnellsten Schutz?

Abhängigkeiten auf feste, geprüfte Versionen zu pinnen und Builds isoliert sowie ohne Root-Rechte laufen zu lassen. Beides verhindert, dass ein still ausgetauschtes Paket automatisch und mit hohen Rechten ins eigene System gelangt.