Die Kampagne mit dem Namen „Atomic Arch“ kompromittierte mehr als 400 Community-Pakete – mit verheerenden Folgen für Entwickler.
Die Attacke zielte auf verwaiste AUR-Pakete ab, die nicht mehr von ihren ursprünglichen Autoren gepflegt werden. Die Angreifer übernahmen die Kontrolle und schleusten Schadcode in die PKGBUILD-Skripte ein – jene Anweisungen, die zur Installation von Software auf Arch Linux verwendet werden.
So funktionierte der Angriff
Anzeige: Wer in den letzten Tagen AUR-Pakete installiert oder aktualisiert hat, sollte sein System jetzt gründlich prüfen – die Atomic-Arch-Malware nutzt eBPF-Rootkits und bleibt sonst unsichtbar. Dieser Report liefert eine Erkennungs-Checkliste und die wichtigsten Bereinigungs-Schritte. Jetzt kostenlosen Sicherheits-Report anfordern
Am 11. Juni 2026 veröffentlichte die Cybersicherheitsfirma Sonatype ihre Analyse der „Atomic Arch“-Kampagne. Demnach manipulierten die Angreifer die Build-Skripte so, dass diese beim Kompilieren automatisch schadhafte npm-Pakete nachluden – konkret die Pakete „atomic-lockfile“ und „js-digest“.
Die offiziellen Arch-Linux-Repositories blieben von dem Angriff verschont. Dennoch sind rund 408 Pakete im AUR betroffen – eine beachtliche Zahl für ein Repository, das auf Vertrauen und Community-Beiträgen basiert.
eBPF-Rootkit: Unsichtbare Gefahr für Entwickler
Die technische Analyse des Schadpakets „atomic-lockfile“ (Version 1.4.2) offenbart eine hochentwickelte Malware. Der ELF64-Credential-Stealer nutzte eBPF-Programme (Extended Berkeley Packet Filter), um seine Prozesse, Dateien und Netzwerkaktivitäten vor dem Betriebssystem zu verstecken.
Das Ziel: sensible Daten aus Entwicklerumgebungen abzugreifen. Die Diebstahlliste liest sich wie ein Albtraum für jeden Entwickler:
- Browser-Zugangsdaten und Cookies
- SSH-Schlüssel und Shell-Historien
- Umgebungsvariablen und Docker-Konfigurationen
- Access-Tokens für GitHub, npm und HashiCorp Vault
- Daten aus Kommunikationsplattformen wie Slack, Discord, Microsoft Teams und Telegram
- Kryptowährungs-Wallet-Informationen
Die Sicherheitsforscher bewerteten die Schwere des Angriffs mit einem CVSS-Score von 8,7 – die zweithöchste Risikostufe. Die gestohlenen Daten wurden über HTTP-Uploads an temporäre Speicherdienste und einen Command-and-Control-Server (C2) übertragen, der als Onion-Dienst im Tor-Netzwerk operierte.
Reaktion der Community und Schutzmaßnahmen
Das Arch-Linux-Sicherheitsteam reagierte umgehend: Die bösartigen Commits wurden rückgängig gemacht, die Konten der Angreifer gesperrt. Doch die Diskussion um die Sicherheitsarchitektur des AUR ist neu entfacht.
Das AUR lebt von nutzergenerierten Inhalten – ein Modell, das Sicherheitsexperten seit Jahren kritisch sehen. Das Arch-Linux-Team betont zwar, dass AUR-Pakete nicht offiziell unterstützt werden und vor der Installation geprüft werden sollten. Doch in der Praxis installieren viele Nutzer die Pakete blind.
In der Community mehren sich nun Stimmen, die automatische Überprüfungsmechanismen oder Quarantänezeiten für neu übernommene Pakete fordern. Erste Community-Skripte helfen bereits dabei, zu prüfen, ob eigene Installationen betroffen sind.
Anzeige: Entwickler, die SSH-Schlüssel, API-Tokens oder Cloud-Zugänge in ihren Dev-Umgebungen nutzen, sind das Hauptziel der Atomic-Arch-Attacke. Einmal gestohlen, können diese Daten noch lange für weitere Angriffe genutzt werden. Erfahren Sie in diesem Report, wie Sie Ihre Systeme absichern und gestohlene Credentials sofort rotieren. Sicherheits-Report jetzt herunterladen
Was betroffene Entwickler jetzt tun sollten
Experten warnen: Die Malware nutzte systemd-Dienste zur Persistenz – eine gründliche Systemüberprüfung ist daher unerlässlich. Wer in den letzten Tagen AUR-Pakete installiert oder aktualisiert hat, sollte seine Systeme genau unter die Lupe nehmen.
Die Liste der kompromittierten Pakete kursiert inzwischen in der Community. Betroffene Entwickler sollten nicht nur die Pakete entfernen, sondern auch alle Zugangsdaten zurücksetzen – insbesondere SSH-Schlüssel, API-Tokens und Cloud-Zugänge. Denn einmal gestohlen, können diese Daten noch lange für weitere Angriffe genutzt werden.
