Atomic Arch: 1.900 AUR-Pakete durch Supply-Chain-Angriff kapern lassen – Was jetzt zu tun ist

Die Kampagnenseite von SafeDep und von der Community konsolidierte Listen zählten schließlich 1.937 betroffene AUR-Paketnamen, was die massive Reichweite des Angriffs unterstreicht . Wichtig zu betonen: Die offiziellen Arch-Linux-Paketquellen (core, extra, community) waren davon nicht betroffen – es handelte sich ausschließlich um einen AUR-Vorfall .

Die Angriffsmethode: Wie ein vertrauensbasierter Workflow ausgehebelt wurde

Atomic Arch war kein Einbruch in die Infrastruktur von Arch. Stattdessen nutzten die Angreifer gezielt den Adoptions-Workflow für verwaiste Pakete im AUR aus, der es jedem Community-Mitglied erlaubt, die Betreuung verlassener Pakete zu übernehmen .

Der Angriff erfolgte in zwei getrennten Wellen, wobei die Täter ihre Vorgehensweise verfeinerten, um einer Entdeckung zu entgehen.

Welle 1: Der npm-Hook (11. Juni)

Die Angreifer übernahmen systematisch verwaiste Pakete. Sobald sie die Maintainer-Rechte innehatten, veränderten sie nicht den Quellcode der Software selbst – ein Schritt, der Prüfsummen ungültig gemacht und Alarm ausgelöst hätte. Stattdessen modifizierten sie die PKGBUILD-Build-Skripte, um schädliche npm-Abhängigkeiten einzuschleusen: atomic-lockfile (v1.4.2) und js-digest (v4.2.2) . Diese Pakete wurden so konfiguriert, dass sie beim makepkg-Prozess automatisch ausgeführt wurden. Um die bösartigen Aktivitäten weiter zu tarnen, wurde der Code in .install-Skripte eingebettet und mittels String-Aufteilung, gemischter Anführungszeichen und hexadezimaler Escape-Sequenzen verschleiert .

Welle 2: Der Wechsel zu Bun (12. Juni)

Nur einen Tag später tauchte eine zweite Welle auf. Diesmal ersetzten die Angreifer den npm-Installationspfad durch einen Bun-basierten Installationsprozess und verwendeten ein anderes schädliches Paket namens lockfile-js (v1.4.2) . Dieser Wechsel erschwerte die Erkennung, da sich viele der ersten Kompromittierungsindikatoren (Indicators of Compromise, IoCs) auf die npm-Registry konzentrierten und Sicherheitswerkzeuge aktualisiert werden mussten, um die neue Laufzeitumgebung zu überwachen .

Indem nur die Build-Anweisungen und nicht die Software selbst vergiftet wurden, umgingen die Angreifer traditionelle Integritätsprüfungen. Der vorgelagerte Quellcode erschien sauber und die Malware wurde erst zur Build-Zeit heruntergeladen und ausgeführt, was sie für Nutzer unsichtbar machte, die PKGBUILD-Skripte nicht manuell überprüften .

Die Schadnutzlast: Infostealer und Rootkit

Maschinen, die die kompromittierten Pakete bauten, erhielten eine zweistufige Nutzlast, die auf Spionage und dauerhaften Verbleib ausgelegt war.

• Rust-basierter Credential-Stealer: Eine zielgerichtete Binary-Datei, die Entwickler-Geheimnisse wie Browser-Sessions, SSH-Schlüssel, GitHub-Token, npm-Token, Slack/Teams-Sessions, Vault-Token, Docker/Podman-Zugangsdaten und Cloud-Zugriffsschlüssel ausliest und exfiltriert .
• eBPF-Rootkit (nur bei Root-Rechten): Wurde das Paket mit Root-Rechten gebaut, installierte die Malware einen eBPF-Rootkit, der seine eigenen Dateien, Prozesse und Netzwerkaktivitäten vor Standard-Erkennungstools wie ps und htop verstecken kann. Der Rootkit nutzte /sys/fs/bpf/ für die Persistenz, was seine Entfernung extrem erschwert .

Die Kombination aus einem Credential-Stealer und einem Kernel-Level-Rootkit macht diesen Angriff besonders gefährlich, vor allem für Entwickler, deren Arbeitsrechner oft privilegierte Zugangsschlüssel und sensible Daten enthalten.

Reaktionen der Community und der Entwickler

Die Arch-Linux-Community reagierte schnell, wurde jedoch durch das Ausmaß des Angriffs vor Herausforderungen gestellt.

• Maßnahmen des Arch-Teams: Arch-Entwickler eröffneten am 11. Juni einen zentralen Meldethread im AUR und begannen damit, bösartige Commits rückgängig zu machen, Angreifer-Konten zu sperren und den Pool verwaister Pakete zu bereinigen. Arch Linux setzte zudem am darauffolgenden Montag die Registrierung neuer Konten im AUR aus, um weiteren Missbrauch zu verhindern . Der Arch-Paketbetreuer Jonathan Grotelüschen bestätigte, dass das Team daran arbeite, „alle bösartigen Commits wiederherzustellen oder zu löschen und die verantwortlichen Konten zu sperren“ .
• Kontroverse in der Community: Der Angriff löste heftige Debatten aus. In Foren wie PrivacyGuides forderten einige Community-Mitglieder die komplette Abschaltung des AUR mit der Begründung, das vertrauensbasierte Modell sei bei einem Kompromittierungsausmaß dieser Größenordnung grundlegend gescheitert .
• Reaktion externer Sicherheitsfirmen: Sicherheitsunternehmen wie Sonatype, Corgea, die Cloud Security Alliance (CSA) und TrueSec veröffentlichten detaillierte Analysen, Kompromittierungsindikatoren (IoCs) und Community-Erkennungsskripte (wie aur-malware-check), um Nutzern bei der Überprüfung ihrer Systeme zu helfen .

Ein großer Kritikpunkt war, dass das offizielle Arch-Team nicht sofort eine einzige, verbindliche Liste aller betroffenen Pakete veröffentlichte. Dies führte dazu, dass Nutzer auf Manifeste von Drittanbietern wie SafeDep und Corgea angewiesen waren .

Lehren für das Linux-Ökosystem

Der Atomic-Arch-Angriff offenbart strukturelle Schwächen in vertrauensbasierten Community-Repositorien, die auf ehrenamtliche Pflege angewiesen sind.

• Die „Orphan-Falle“ ist ein systemisches Risiko: Die Möglichkeit für jeden Nutzer, ein aufgegebenes Paket ohne Identitätsprüfung oder obligatorische Code-Überprüfung sofort zu übernehmen, verwandelte eine praktische Funktion in einen hochwirksamen Angriffsvektor .
• Build-Time-Injection umgeht Integritätsprüfungen: Traditionelle Verteidigungsmechanismen beruhen auf der Überprüfung der Integrität von Quellcode-Archiven. Da Atomic Arch die Build-Skripte und nicht den Quellcode vergiftete, boten Standard-Prüfsummen keinen Schutz .
• Ökosystem-übergreifende Lieferketten sind die neue Front: Der Angriff nutzte die npm- und Bun-Registries, um Malware im Linux-Ökosystem zu verteilen, und bewies damit, dass ein einziges kompromittiertes Paket in einer Registry kaskadierende Auswirkungen auf andere Plattformen haben kann .

Was betroffene Nutzer jetzt tun müssen

Sicherheitsforscher und die Arch-Community sind sich einig: Die einfache Entfernung eines einzelnen Pakets reicht hier nicht aus.

1. Gehen Sie von einer vollständigen Kompromittierung aus: Betrachten Sie jeden Rechner, der zwischen dem 9. und 12. Juni 2026 ein AUR-Paket gebaut oder aktualisiert hat, als vollständig kompromittiert .
2. Neuinstallation von einem sauberen Medium: Ein einfacher Malware-Scan ist unzuverlässig, da der eBPF-Rootkit darauf ausgelegt ist, sich zu verstecken. Die einzig garantierte Maßnahme ist, das betroffene System von einem vertrauenswürdigen Installationsmedium aus neu aufzusetzen .
3. Alle Zugangsdaten sofort zurücksetzen: Gehen Sie davon aus, dass der Credential-Stealer jedes auf dem Rechner erreichbare Geheimnis exfiltriert hat: SSH-Schlüssel, GitHub- und npm-Token, Vault-Token, Cloud-Zugriffsschlüssel, Browser-Sessions und Docker/Podman-Zugangsdaten .
4. AUR-Historie prüfen: Führen Sie

   pacman -Qm

   aus, um alle extern installierten Pakete auf dem System aufzulisten, und gleichen Sie diese mit den von der Community veröffentlichten Listen bösartiger Pakete ab .
5. Auf Kompromittierungsindikatoren prüfen: Suchen Sie in Build-Caches nach Spuren von atomic-lockfile, lockfile-js oder js-digest sowie nach verdächtigen Einträgen unter /sys/fs/bpf/ .
6. Behandeln Sie dies als Security-Incident: Organisationen sollten dies nicht als einfache Scan-Übung betrachten. Jede Arch-Entwickler-Workstation oder jeder CI/Build-Server, der während des Angriffszeitraums Pakete aus dem AUR bezogen hat, muss als Sicherheitsvorfall mit einer umfassenden Reaktion behandelt werden .