Rust Supply-Chain-Angriff: arrayref schleust Backdoor beim Kompilieren ein

Ein Rust Supply-Chain-Angriff hat am 20. August 2026 drei weit verbreitete Pakete auf crates.io getroffen. Das Perfide daran: Der Schadcode lief nicht erst, wenn ein Programm die Bibliothek aufruft, sondern bereits beim Kompilieren. Ein einfaches cargo build genügte.

Was passiert ist

Betroffen sind laut Analyse von Wiz die manipulierten Versionen arrayref 0.3.10, internment 0.8.7 und append-only-vec 0.1.9. Alle drei erhielten eine neue Abhängigkeit namens proc-macro1 – ein Tippfehler-Klon des legitimen und millionenfach genutzten proc-macro2. In dessen Build-Skript steckte die eigentliche Bösartigkeit.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

Ein Detail verrät die Absicht besonders deutlich: proc-macro1 war überhaupt die erste Abhängigkeit, die arrayref in zehn Jahren Projektgeschichte bekam. Eine Bibliothek, die ein Jahrzehnt ohne Fremdcode auskam, holt sich plötzlich ein Netzwerkpaket – das ist kein Zufall.

BleepingComputer beschreibt den Ablauf: In der Nacht wurde ein GitHub-Konto angelegt, das einen bekannten Rust-Entwickler imitierte, kurz darauf ein passendes Konto auf crates.io. Die manipulierte arrayref-Version erschien anschließend über das echte Wartungskonto, während ältere Versionen zurückgezogen wurden – vermutlich, um Projekte zum Aktualisieren zu zwingen. Das Rust Security Response Team reagierte schnell: Die manipulierte arrayref-Version war um 07:15 UTC online und um 08:41 UTC wieder aus dem Index – ein Expositionsfenster von 86 Minuten. Das Konto wurde vorsorglich gesperrt; das Team geht davon aus, dass Rechner oder Zugangsdaten des Maintainers kompromittiert waren.

Was der Schadcode tat

Weil Cargo Build-Skripte während der Übersetzung ausführt, reichte das bloße Bauen eines betroffenen Projekts aus. Der Ablauf laut Wiz:

• Die C2-Adresse wurde aus Base64-Fragmenten zusammengesetzt.
• Die TLS-Zertifikatsprüfung wurde per eigenem Verifier ausgehebelt.
• Passend zu Betriebssystem und Architektur lud das Skript eine zweite Stufe nach – nach /tmp/rust-setup unter Unix beziehungsweise %TEMP%\\rust-setup.ps1 unter Windows – und startete sie.
• Der Build lief danach normal weiter, das Paket funktionierte unauffällig.

Die zweite Stufe ist eine vollwertige Hintertür: Sie sammelt Angaben zum Rechner, fragt die Login-Datenbanken von Chrome, Brave und Edge ab und nistet sich per Registry-Run-Schlüssel, LaunchAgent oder systemd-Benutzerdienst dauerhaft ein; gemeldet wird per HTTPS-POST. Ein Hinweis zur Genauigkeit: Ob dabei tatsächlich verschlüsseltes Passwortmaterial abfloss oder nur die Liste der hinterlegten Zugänge ausgelesen wurde, wird in den vorliegenden Analysen unterschiedlich dargestellt. Im Zweifel behandelt man es als Abfluss. Fällt der aus, greift ein Domain-Generierungs-Algorithmus. Wiz sieht deutliche Überschneidungen der Infrastruktur mit früheren nordkoreanischen Kampagnen gegen npm-Pakete – konkret mit den Angriffen auf Mastra und axios: gleicher C2-Pfad, gleicher SSL-Aussteller, dieselbe IP-Range beim selben Hoster. Das ist eine begründete Einschätzung, keine gerichtsfeste Zuordnung.

Was das für dich bedeutet

Der entscheidende Unterschied zu üblichen Paket-Vorfällen ist der Zeitpunkt der Ausführung. Bei einem klassischen Supply-Chain-Angriff muss der Schadcode irgendwann laufen – im Test, im Deployment, in Produktion. Hier genügte der Build. Betroffen ist damit jeder Rechner, der in diesem knapp anderthalbstündigen Fenster ein betroffenes Projekt frisch aufgelöst und gebaut hat: Entwickler-Laptops und vor allem CI-Runner. Und CI-Runner sind meist der Ort, an dem Signaturschlüssel, Cloud-Token und Deploy-Credentials liegen.

Genau deshalb ist „wir nutzen die Bibliothek ja gar nicht aktiv” hier kein Argument. Der Code muss nie aufgerufen werden.

Bemerkenswert ist auch die Methode mit den zurückgezogenen Versionen. Ein zurückgezogenes Paket erzeugt Warnungen, und Warnungen erzeugen Handlungsdruck – Teams aktualisieren reflexhaft. Der Angreifer hat also nicht nur eine technische Lücke genutzt, sondern eine eingeübte Reaktion. Wer das nächste Mal eine ganze Reihe stabiler Versionen eines alten Pakets verschwinden sieht, sollte zuerst nachsehen und erst dann aktualisieren.

Das Muster ist nicht neu: Beim npm-Supply-Chain-Wurm rund um keyv und cacheable ging es ebenfalls um gestohlene Zugangsdaten. Der wirksamste Einzelschutz gegen die Weiterverwertung solcher Beute bleibt ein zweiter Faktor, der sich nicht abgreifen lässt – siehe unsere Übersicht zu Hardware-Security-Keys mit FIDO2.

Was du jetzt tun solltest

• Lockfiles durchsuchen. Prüfe alle Cargo.lock auf die drei manipulierten Versionen und auf sämtliche Angreifer-Pakete: proc-macro1, proc-macro-en, aovine, arone, aronenao und tinymember.
• Lokalen Cargo-Cache prüfen unter ~/.cargo/registry/cache – dort liegen heruntergeladene .crate-Dateien auch dann, wenn die Version längst zurückgezogen wurde.
• Betroffene Hosts als kompromittiert behandeln. Jeder Rechner und jeder CI-Runner, der ein betroffenes Projekt gebaut hat, braucht eine Rotation aller erreichbaren Zugangsdaten: CI-Secrets, Tokens, Signaturschlüssel.
• Im Browser gespeicherte Passwörter zurücksetzen und die zugehörigen Sitzungen widerrufen. Ein Passwortwechsel ohne Session-Invalidierung bringt wenig.
• Persistenz-Reste entfernen: /tmp/rust-setup, %TEMP%\rust-setup.ps1 und den versteckten Starter %TEMP%\rust-setup-launch.vbs sowie unbekannte HKCU-Run-Einträge, LaunchAgents und systemd-Benutzerdienste.
• Build-Abhängigkeiten künftig gesondert prüfen. Eine neue Netzwerk-Bibliothek in einem Paket, das keinerlei Grund für Netzverkehr hat, ist ein Warnsignal.
• Ausgehenden Verkehr am CI-Runner begrenzen. Ein Build-Job, der ins offene Internet telefonieren darf, macht jedes Build-Skript zur Fernsteuerung. Beschränke ausgehende Verbindungen auf Paket-Registry und Artefakt-Speicher – das allein hätte diesen Angriff im CI gestoppt.
• Version vorübergehend festnageln statt reflexhaft hochzuziehen. Eine exakt gepinnte, nachweislich saubere Version kostet nichts und nimmt dem nächsten Yank-Manöver die Wirkung.

Quellen

• Wiz: Rust Supply Chain Attack on arrayref (20.08.2026)
• Rust Blog: Supply chain attack on arrayref
• BleepingComputer: Hackers poison arrayref Rust crate to push infostealer malware
• StepSecurity: arrayref, internment und append-only-vec poisoned