#Netzwerk & Sicherheit · 5 Min. Lesezeit · Tim Rinkel

GIFT IM BAUKASTEN! Ein Rust-Paket mit 245 Millionen Downloads schob heimlich Malware in fremde Programme

GIFT IM BAUKASTEN! Ein Rust-Paket mit 245 Millionen Downloads schob heimlich Malware in fremde Programme

Es ist der Albtraum jedes Entwicklers: Du tippst cargo build, gehst Kaffee holen — und in der Zwischenzeit lädt dein Rechner ganz von allein eine fremde Datei aus dem Netz und führt sie aus. Genau das ist am 20. August passiert. Betroffen war kein Nischenprojekt, sondern arrayref, ein winziges Hilfspaket mit rund 245 Millionen Downloads.

SCHOCK: Der Angriff lief, bevor das Programm überhaupt startete

Die meisten Menschen stellen sich Schadsoftware so vor: Man installiert etwas, startet es, und dann geht es los. Beim arrayref-Angriff war das anders — und deshalb ist er so unangenehm.

Die manipulierte Version 0.3.10 brachte eine zusätzliche Abhängigkeit mit, ein Paket namens proc-macro1. Der Name sieht aus wie ein Tippfehler des echten, weit verbreiteten proc-macro2 — und genau das war Absicht. Dieses Paket enthielt ein sogenanntes Build-Skript. Solche Skripte laufen bei Rust ganz regulär während des Kompilierens, um zum Beispiel Systempfade zu ermitteln.

Hier tat das Skript etwas anderes: Es setzte seine Zieladresse aus mehreren harmlos aussehenden Textschnipseln zusammen, lud von dort ein Programm herunter und startete es. Kurz gesagt: Bauen reichte aus. Du musstest deine Anwendung nie ausführen.

Der dreisteste Teil: TLS-Prüfung einfach abgeschaltet

Damit die Verbindung zum Server der Angreifer garantiert klappt, baute das Skript eine eigene Zertifikatsprüfung ein — eine, die schlicht immer „alles in Ordnung“ meldet. Alle drei Prüffunktionen gaben unabhängig vom Ergebnis Erfolg zurück.

Im Klartext: Die Sicherheitsprüfung, die normalerweise verhindert, dass dein Rechner mit einem gefälschten Server spricht, wurde für diesen einen Download stillgelegt. Sicherheitsforscher von Wiz sehen in Aufbau und Vorgehen deutliche Überschneidungen mit Kampagnen, die nordkoreanischen Gruppen zugerechnet werden.

Drei Pakete, ein gekapertes Konto — und 86 Minuten

Betroffen waren drei Veröffentlichungen desselben Entwicklerkontos, alle am 20. August:

  • arrayref 0.3.10
  • internment 0.8.7
  • append-only-vec 0.1.9

Das crates.io-Team zog alle drei nach 86 bis 107 Minuten zurück. Das klingt schnell — und ist es auch. Trotzdem reicht gut eine Stunde locker aus, damit automatische Build-Systeme irgendwo auf der Welt die neue Version ziehen. Genau da liegt das Problem.

Denn arrayref benutzt kaum jemand bewusst. Es steckt tief in ganz normalen Abhängigkeitsketten: über tiny-skia, sctk-adwaita und winit landet es unter fast allem, was mit den Oberflächen-Werkzeugen egui, eframe oder iced gebaut wird. Du kannst es also nutzen, ohne den Namen je gelesen zu haben.

So prüfst du dein Projekt in 3 MINUTEN

  1. Öffne die Datei Cargo.lock in deinem Projekt und suche nach arrayref, internment und append-only-vec.
  2. Steht dort 0.3.10, 0.8.7 oder 0.1.9, war das eine der manipulierten Versionen.
  3. Suche zusätzlich nach proc-macro1 — mit der Ziffer Eins am Ende. Ein Treffer ist ein klares Warnsignal.
  4. Bereinige den Zwischenspeicher (cargo clean), aktualisiere auf die sauberen Versionen und baue neu.
  5. Hat ein Build-Rechner die Pakete gezogen: Zugangsdaten, Tokens und SSH-Schlüssel dieses Rechners austauschen. Der Schadcode war auf das Abgreifen genau solcher Daten ausgelegt.

EXTRA-TIPP: Warum das auch dein Homelab angeht

Du schreibst keinen Rust-Code? Dann trifft dich der Vorfall indirekt — und die Lehre daraus trotzdem. Immer mehr Werkzeuge im Selfhosting-Bereich sind in Rust geschrieben. Wer solche Projekte selbst aus dem Quellcode baut, statt fertige Container zu nutzen, holt sich diese Bau-Schritte mit ins Haus.

Die praktische Konsequenz: Baue nicht als root und nicht auf deinem Hauptsystem. Ein Container oder eine kleine VM, die nach dem Build wieder verschwindet, kostet fünf Minuten Einrichtung und begrenzt genau diesen Schadensfall.

FAZIT: Kleine Pakete, große Hebel

Der Fall arrayref zeigt kein neues Muster, aber ein besonders sauber ausgeführtes. Ein gekapertes Entwicklerkonto, ein Paket, das niemand bewusst installiert, und ein Bau-Schritt, dem alle blind vertrauen. Die Reaktionszeit war gut. Die eigentliche Frage bleibt: Weißt du, was dein Rechner beim nächsten Build eigentlich tut?

Häufige Fragen

Welche Versionen sind betroffen?
Manipuliert wurden arrayref 0.3.10, internment 0.8.7 und append-only-vec 0.1.9 — alle am 20. August 2026 veröffentlicht und innerhalb von 86 bis 107 Minuten wieder entfernt. Die vorherige, saubere Version von arrayref ist 0.3.9. Wer danach neu aufgelöst hat, bekommt automatisch wieder unbedenkliche Pakete.
Wie merke ich, ob ich betroffen bin?
Der zuverlässigste Hinweis steht in deiner Cargo.lock. Tauchen dort die genannten Versionsnummern oder das Paket proc-macro1 auf, hat dein Build die manipulierte Kette gezogen. Zusätzlich lohnt ein Blick in die Netzwerkprotokolle des Build-Rechners rund um den 20. August.
Reicht es, einfach zu aktualisieren?
Zum Beseitigen der Pakete ja. Wenn ein Rechner den Schadcode aber ausgeführt hat, reicht das Update nicht: Der Ablauf war darauf ausgelegt, Zugangsdaten einzusammeln. Dann solltest du Tokens, API-Schlüssel und SSH-Schlüssel dieses Systems neu erzeugen und die alten sperren.
Warum trifft das so viele Projekte?
arrayref ist ein sehr kleines Hilfspaket, das über größere Bibliotheken wie tiny-skia oder winit in unzählige Abhängigkeitsbäume rutscht. Die meisten Entwickler haben es nie bewusst hinzugefügt. Genau diese unsichtbaren Zwischenschichten machen Angriffe auf die Lieferkette so wirkungsvoll.

Quellen

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert