Arch AUR: Infostealer in Hunderten Community-Paketen entdeckt
Eine Supply-Chain-Kampagne namens Atomic Arch traf verwaiste Pakete im Arch User Repository. Betroffene Systeme sollten als kompromittiert geprüft werden.
Im Arch User Repository (AUR) sind in den vergangenen Tagen zahlreiche Community-Pakete durch eine Supply-Chain-Kampagne missbraucht worden. Sicherheitsforscher von Sonatype führen die Kampagne unter dem Namen „Atomic Arch“ und beschreiben manipulierte Paketdefinitionen, die bei der Installation zusätzliche Schadsoftware nachladen konnten. Betroffen waren nach aktuellem Stand vor allem verwaiste AUR-Pakete, also Projekte ohne aktive ursprüngliche Maintainer. Die offiziellen Arch-Linux-Repositories waren nach den vorliegenden Berichten nicht Teil der Kompromittierung.
Die Schwachstelle
Der Vorfall ist keine klassische Schwachstelle mit CVE, sondern ein Angriff auf das Vertrauensmodell des AUR. Nach Sonatype-Angaben übernahmen Angreifer legitime, aber verwaiste AUR-Projekte und änderten deren PKGBUILD- beziehungsweise Installationsanweisungen. Diese Änderungen sorgten dafür, dass während des Paketbaus ein schädliches npm-Paket namens atomic-lockfile installiert wurde. In einer zweiten Welle sollen zusätzlich Bun-basierte Installationspfade und weitere Pakete wie js-digest und lockfile-js aufgetaucht sein.
Die technische Analyse beschreibt einen nativen Linux-Payload mit Funktionen für Credential-Diebstahl, Tarnung, Anti-Debugging und mögliche Datenexfiltration. Genannt werden unter anderem Hinweise auf GitHub-Zugangsdaten, SSH-Artefakte, HashiCorp-Vault-Tokens, Browser-Cookie-Datenbanken sowie Daten aus Slack, Discord, Microsoft Teams und Telegram. Bei Ausführung mit ausreichenden Rechten kann die Malware demnach eBPF-Funktionen nutzen, um Prozesse, Dateien oder Netzwerkspuren zu verstecken. Damit ist die Bereinigung schwieriger als bei einem gewöhnlichen fehlerhaften Paket.
Bin ich betroffen?
Prüfen sollten vor allem Arch- und Arch-basierte Systeme, auf denen seit dem 11. Juni 2026 AUR-Pakete installiert oder aktualisiert wurden. Das betrifft insbesondere Entwicklerarbeitsplätze, Build-Systeme, Testumgebungen und Administratoren, die AUR-Helfer wie yay oder paru nutzen. Die Zahl der betroffenen Pakete ist dynamisch: BleepingComputer und The Hacker News berichten von mehr als 400 Paketen, während Sonatype in einem Update von einer möglichen Ausweitung auf etwa 1.500 Pakete über mehrere Wellen spricht. Diese Zahlen sollten vorsichtig gelesen werden, weil Maintainer und Community die Listen laufend bereinigen und ergänzen.
Ein Arch-Linux-Maintainer schrieb am 12. Juni in der öffentlichen AUR-Mailingliste, dass die bis dahin bekannten schädlichen Commits gelöscht worden seien, die veröffentlichte Liste aber viele und nicht zwingend alle betroffenen Pakete enthalte. Wer AUR-Pakete nutzt, sollte deshalb nicht allein auf einen Paketnamen vertrauen, sondern die zuletzt gebauten Pakete, lokale Build-Caches und Installationsskripte gegen aktuelle Indikatoren aus den Analysen prüfen.
Wie behebe ich das?
Betroffene Systeme sollten zunächst nicht als vertrauenswürdig weiterverwendet werden. Wurde ein bekannt kompromittiertes Paket gebaut oder installiert, reicht das Entfernen des AUR-Pakets nicht aus. Administratoren sollten nach Hinweisen auf atomic-lockfile, js-digest, verdächtige systemd-Dienste, unerwartete Dateien unter /var/lib/ und eBPF-Artefakte suchen. Ebenso wichtig ist die Prüfung von Build-Historie, Shell-Historien, Paket-Caches und ausgehenden Verbindungen.
Da die Malware ausdrücklich auf Entwickler- und Infrastrukturzugänge abzielt, sollten Zugangsdaten vorsorglich rotiert werden, wenn ein Treffer vorliegt. Dazu gehören SSH-Schlüssel, GitHub- und npm-Tokens, Vault-Zugänge, Docker- und Podman-Credentials, VPN-Profile, Cloud-Schlüssel sowie Sitzungen in Kommunikationsdiensten. Wenn der Payload mit Root-Rechten lief oder eBPF-Spuren gefunden werden, ist eine Neuinstallation aus vertrauenswürdigen Quellen die belastbarere Option als eine rein manuelle Bereinigung.
Was bedeutet das für Unternehmen?
Der Vorfall zeigt, dass Community-Repositories nicht wie geprüfte Hersteller-Repositories behandelt werden sollten. Für Unternehmen mit Arch-basierten Entwickler- oder Build-Systemen ist besonders relevant, dass der Angriff nicht auf neue, auffällige Paketnamen setzte. Stattdessen wurde bestehendes Vertrauen übernommen: verwaiste Pakete behielten Namen und Historie, während sich die Build-Anweisungen änderten.
Für IT-Teams ergibt sich daraus eine klare Konsequenz: AUR-Pakete gehören in ein kontrolliertes Risiko- und Freigabemodell. Dazu zählen Pinning, interne Spiegel oder Paketfreigaben, regelmäßige Prüfung von PKGBUILD- und .install-Dateien, Monitoring auf neue Maintainer sowie eine Trennung zwischen Entwicklerarbeitsplätzen und produktiven Geheimnissen. Besonders kritisch sind CI-Systeme, auf denen Paketbau und Secrets oft nahe beieinanderliegen. Dort sollten AUR-Installationen mindestens isoliert und ohne dauerhaft verfügbare Produktionszugänge erfolgen.
