Rust-Lieferkettenangriff schleust Build-Time-Malware in arrayref ein

Angreifer haben am 20. August 2026 manipulierte Versionen von drei weit verbreiteten Rust-Crates - arrayref 0.3.10, internment 0.8.7 und append-only-vec 0.1.9 - auf crates.io veröffentlicht, und wer ein Projekt kompilierte, das eine dieser Versionen auflöste, führte Malware auf seinem Rechner aus. Die Schadroutine lief direkt beim cargo build; ein Entwickler oder CI-Runner musste den vergifteten Code also nie aufrufen, um kompromittiert zu werden.

Das Zeitfenster war kurz, die potenzielle Reichweite nicht. Laut The Hacker News kommt arrayref auf 245.385.500 Downloads insgesamt, davon 53.905.601 in den 90 Tagen vor dem Angriff, und 403 Crates führen es als direkte Abhängigkeit. Die Sicherheitsfirma Wiz gibt an, dass arrayref in mehr als 35% aller von ihr beobachteten Umgebungen vorkommt - und in drei Vierteln der Umgebungen, in denen Rust überhaupt präsent ist.

Wie der Angriff funktionierte

Das Rust Security Response Team erklärt, es habe am 20. August um 7:15 UTC einen Hinweis erhalten und verifiziert, dass das neue arrayref-Release "ein Build-Skript enthielt, das eine bösartige Nutzlast herunterlud". Die manipulierten Versionen veränderten arrayrefs eigenen Code nicht. Stattdessen fügten sie eine neue Abhängigkeit namens proc-macro1 hinzu - ein Typosquat auf das legitime proc-macro-Ökosystem -, deren Build-Skript beim Kompilieren eine entfernte Binärdatei herunterlädt und ausführt.

Die Analyse von StepSecurity bringt den Mechanismus auf den Punkt: "Es reichte, irgendein Projekt zu bauen, dessen Lockfile arrayref 0.3.10 auflöste, um die Nutzlast zu zünden. Der Code des Crates muss nie aufgerufen werden." Dieselbe Analyse stellte fest, dass der Angreifer alle sauberen 0.3.x-Releases von arrayref in einem skriptgesteuerten Schub zurückzog und damit "Cargos eigene 'yanked version'-Warnung als Auslieferungsmechanismus" nutzte - wer auf die Warnung reagierte, aktualisierte geradewegs in das bösartige Release hinein.

Laut Wiz rekonstruierte die heruntergeladene Backdoor ihre Command-and-Control-URLs aus Base64-Fragmenten, deaktivierte die TLS-Zertifikatsprüfung und brachte plattformspezifische Nutzlasten mit Persistenz für Windows, macOS und Linux mit, dazu das Auslesen von Zugangsdaten aus Browser-Profilen. Neben proc-macro1 identifizierte das Rust Security Response Team fünf weitere Crates unter Kontrolle der Angreifer: proc-macro-en, aovine, arone, aronenao und tinymember.

crates.io entfernte die manipulierten Releases schnell: arrayref 0.3.10 war 86 Minuten online, internment 0.8.7 90 Minuten und append-only-vec 0.1.9 107 Minuten, so die von The Hacker News berichteten Zeitstempel. StepSecurity hält fest: "Die gesamte Operation, von der Erstellung der Tarnidentität bis zur Entfernung aus der Registry, passt in einen einzigen Arbeitsvormittag."

Wer dahintersteckt

Kompromittiert wurde das Konto des Maintainers, nicht der Maintainer selbst. "Wir glauben nicht, dass der Autor von arrayref böswillig handelt; vermutlich sind sein Rechner oder seine Zugangsdaten kompromittiert", erklärte das Rust Security Response Team in seiner Offenlegung.

Wiz berichtet, dass die Infrastruktur der Kampagne erheblich mit jüngsten nordkoreanischen Lieferkettenoperationen überlappt: Sie nutzt denselben Hostwinds-Adressbereich 23.254.164.0/23 wie die npm-Kampagne Mastra, die der DPRK-nahen Gruppe Sapphire Sleet zugeschrieben wird, und ihr Command-and-Control-Verkehr lief zu einer IP-Adresse, die in der Analyse der axios-npm-Angriffe von Google Cloud Threat Intelligence auftaucht - ebenfalls Nordkorea zugeschrieben. Das aus npm bekannte Playbook hat damit crates.io erreicht.

Was das für Entwickler bedeutet

Wenn einer Ihrer Rechner oder CI-Runner am Vormittag des 20. August (UTC) ein Rust-Projekt gebaut hat, prüfen Sie, ob das Lockfile arrayref 0.3.10, internment 0.8.7 oder append-only-vec 0.1.9 aufgelöst hat, und inspizieren Sie den lokalen Registry-Cache - das Advisory des Rust Security Response Teams bittet darum, zwischengespeicherte Abhängigkeiten auf die oben genannten bösartigen Crate-Namen zu prüfen. Behandeln Sie eine Maschine, die eines dieser Releases gebaut hat, als kompromittiert, nicht bloß als gefährdet: Laut Wiz installiert die Nutzlast Persistenz und liest Browser-Zugangsdaten aus - rotieren Sie also alle Secrets, die diese Maschine erreichen konnte.

Die strukturelle Lehre: Build-Skripte sind eine Angriffsfläche für Remote-Code-Ausführung, und Lockfiles sind die Kontrolle darüber. Ein eingechecktes Cargo.lock pinnt exakte Versionen; verwundbar waren im 86-Minuten-Fenster ein frisches cargo install oder ein ungepinnter CI-Job. Der Angriff verwandelte zudem ein Sicherheitsfeature in einen Köder - nach dem Yank-Trick ist "eine zurückgezogene Version heißt: sofort aktualisieren" kein sicherer Reflex mehr. Prüfen Sie, worauf Sie aktualisieren, und behandeln Sie eine brandneue Abhängigkeit im Diff eines lange stabilen Crates als Signal, sofort innezuhalten.