Wer heute Software aus einem Community-Repository installiert, vertraut nicht mehr nur dem offiziellen Distributor, sondern oft einem einzelnen GitHub-Account, einer Mail-Adresse und einer Maintainer-Historie, die sich mit wenigen Klicks fälschen lässt. Der Arch Linux User Repository (AUR) gilt unter Power-Usern und Entwicklern als unverzichtbarer Tresor für proprietäre Tools, Beta-Versionen und Nischenpakete. Genau diese Vertrauensbasis ist im Juni 2026 ins Wanken geraten. Ein koordinierter Angriff zeigt, wie schnell aus einer vermeintlich harmlosen Paket-Adoption ein globaler Supply-Chain-Befall werden kann, der bis in den Linux-Kernel reicht.

Konkret wurden laut dem Bericht des Open-Source-Intelligence-Netzwerks IFIN mindestens 408 AUR-Pakete kompromittiert. Der Angreifer nutzte verwaiste Pakete, täuschte als neuer Maintainer vertraute Namen vor und schleuste über modifizierte PKGBUILD-Skripte die npm-Pakete atomic-lockfile, js-digest und nextfile-js ein. Die Resultate reichten von einem Credential-Stealer bis zu einem optionalen eBPF-Rootkit, das lokale Prozesse, Dateien und Netzwerkinterfaces vor dem System verbergen kann. Arch Linux reagierte mit der vorübergehenden Deaktivierung der AUR-Registrierung und einem Aufruf der Community, verdächtige Pakete zu melden.

Der Angriff im Überblick

Wie der AUR funktioniert – und warum er anfällig ist

Der Arch User Repository ist kein klassisches Software-Repository mit zentral geprüften Binärpaketen, sondern eine Sammlung von PKGBUILD-Dateien. Ein PKGBUILD ist ein Bash-Skript, das definiert, von wo Quellcode oder Binärdateien bezogen werden, wie sie gebaut und schließlich installiert werden. Nutzer laden diese Skripte herunter, prüfen sie idealerweise manuell und führen sie mit makepkg aus. In der Praxis springt jedoch oft ein AUR-Helper wie yay oder paru ein, der die Prüfung auf wenige Zeilen im Terminal reduziert.

Das AUR erlaubt es jedem registrierten Account, als neuer Maintainer ein verwaistes Paket zu übernehmen. Verwaiste Pakete sind solche, deren bisheriger Betreuer nicht mehr aktiv ist. Dieses Adoptionsmodell ist der Grundstein der Community-Vielfalt, aber auch der größte strukturelle Schwachpunkt. Ein Angreifer muss nichts weiter tun, als einen vertrauenswürdigen klingenden Nutzernamen zu wählen, die Historie des Pakets zu studieren und dann einen scheinbar harmlosen Update-Commit zu pushen. Für den Endanwender sieht das wie ein legitimes Maintenance-Update aus.

Die offizielle Arch-Wiki erklärt das Prinzip des AUR als community-maintained und warnt explizit davor, dass Inhalte nicht im selben Maße geprüft werden wie die offiziellen Arch-Repositories. Arch Wiki: Arch User Repository.

Die drei Wellen des Angriffs

Der Vorfall entwickelte sich in mehreren Stufen, die IFIN und Sicherheitsforscher dokumentiert haben. Eine erste Welle infizierte ursprünglich betroffene Pakete mit einem preinstall-Script, das npm aufruft und das Paket atomic-lockfile installiert. Eine zweite Welle nutzte bun add, um die bösartige Abhängigkeit js-digest einzuschleusen. Eine dritte Welle, am 14. Juni 2026 beobachtet, verschleierte den bun add-Befehl weiter und verwies auf die Abhängigkeit nextfile-js, die denselben preinstall-Mechanismus enthielt.

Diese Stufen zeigen, dass der Angreifer aktiv auf Gegenmaßnahmen reagierte. Sobald die erste Malware bekannt wurde, wechselte er zu alternativen Paketmanagern und verschleierten Installationsbefehlen. IFIN: 400+ AUR Packages Compromised.

Technische Analyse der Schadsoftware

Die Rolle von atomic-lockfile

Im Mittelpunkt der ersten Angriffswelle steht das npm-Paket atomic-lockfile. Es wurde vom Nutzer herbsobering veröffentlicht und zeigte laut Socket.dev 134 Downloads, bevor die Plattform es als bösartig kennzeichnete. Sobald ein infiziertes AUR-Paket installiert wurde, führte das preinstall-Script die Installation von atomic-lockfile aus. Innerhalb des Pakets befand sich eine Linux-ELF-Datei namens deps, die von unabhängigen Sicherheitsforschern analysiert wurde.

Der Sicherheitsforscher Whanos identifizierte deps als Credential-Stealer mit optionalem Rootkit. Optional bedeutet hier, dass die eBPF-Komponente nur auf Systemen mit entsprechenden Rechten aktiviert wurde. Ist das der Fall, kann der Angreifer im Kernel-Kontext laufen und damit klassische Detektionsmechanismen auf User-Ebene unterlaufen. Socket.dev: atomic-lockfile.

eBPF als Rootkit-Technologie

Extended Berkeley Packet Filter, kurz eBPF, ist eine Linux-Technologie, mit der sich Programme sicher im Kernel-Kontext ausführen lassen. Ursprünglich für Netzwerk-Tracing entwickelt, wird eBPF heute für Observability, Performance-Monitoring und Firewall-Regeln genutzt. Im falschen Kontext wird aus einem nützlichen Werkzeug jedoch eine mächtige Rootkit-Plattform.

Die im AUR-Angriff gefundene eBPF-Komponente nutzt Map-Strukturen, um Prozesse, Dateien und Netzwerkinterfaces zu verstecken. Administratoren können verdächtige Maps mit dem Befehl bpftool map list aufspüren. Typische Indikatoren sind die Map-Namen hidden_pids, hidden_names und hidden_inodes. Sobald diese Maps aktiv sind, sehen selbst Tools wie ps, ls oder netstat nicht mehr das, was der Kernel tatsächlich verwaltet. Der Schadcode verschwindet buchstäblich vor den Augen des Betriebssystems.

Diese Technik ist nicht neu, aber ihre Kombination mit einem Supply-Chain-Angriff über ein Community-Repository ist ungewöhnlich und besonders gefährlich. Der Nutzer installiert ein vermeintlich legitimes Tool, aktiviert dabei unbemerkt Kernel-Code und öffnet anschließend die Tür für weitere Manipulationen. Wer tiefer in Linux-Sicherheit einsteigen möchte, findet auf itratgeber2024.de ergänzende Hintergründe.

Infostealer-Funktionalität und Datenexfiltration

Neben der eBPF-Komponente verfügt die ELF-Payload über klassische Infostealer-Funktionen. Laut der Analyse durch Sonatype kann die Binärdatei sensible Daten archivieren, mehrteilige Dateien verarbeiten und per HTTP hochladen. Das ist das Standard-Repertoire für Datenexfiltration: lokale Credentials, SSH-Schlüssel, Browser-Daten, Krypto-Wallets und Zugangsdaten für Entwicklungsumgebungen werden gesammelt und an externe Server übertragen.

Für Entwickler und DevOps-Teams ist das besonders brisant. Arch-Linux-Systeme werden häufig auf Workstations, Build-Servern und in Container-Umgebungen eingesetzt. Ein einziges kompromittiertes Paket auf einem Build-Agent kann dazu führen, dass CI/CD-Secrets, API-Keys oder Container-Registry-Tokens abgezogen werden. Die Konsequenzen reichen dann weit über das einzelne System hinaus und betreffen die gesamte Software-Supply-Chain.

Reaktionen der Community und der Industrie

Arch Linux und AUR-Maintainer

Arch-Linux-Maintainer Jonathan Grotelüschen wandte sich direkt an die Community und rief dazu auf, verdächtige Pakete zu melden. Parallel arbeiteten AUR-Maintainer daran, die bösartigen Commits zu identifizieren und die betreffenden Accounts zu sperren. Als kurzfristige Schutzmaßnahme wurde die AUR-Registrierung vorübergehend deaktiviert, um weitere Adoptionswellen zu stoppen. AUR-General Mailing List.

Sonatype und Socket.dev

Das Supply-Chain-Management-Unternehmen Sonatype veröffentlichte einen eigenen Bericht über die Kampagne. Die Forscher konnten nachweisen, dass der Angreifer mindestens 20 verwaiste AUR-Pakete übernommen und durch modifizierte PKGBUILDs Schadcode verteilt hat. Socket.dev ergänzte die Analyse durch die Veröffentlichung des npm-Pakets atomic-lockfile mit einem Vertrauens-Score, der den Code als hochriskant einstufte.

Verbindung zu GitHub und Container-Images

Die Recherche führte auch zu einem GitHub-Container-Image unter dem Account fardewoak/nodejs-argo. Das Image herbsobering430 scheint laut IFIN ein Reverse-Shell- oder Proxy-Tool zu sein und verknüpft den npm-Nutzer herbsobering mit weiterer Infrastruktur des Angreifers. Obwohl noch keine direkte Verbindung zum AUR-Angriff bewiesen ist, deutet die konsistente Namensgebung auf ein gemeinsames Betätigungsfeld hin. GitHub: herbsobering430 Container.

Der AUR im Vergleich zu anderen Ökosystemen

Community-Repositories versus kuratierte Stores

Nicht jeder Software-Marktplatz ist gleich riskant. Debian- und Fedora-Repositories durchlaufen einen formellen Review-Prozess, bei dem Pakete von Maintainern geprüft und signiert werden. Der Microsoft Store, Apples App Store und Snapcraft setzen auf zentralisierte Scans und Signatur-Checks. Der AUR hingegen basiert auf Selbstverwaltung. Jeder kann beitragen, jeder kann adoptieren, und die Prüfung erfolgt erst beim Endnutzer.

Dieses Modell ist nicht per se falsch. Es ermöglicht Innovation und Nischenlösungen, die in kuratierten Stores nie landen würden. Allerdings setzt es voraus, dass der Nutzer die Kompetenz und die Zeit hat, jedes PKGBUILD zu lesen. Genau hier liegt die Schwachstelle: AUR-Helper automatisieren die Installation so stark, dass der eigentliche Review-Schritt zur reinen Formalität wird. Wer einmal täglich Dutzende Updates einspielt, wird keine Zeile der Build-Skripte mehr lesen.

Was Nutzer regelmäßig übersehen

Ein typischer AUR-Nutzer startet seinen Helper, sieht eine Liste von Updates, tippt „Y“ und wartet auf das Ende der Kompilierung. Dabei werden Warnhinweise zu neuen Maintainer-Namen, geänderten Abhängigkeiten oder zusätzlichen Download-Quellen oft ignoriert. Der Juni-2026-Vorfall nutzte genau dieses Verhalten aus. Der bösartige Code lag nicht im eigentlichen Paket, sondern in einer zusätzlichen Abhängigkeit, die während der Installation nachgeladen wurde.

Besonders problematisch ist die Kombination aus npm und PKGBUILD. Viele Nutzer erwarten, dass ein AUR-Paket nur Software aus dem Arch-Ökosystem nachlädt. Wenn das Skript jedoch npm oder bun aufruft, um JavaScript-Abhängigkeiten zu installieren, entsteht eine transitive Vertrauenskette, die kaum noch nachvollziehbar ist. Der Angriff zeigt, dass selbst ein scheinbar kleiner zusätzlicher Schritt im Installationsprozess die Angriffsfläche massiv vergrößern kann.

Warum dieser Vorfall besonders lehrreich ist

Vertrauen ist kein Sicherheitsmechanismus

Der AUR-Angriff ist kein klassischer Exploit, der eine Software-Schwachstelle ausnutzt. Er nutzt das Vertrauensmodell der Community aus. Der Angreifer brauchte keine Zero-Day-Lücke im Kernel, sondern nur die Berechtigung, verwaiste Pakete zu übernehmen und glaubwürdige Maintainer-Namen zu spoofen. Sobald das Paket einmal installiert ist, laufen alle weiteren Aktionen mit den Rechten des Nutzers – und im Falle des eBPF-Rootkits mit Kernel-Rechten.

Diese Taktik erinnert an andere jüngere Supply-Chain-Angriffe über Build-Pipelines, bei denen vermeintlich interne Artefakte zum Trojaner werden. Der Unterschied liegt nur im Einstiegstor: statt eines kompromittierten NPM-Accounts nutzt der Angreifer hier die offene Struktur des AUR.

eBPF wird zur Doppelschneide

eBPF ist längst kein Nischenthema mehr. Cloud-native Sicherheitsstacks wie Falco, Cilium und Tetragon setzen auf eBPF, um Container und Netzwerkverkehr zu überwachen. Gleichzeitig wird eBPF zunehmend von Angreifern als Rootkit-Grundlage genutzt, weil es privilegierten Code im Kernel ausführen kann, ohne Kernel-Module laden zu müssen. Für Defender bedeutet das, dass sie nicht nur Prozesse und Dateien prüfen müssen, sondern auch geladene eBPF-Programme und Maps.

Orphaned Packages als systemische Angriffsfläche

Die Verwendung verwaister Pakete ist keine Ausnahme, sondern ein systemisches Problem. Viele populäre AUR-Pakete haben im Laufe der Jahre mehrere Maintainer gewechselt. Jeder Wechsel ist eine Gelegenheit für Angreifer. Nutzer, die AUR-Helper im Batch-Modus betreiben und Updates automatisch anwenden, merken solche Besitzerwechsel oft nicht. Ein einfacher Hinweis wie „Package X was adopted by new maintainer Y“ wird in der Flut der Terminal-Ausgabe leicht übersehen.

Langfristige Gefahren für Unternehmen

Unternehmen setzen Arch Linux häufig auf Entwickler-Workstations, in Penetration-Testing-Umgebungen und in Container-Build-Pipelines ein. Der Vorfall macht deutlich, dass diese Systeme nicht als isolierte Einzelplätze betrachtet werden dürfen. Ein kompromittiertes Build-Image kann Schadcode in produktive Container, Installer oder Git-Repositories einschleusen. Selbst wenn der ursprüngliche Befall nur ein Credential-Stealer war, kann die gezielte Weitergabe von API-Keys über Wochen zu einem sekundären Datenleck führen, das erst Monate später auffällt.

Die IT-Sicherheit vieler Unternehmen konzentriert sich auf zentrale Server und Endgeräte mit Windows. Linux-Workstations von Entwicklern erhalten oft weniger Aufmerksamkeit, obwohl sie Zugriff auf Quellcode, Produktionskonfigurationen und Cloud-Credentials haben. Der AUR-Angriff ist ein weiterer Beleg dafür, dass der Schutz der Entwickler-Toolchain mindestens so wichtig ist wie der Schutz der produktiven Infrastruktur.

Handlungsempfehlungen für Administratoren und Entwickler

Betroffene und potenziell betroffene Systeme sollten sofort überprüft werden. Die IFIN hat ein Skript veröffentlicht, mit dem Arch-Nutzer ihre installierten Pakete gegen die bekannte Liste betroffener Pakete prüfen können. Das ursprüngliche Skript wurde inzwischen durch eine aktualisierte Version ersetzt, die auf GitHub verfügbar ist. Administratoren sollten stets die aktuellste Version verwenden.

• Prüfen Sie installierte AUR-Pakete gegen die öffentlich gemachte Liste kompromittierter Pakete.
• Suchen Sie nach der Datei deps und dem SHA256-Hash 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316.
• Führen Sie bpftool map list aus und achten Sie auf Maps mit den Namen hidden_pids, hidden_names und hidden_inodes.
• Rotieren Sie alle Credentials, die auf dem System gespeichert waren, einschließlich SSH-Keys, API-Tokens und Browser-Passwörter.
• Blockieren Sie ausgehenden Tor-Verkehr im Netzwerk, sofern dies betrieblich möglich ist.
• Erwägen Sie eine Neuinstallation, falls ein Rootkit im Kernel-Bereich aktiv war.

Für Unternehmen ergibt sich daraus eine klare Strategie: AUR-Pakete sollten auf produktiven Systemen grundsätzlich vermieden oder zumindest einem vieraugigen Review unterzogen werden. CI/CD-Build-Server, die Arch oder Arch-basierte Container nutzen, müssen besonders geschützt werden, da hier ein Kompromiss die gesamte Software-Lieferkette gefährdet. Der jüngste FortiOS-Zero-Day-Fall hat gezeigt, wie schnell aus einer einzelnen Lücke ein flächendeckendes Sicherheitsproblem wird – das AUR-Desaster folgt einer ähnlichen Logik, nur auf der Software-Verteilungsebene.

Fazit und Ausblick

Der Angriff auf den Arch Linux User Repository ist mehr als ein temporärer Vorfall. Er ist ein warnendes Beispiel dafür, wie offene, community-getriebene Infrastrukturen von organisierten Akteuren instrumentalisiert werden können, ohne dass dafür klassische Sicherheitslücken nötig sind. Die Kombination aus verwaisten Paketen, gespooften Maintainer-Identitäten, npm-Abhängigkeiten und einem eBPF-Rootkit zeigt, dass moderne Supply-Chain-Angriffe gezielt die Grenzen zwischen vertrauenswürdiger Community und bösartiger Infrastruktur verwischen.

Für die Arch-Community steht nun die Frage im Raum, ob das Adoptionsmodell des AUR ohne zusätzliche Sicherheitsmechanismen zeitgemäß ist. Mögliche Maßnahmen reichen von einer längeren Wartezeit bei Maintainer-Wechseln über Reputations-Scores bis hin zu einer stärkeren Integration automatisierter Malware-Scans. Bis diese existieren, bleibt die Verantwortung beim einzelnen Nutzer: jedes PKGBILD vor der Installation lesen, unbekannte Maintainer recherchieren und Systeme regelmäßig auf Anzeichen eines Kompromisses prüfen.

Tags: AUR, Arch Linux, eBPF, Rootkit, Supply Chain Security, Infostealer, atomic-lockfile