Rust-Paket arrayref: Wie gelangte der Schadcode hinein?

Schädliches Rust-Paket arrayref: Der Schadcode startet beim Kompilieren

Markus Seyfferth

Autor Dr. Web

20. August 2026

2 Min. Lesezeit

Das Rust-Paket arrayref lag am 20. August 2026 genau 86 Minuten lang in einer manipulierten Fassung auf crates.io. In dieser Zeitspanne genügte ein einziger Build, damit ein nachgeladenes Programm auf dem Entwicklerrechner startete. Betroffen ist ein Baustein mit 245 Millionen Downloads, der tief unter Grafikbibliotheken wie winit und egui sitzt.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Um 07:15 Uhr UTC erschien Version 0.3.10 des Rust-Pakets arrayref auf crates.io. 24 Sekunden später verschwanden fünf saubere Vorgängerversionen aus dem Verzeichnis. Der Angreifer machte damit ausgerechnet die Warnung, die Cargo vor zurückgezogenen Versionen ausgibt, zum Wegweiser auf die präparierte Fassung.^[1]

Das Wichtigste in Kürze

Version 0.3.10 hängte eine neue Abhängigkeit namens proc-macro1 an, einen Tippfehler-Klon des weit verbreiteten Pakets proc-macro2.
Das Bauskript dieser Abhängigkeit lud eine Binärdatei von der Adresse 23.254.165.112 und führte die Datei losgelöst vom Build-Prozess aus.
Dasselbe Betreuerkonto veröffentlichte auch internment 0.8.7 und append-only-vec 0.1.9, zusammen kommen die drei Pakete auf 264 Millionen Downloads.
crates.io löschte alle drei Fassungen. Das Rust-Sicherheitsteam stuft das Betreuerkonto als übernommen ein und sperrte den Zugang vorsorglich.

Wie kam der Schadcode in ein Paket mit 245 Millionen Downloads?

Aufgestapelte Holzklötze mit einem Zettel und einer gefalteten Bauanleitung — Cargo führt Bauskripte vor Paketnutzung aus. Schadcode in build.rs von proc-macro1 konstruierte Server-Adressen aus base64-Fragmenten und lud Binärdateien herunter

Cargo führt Bauskripte automatisch aus, lange bevor eine einzige Zeile des Pakets aufgerufen wird. Genau dort saß der Schadcode, in der Datei build.rs des angehängten Pakets proc-macro1. Das Skript setzte eine Server-Adresse aus base64-Fragmenten zusammen und lud die passende Binärdatei für Linux, macOS oder Windows. Als Steuerkanal bekam das nachgeladene Programm eine zweite Adresse mit. Unter Windows startete ein VBScript den Ablauf über wscript.exe und entkam so der Prozessgruppe von Cargo.^[2]

Die Tarnung war sorgfältig gebaut: Das Angreiferkonto trug gefälschte Urheberangaben mit dem Namen des Betreuers von proc-macro2. Verraten hat den Angriff die Zutatenliste. Ein Paket, das jahrelang ohne jede Abhängigkeit auskam, brachte plötzlich base64, rustls und ureq als Bau-Abhängigkeiten mit.^[3]

Warum trifft dieses Muster jede Paketverwaltung?

Der Angriff über ein übernommenes Betreuerkonto ist längst Routine. Anfang August lief in der JavaScript-Welt noch der Angriff auf die npm-Lieferkette über das Paket Keyv. Im Mai plünderten 34 präparierte Pakete Wallets und Zugangstoken, einen Monat später scheiterte ein staatlich gestützter Übernahmeversuch bei einem einzelnen Entwickler.

Gegen so kurze Zeitfenster hilft vor allem Karenzzeit. Die drei manipulierten Fassungen standen 86, 90 und 107 Minuten bereit. Nach einer Wartefrist von drei Tagen wäre keine davon je in einem Firmenprojekt gelandet: GitHubs Dependabot wartet seit Juli standardmäßig genau so lange. Die Python-Verwaltung geht denselben Weg, seit PyPI nachträgliche Dateien in alten Releases nach 14 Tagen blockiert.

Ein Bauskript hat auf dem Entwicklerrechner dieselben Rechte wie der Entwickler selbst. Solange Cargo, npm und pip diese Skripte beim Installieren ausführen, entscheidet die Karenzzeit über den Schaden und nicht der Virenscanner.
— Michael Dobler, Herausgeber Dr. Web

86 Minuten

stand arrayref 0.3.10 auf crates.io bereit, von 07:15 Uhr UTC bis zur Löschung

245 Mio.

Downloads von arrayref insgesamt, davon 53,7 Millionen in den letzten 90 Tagen

406

abhängige Crate-Versionen, darunter Bausteine von winit, egui, iced und blake3

134 Minuten

dauerte das gesamte Zeitfenster über alle drei Pakete, von 07:11 bis 09:25 Uhr UTC

Neben den drei Fassungen entfernte crates.io auch das komplette Paket proc-macro1 samt der Hilfspakete arone, aronenao und tinymember.

Was sollten Unternehmen im DACH-Raum jetzt tun?

Ab dem 11. September 2026 wird aus so einem Fund eine Meldepflicht. Der EU Cyber Resilience Act verlangt von Herstellern digitaler Produkte ab diesem Stichtag eine Frühwarnung binnen 24 Stunden an die EU-Agentur ENISA. Danach folgen eine Vollmeldung nach 72 Stunden und ein Abschlussbericht, wobei eine fremde Abhängigkeit im eigenen Produkt niemanden entlastet.^[4]

Durchsuchen Sie Ihre Cargo.lock-Dateien nach arrayref 0.3.10, internment 0.8.7, append-only-vec 0.1.9 sowie jeder Fassung von proc-macro1. Löschen Sie passende Archive aus dem Cargo-Cache. Sauber bleiben allein die Stände 0.3.9, 0.8.6 sowie 0.1.8. Auf jedem Rechner, der am Vormittag des 20. August gebaut hat, tauschen Sie danach SSH-Schlüssel, Zugangstoken und Signaturschlüssel aus. Die Grundlagen dazu stehen in unseren Cybersecurity-Grundlagen für KMU.