Die erste neue Abhängigkeit seit zehn Jahren
Am 20. August 2026 nutzte ein Angreifer, der ein Maintainer-Konto auf crates.io, dem offiziellen Registry für Rust-Pakete, kompromittiert hatte, diesen Zugang, um vergiftete Versionen von drei weit verbreiteten Crates zu veröffentlichen: arrayref, internment und append-only-vec. Allein arrayref ist in mehr als 35 Prozent aller Rust-Umgebungen und in etwa drei von vier Umgebungen vorhanden, in denen Rust überhaupt vorkommt, was es zu einer der unauffälligsten, aber am weitesten verbreiteten kleinen Bibliotheken im gesamten Ökosystem macht.
Die bösartige Version arrayref 0.3.10 trug ein Detail in sich, das für sich allein schon ein Warnsignal hätte sein müssen: Es war die erste neue Abhängigkeit, die arrayref in seiner gesamten zehnjährigen Geschichte hinzugefügt hatte. Wenn ein Crate ein Jahrzehnt lang völlig ohne Abhängigkeiten ausgekommen ist und dann plötzlich eine bekommt, ist genau das die Art von Änderung, die eine sorgfältige Abhängigkeitsprüfung auffallen müsste, sofern überhaupt jemand hinschaut.
Ein Build-Skript lief, bevor irgendein Code lief
Jede vergiftete Version fügte eine Abhängigkeit zu einem neuen, ebenfalls bösartigen Crate namens proc-macro1 hinzu. Proc-macro1 enthielt ein Build-Skript, ein kleines Programm, das Cargo, das Build-Werkzeug von Rust, automatisch als Teil des Kompilierens eines Projekts ausführt, noch bevor der eigentliche Code des Projekts fertig gebaut oder überhaupt ausgeführt wurde.
Genau diese automatische Ausführung machte den Angriff so unauffällig: Ein Entwickler oder eine CI-Pipeline musste die fertige Binärdatei nicht ausführen, nichts anklicken und keine verdächtige Funktion importieren, um kompromittiert zu werden. Es reichte, auf einem Projekt, das von dem vergifteten Crate abhing, einfach cargo build auszuführen, um das Build-Skript auszulösen und die Nutzlast des Angreifers herunterzuladen.
Zurückziehen und Anstupsen: ein Trick aus der npm-Welt
Der Angreifer zog außerdem die älteren, sauberen Veröffentlichungen von arrayref zurück, die Versionen 0.3.5 bis 0.3.9, aus dem Registry. Ein Zurückziehen löscht eine Version nicht vollständig, sorgt aber dafür, dass Cargo seine übliche Warnung anzeigt, ein Projekt solle auf eine Version aktualisieren, die nicht zurückgezogen wurde.
Da jede saubere Version als zurückgezogen markiert war, blieb als einzige nicht zurückgezogene Veröffentlichung, die Cargo empfehlen konnte, nur die bösartige Version 0.3.10 übrig, was Entwickler über das eigene Werkzeug des Registrys zur vergifteten Version drängte. Sicherheitsforscher haben genau dieses Muster aus Zurückziehen und Anstupsen bereits bei früheren npm-Supply-Chain-Angriffen beobachtet, sodass sein Auftauchen bei crates.io denselben Trick aus Social Engineering über Werkzeuge nahelegt und keine neue Erfindung ist.
Drei Crates, drei kurze Zeitfenster
Alle drei bösartigen Versionen wurden innerhalb eines 22-minütigen Zeitfensters am Morgen des 20. August 2026 veröffentlicht, und alle drei wurden innerhalb von etwa 90 bis 107 Minuten nach Veröffentlichung wieder entfernt, nachdem das Rust Security Response Team das kompromittierte Konto gesperrt und die Pakete zurückgezogen hatte.
| Crate | Bösartige Version | Veröffentlicht (UTC) | Entfernt (UTC) | Minuten live |
|---|---|---|---|---|
| arrayref | 0.3.10 | 07:15 | 08:41 | 86 |
| internment | 0.8.7 | 07:34 | 09:04 | 90 |
| append-only-vec | 0.1.9 | 07:37 | 09:25 | 107 |
Ein Zeitfenster von weniger als zwei Stunden klingt kurz, aber crates.io kennt keine eingebaute Verzögerung zwischen der Veröffentlichung einer neuen Version und dem Moment, ab dem jedes abhängige Projekt sie beim nächsten Build automatisch abrufen kann, sodass selbst ein kurzes Fenster ausreicht, damit ein Build-Skript jedes Projekt erreicht, das zufällig während dieser Zeit neu gebaut wird.
Diebstahl von Zugangsdaten, ein Kill-Switch und eine Spur nach Nordkorea
Wiz Research analysierte die Nutzlast und fand eine Hintertür, die sich per HTTPS bei einem entfernten Server meldet, gespeicherte Zugangsdaten aus Chrome, Brave und Edge aufzählt, plattformübergreifende Persistenz einrichtet und vier verschiedene Fernbefehle ausführen kann, darunter einen Kill-Switch und einen Befehl zum Ausführen beliebiger Skripte.
Wiz stellte außerdem fest, dass der Endpunkt der Hintertür sich dieselbe Infrastruktur wie die Mastra-Kampagne teilt, die Microsoft der mit Nordkorea verbundenen Gruppe Sapphire Sleet zuschrieb, sowie mit einem früheren Angriff auf das npm-Paket axios, den Google Cloud Threat Intelligence und Mandiant unabhängig voneinander ebenfalls Nordkorea zuordneten, was nahelegt, dass dieselbe Angreifergruppe, die bereits npm kompromittiert hat, nun dieselbe Fähigkeit gegen crates.io gezeigt hat. Die Entdeckung wird Nextron Systems GmbH zugeschrieben, einer deutschen Sicherheitsfirma; das Rust Security Response Team sperrte das Konto und zog alle drei Versionen zurück, und es gibt bislang keinen bestätigten Nachweis einer tatsächlichen Ausnutzung.
Rust löst Speicherfehler, nicht die Frage, wer das Konto kontrolliert
Der EU Cyber Resilience Act und NIS2 drängen Hersteller sicherheitskritischer und vernetzter Produkte schon länger zu speichersicheren Sprachen, und Rust ist einer der Hauptprofiteure dieses Drucks. Dieser Vorfall erinnert daran, dass eine Umstellung auf Rust aus Compliance-Gründen nur ein Problem löst, nämlich Speicherfehler wie Pufferüberläufe, ohne ein völlig anderes zu berühren: wer das Konto kontrolliert, das die Abhängigkeiten eines Projekts veröffentlicht, und was ein Build-Skript ausführen darf, bevor der eigene Code des Projekts überhaupt fertig kompiliert ist.
Eigentümer, die eine Rust-Umstellung aus Compliance-Gründen angeordnet haben, sollten ihren Entwicklungsteams drei konkrete Fragen stellen: Werden Abhängigkeitsaktualisierungen vor dem Merge geprüft, kann die CI-Pipeline einschränken, was ein Build-Skript tun darf, und würde überhaupt jemand ein Zurückziehen und erneutes Veröffentlichen am selben Tag bei einem Paket bemerken, dem das Team seit Jahren vertraut. Bemerkenswert ist, dass die Entdeckung selbst von Nextron Systems GmbH kam, einer deutschen Firma, was jede Annahme widerlegt, dieses Risiko in der Lieferkette betreffe nur andere.
Weiterlesen: Niemand kann den Chip in Ihrem Sicherheitsschlüssel prüfen | Ihr Bounty-Budget kauft KI-Müll
