Rust-Supply-Chain-Angriff: Präparierte arrayref-Version mit 245 Millionen Downloads infiziert

Am 20. August 2026 wurde die Rust-Paket-Registry crates.io Ziel eines Supply-Chain-Angriffs, der in seiner Tragweite ungewöhnlich groß ausfällt: Das kompromittierte Konto des langjährigen Maintainers von arrayref, einem winzigen aber weitverbreiteten Utility-Crate zur Array-Konvertierung, veröffentlichte eine präparierte Version. Das Crate selbst zählt rund 245 Millionen Downloads seit Erscheinen und liegt als Abhängigkeit unter vielen bekannten Bibliotheken wie tiny-skia, winit und blake3 sowie großen Teilen des Solana- und Ethereum-Tooling-Ökosystems. Für Rust-Entwickler und Admins, die selbst gebaute Rust-Binaries betreiben, ist das ein Vorfall, den man ernst nehmen muss, auch wenn die Schadversionen inzwischen entfernt sind.

Was genau passiert ist

Um 07:11 UTC wurde arrayref@0.3.10 über den Account des legitimen Maintainers veröffentlicht. Die neue Version führte erstmals eine Abhängigkeit namens proc-macro1 ein, ein Typosquatting-Paket, das den Namen des bekannten und weit verbreiteten Crates proc-macro2 imitiert und vier Minuten zuvor von einem Account veröffentlicht wurde, der sich als der bekannte Rust-Entwickler David Tolnay ausgab. Das build.rs-Skript dieses Pakets ist ein plattformübergreifender Dropper: Es lädt über eine TLS-Verbindung mit deaktivierter Zertifikatsprüfung eine zweite Schadkomponente herunter, speichert sie in einem temporären Verzeichnis und führt sie mit einer Command-and-Control-Adresse als Argument aus.

Entscheidend ist der Zeitpunkt der Ausführung: Rust-Build-Skripte laufen bereits während des Kompilierens, nicht erst wenn das fertige Programm gestartet wird. Es genügte also, ein Projekt zu bauen, dessen Lockfile arrayref 0.3.10 auflöste, um den Schadcode auszulösen. Der eigentliche Crate-Code musste dafür nie aufgerufen werden.

Ausmaß des Vorfalls

Innerhalb von nur 23 Minuten veröffentlichte das kompromittierte Konto vergiftete Releases aller drei eigenen Crates. Das Rust Security Response Team entfernte im selben Zuge ein zweites Dropper-Crate sowie vier weitere vom Angreifer kontrollierte Pakete. Laut dem Sicherheitsdienstleister StepSecurity blieben die Schadversionen zwischen 86 und 107 Minuten aktiv verfügbar, bevor sie entfernt wurden. Alle drei kompromittierten legitimen Crates wurden inzwischen von crates.io gelöscht, die fälschlich zurückgezogenen sauberen Versionen wiederhergestellt und die betroffenen Publisher-Accounts gesperrt.

Wer steckt dahinter?

Laut SecurityWeek bringen Sicherheitsforscher den Angriff mit nordkoreanischen Akteuren in Verbindung. Diese Zuordnung passt zu einem längeren Trend: Software-Supply-Chain-Angriffe über kompromittierte Paket-Manager-Accounts (npm, PyPI, jetzt verstärkt auch crates.io) werden seit Monaten verstärkt mit staatlich verbundenen nordkoreanischen Gruppen assoziiert, die primär auf Kryptowaehrungsdiebstahl und Infostealer-Verbreitung abzielen.

Was Entwickler und Admins jetzt tun sollten

1. Prüfen, ob eigene Rust-Projekte im Zeitfenster 20. August 2026, ca. 07:11 bis 09:25 UTC, gebaut wurden (CI-Pipeline-Logs, lokale Build-Historie).
2. Cargo.lock-Dateien nach den Versionen arrayref 0.3.10, internment 0.8.7 und append-only-vec 0.1.9 durchsuchen.
3. Betroffene Build-Hosts auf unbekannte Prozesse, ausgehende Verbindungen zu unbekannten Endpunkten und Dateien in temporären Verzeichnissen prüfen.
4. Bei Verdacht auf Kompromittierung: Build-Server neu aufsetzen statt nur bereinigen, da ein Build-Time-Dropper vollen Prozesszugriff hatte.
5. cargo audit und Dependency-Scanning-Tools wie cargo-deny in die eigene CI-Pipeline einbauen, um kompromittierte Versionen früh zu erkennen.
6. Grundsätzlich Lockfiles versionieren und Dependency-Updates nicht automatisch, sondern mit Review-Schritt einspielen.
7. CI-Build-Umgebungen so isolieren, dass ausgehende Netzwerkverbindungen während des Build-Vorgangs nur zu bekannten, notwendigen Zielen erlaubt sind.
8. Team über den Vorfall informieren, auch wenn kein aktiver Rust-Einsatz bekannt ist: Viele Tools (etwa ripgrep-basierte CLI-Werkzeuge) haben Rust-Abhängigkeiten im Unterbau.

Einordnung für den IT-Alltag

Der Vorfall zeigt exemplarisch, wie verwundbar moderne Software-Lieferketten sind, selbst wenn das eigene Unternehmen keine einzige Zeile Rust-Code schreibt. Container-Images, CLI-Tools und selbst Browser-Erweiterungen bauen zunehmend auf Rust-Komponenten auf. Build-Time-Angriffe wie dieser sind besonders tückisch, weil klassische Endpoint-Security-Lösungen den Schadcode oft erst erkennen, wenn er bereits läuft, während der Angriff bereits während des Kompilierens abgeschlossen ist. Für Admins in kleinen und mittleren Unternehmen bedeutet das: Auch interne Entwickler-Workstations und Build-Server gehören in die reguläre Sicherheitsüberwachung, nicht nur produktive Server.

Passende Anleitungen auf S-EDV

1. S3-Speicher selbst hosten nach dem MinIO-Aus: Garage und RustFS im Vergleich
2. CISA KEV: Warum der Known Exploited Vulnerabilities Catalog für Admins Pflichtlektüre bleibt

Quellen

1. The Hacker News: Rust Supply Chain Attack Puts Build-Time Malware in Crates with 245 Million Downloads
2. StepSecurity: Rust Supply-Chain Attack - arrayref, internment, and append-only-vec Poisoned
3. SecurityWeek: Rust Supply Chain Attack Linked to North Korean Hackers