Der arrayref-Supply-Chain-Angriff, und warum deine Wallet keine einzelne Angriffsfläche braucht

TL;DR: Angreifer haben das Konto eines bekannten Rust-Paketes übernommen und eine gefälschte Version veröffentlicht, die bei jedem Build automatisch Schadcode ausführt. Die bösartige Version lag rund 86 Minuten online, und das Paket hat 245 Millionen Downloads. Das ist einer einer Welle von Supply-Chain-Angriffen, die häufiger und aggressiver werden. Die wichtigere Lektion für alle, deren Geld an Software hängt, ist, dass der Code und die Server zwischen dir und deinem Geld eine einzelne Angriffsfläche sind. Nuri ist so gebaut, dass kein einziger Kompromittierung, weder eine kompromittierte App noch ein gehackter Server, den Schlüssel freilegt, der dein Bitcoin kontrolliert. Nur ein Schlüssel liegt je auf dem Telefon. Der zweite Anteil liegt bei einem Stateless-Dienst. Um das Geld zu stehlen, braucht der Angreifer beide.

Aktualisiert 21. August 2026 16 Min. Lesezeit Markdown

Inhalt öffnen

Die kurze Antwort

Am 20. August 2026 ging der Bericht ein, dass das Rust-Paket proc-macro1 bösartig sei. Das Rust Security Response Team bestätigte es binnen Minuten: Die Crate trug ein Build-Skript, das eine ferne Last herunterlud und ausführte. Es reichte, ein Projekt zu bauen, das die Crate einband. Niemand musste eine Funktion aufrufen. Der Build selbst war der Auslöser.

Das eigentliche Ziel war arrayref, eine kleine, bekannte Crate, die von sehr vielen anderen Projekten genutzt wird. Das Konten-Inhaber war kompromittiert. Der Angreifer veröffentlichte eine neue Version von arrayref, die von der gefälschten Crate abhing, und zog die alten Versionen still zurück, damit das Build-Tool die Nutzer auf die schlechte Version lenkte.

Das hier geht nicht speziell um Rust. Es geht darum, wie Software gebaut wird: Wir alle hängen an tausenden Bausteinen, die andere geschrieben haben, und jeder von ihnen kann der sein, der still vergiftet ist. Wenn das Ding, das dein Geld hält, Software ist, wird das aus einem Entwicklerproblem zum Geldproblem.

Was tatsächlich passiert ist

Der Angreifer hat die Bibliothek nicht neu geschrieben. Er hat eine Zeile hinzugefügt: eine Abhängigkeit auf proc-macro1, eine absichtliche Fehlschreibung von proc-macro2, einer der am häufigsten heruntergeladenen Crates im ganzen Ökosystem. Die gefälschte Crate ist eine echte Kopie der echten, damit der Build läuft und die Software weiterhin funktioniert. Das ist genau der Punkt. Nichts sieht kaputt aus. Die Last läuft, bevor du überhaupt merkst, dass irgendetwas nicht stimmt.

Das Build-Skript hat die Server-Adresse des Angreifers still aus Teilen kodierten Texts rekonstruiert, die Sicherheitsprüfung deaktiviert, die den Server auf Identität prüft, und dann ein Programm für dein Betriebssystem und deinen Prozessor heruntergeladen. Auf Mac und Linux schrieb es die Datei in einen Temp-Ordner und startete sie im Hintergrund. Auf Windows schrieb es ein Skript und startete es versteckt. Der Angreifer hat all das so gewählt, dass es nicht auffällt, während der Build läuft.

Die heruntergeladene Backdoor ist echte Schadsoftware, kein Test. Sicherheitsforscher, die sie analysiert haben, fanden, dass sie anruft, deinen Computer- und Benutzernamen liest, deine installierten Programme listet und in deinem Browserprofil nach gespeicherten Logins sucht. Sie installiert sich so, dass sie nach einem Neustart wiederkommt. Sie kann auf Abruf mehr Code herunterladen und ausführen. Wenn der Hauptserver ausfällt, generiert sie frische Domainnamen, um einen neuen zu finden.

Die bösartigen Versionen wurden schnell gelöscht: arrayref 0.3.10 war rund 86 Minuten online, und die zwei verwandten Crates rund 90 und 107 Minuten. Das Rust-Team sperrte das Inhaber-Konto als Vorsichtsmaßnahme und gab an, es nicht zu glauben, dass der Autor in schlechter Absicht gehandelt hat. Sein Computer oder sein Login ist wahrscheinlicher der Teil, der kompromittiert wurde. Der Autor von arrayref pflegt die Crate seit 2009.

Wiz, eine Sicherheitsfirma, fand, dass die Infrastruktur des Angreifers mit jüngeren Operationen übereinstimmt, die Nordkorea zugeschrieben werden, einschließlich Kampagnen gegen andere beliebte Bibliotheken. Das war kein Einzelfall eines zufälligen Anfängers. Es war eine organisierte Kampagne mit einem Muster, das sie schon vorher genutzt hatten.

Ziel: arrayref 0.3.10, internment 0.8.7 und append-only-vec 0.1.9, alle von einem kompromittierten Konto.
Vehikel: eine neue Abhängigkeit, proc-macro1, eine Fehlschreibung des allgegenwärtigen proc-macro2.
Auslöser: der Build selbst. cargo build auf einem betroffenen Projekt führte die Last aus.
Online: 86 bis 107 Minuten vor dem Löschen am 2026-08-20.
Größe: arrayref hat 245 Millionen Downloads und erscheint in der Mehrheit der Umgebungen, die Rust nutzen.

Warum das die neue Normalität ist

Der arrayref-Angriff wirkt schockierend, weil er eine beliebte, vertrauenswürdige Bibliothek traf. Aber die Zahlen sagen, dass es nicht schockierend sein sollte. Dasselbe Angriffsmuster läuft seit Jahren gegen jedes große Paket-Registry, und die Rate steigt.

Anbieter, die das verfolgen, melden über eine Million bösartiger Pakete über npm, PyPI, Maven, NuGet und Hugging Face, mit einer Zahl neuer bösartiger Pakete im Jahr 2025, die um rund 75 Prozent zum Vorjahr stieg. Die geschätzten Kosten von Supply-Chain-Angriffen erreichten 2025 rund 60 Milliarden Dollar, mit Prognosen nahe 138 Milliarden bis 2030. Rund 30 Prozent der Datenlecks beinhalten inzwischen einen Dritten, und der Großteil der Schwachstellen in kommerzieller Software liegt nicht im Hauptcode, sondern in den Abhängigkeiten, die er einbindet.

Zwei Dinge machen es gleichzeitig schlimmer. Erstens ist das Tooling, das Software baut und ausführt, komplexer geworden, also gibt es mehr bewegliche Teile, die ein Angreifer berühren kann. Zweitens nutzen die Angreifer KI, um Ziele zu finden, den bösartigen Code zu schreiben und die Kampagne zu skalieren, während die Leute, die jede Abhängigkeit prüfen, meist unbezahlte Freiwillige sind.

Die unbequeme Wahrheit auf Hacker News, wo der Hauptthread 400 Punkte und Hunderte Kommentare erreichte, ist, dass Entwickler das kommen sehen. Eine der am häufigsten bewerteten Beobachtungen war, dass das Build-Tooling Code auf deinem Rechner ausführt, ohne deine Zustimmung, so dass das Hinzufügen einer Abhängigkeit reicht, um dich zu kompromittieren, bevor du den Code überhaupt prüfst. Eine andere stellte fest, dass dasselbe beim xz-Komprimierungskomprimierung passiert ist, und niemand kann jedes kleine Paket im tiefen Abhängigkeitsbaum lesen, um sicherzustellen, dass es sauber ist.

Was Entwickler sagen

Die Hacker-News-Diskussion war ungewöhnlich ruhig und spezifisch, was meist das Zeichen einer erfahrenen Gemeinschaft ist, die ein bekanntes Problem bearbeitet. Hier ist, was immer wieder kam, in ihren eigenen Worten, leicht gekürzt.

Zum Warum es immer wieder passiert: "Warum erlauben Inhaber von Paket-Registries nach so vielen früheren Supply-Chain-Angriffen noch jedem, Pakete hochzuladen und Updates zu pushen, ohne Sicherheitsprüfung?" Diese Frage war nicht rhetorisch. Die Folge war das eigentliche Problem: "Wer finanziert diese Sicherheitsprüfung? Sollen die Leute ihre freie Zeit freiwillig einsetzen?"

Zum Build-Tooling: "Das Problem ist, dass Build-Skripte automatisch ohne Nutzerzustimmung eingreifen. Das Hinzufügen einer Abhängigkeit reicht, um dich zu kompromittieren, bevor du die Chance hast, den Code zu prüfen." Mehrere merkten an, dass andere Paketmanager Kontrollen haben, die Cargo nicht hat, wie das Erlauben von Install-Skripten und eine Wartefrist für brandneue Abhängigkeiten.

Zum Ziel: "Entwicklermaschinen sind sehr saftige Ziele. Da liegen meist alle möglichen Zugangsdaten herum, so dass es oft nicht zu schwer ist, von dort zu deinen Cloud-Konten hochzusteigen." Das ist der eigentliche Preis in den meisten dieser Angriffe. Es ist nicht der eine Rechner. Es ist alles, was dieser Rechner erreichen kann.

Dazu, ob die Sprache eine Rolle spielt: "Rust scheint in dieser Hinsicht kaum besser als Node." Die Gegenargumentation, die ebenfalls weite Verbreitung fand, ist, dass das Ökosystem bereits Audit-Werkzeuge hat und mehrere große Firmen Audits der Crates veröffentlichen, von denen sie abhängen. Die Lücke ist, dass Prüfen die Ausnahme und nicht der Standard ist.

Ein Detail stach heraus. Mehrere fragten, was der bösartige Code tatsächlich tut, und die Antwort war, dass niemand es mit Sicherheit wisse, weil das Inhaber-Konto gelöscht und die bösartigen Veröffentlichungen vom Registry gelöscht statt nur zurückgezogen wurden. Der Angreifer räumte nach. Das ist das Merkmal einer Operation, die das schon vorher gemacht hat.

Wenn der Code das Geld kontrolliert

Most Supply-Chain-Angriffe zielen auf Entwickler und Firmen ab, und der Schaden sind gestohlene Zugangsdaten, gestohlene Daten oder eine langsame, teure Reinigung. Die Reichweite ist ein Build-Server oder ein Firmenkonto.

Eine Wallet ist anders. Der ganze Zweck der Software ist, dein Geld bewegen zu können. Wenn der Code in dieser Software oder die Server, von denen sie abhängt, kompromittiert werden können, kann der Kompromittierung direkt auf das Geld gehen. Es gibt keine Schicht aus "ups, wir haben ein paar Logins verloren" zwischen dem Angreifer und deinem Kontostand.

Deshalb sind das Supply-Chain-Problem und das Self-Custody-Problem dasselbe Problem. Beide drehen sich darum, wo der Schlüssel, der dein Geld kontrolliert, tatsächlich liegt, und ob jeder einzelne Punkt in der Kette, eine Bibliothek, ein Unternehmen, ein Server, ein Inhaber, ein Anbieter, ihn nehmen kann.

Das Problem der einzelnen Angriffsfläche

Eine einzelne Angriffsfläche ist einfach zu definieren und schwer wegzugestalten. Sie ist die eine Komponente, die, wenn sie kompromittiert wird oder ausfällt, das Ganze zum Scheitern bringt. Für eine Custodial-Börse sind es ihre Server. Wenn die kompromittiert werden oder sie einfach dein Konto einfrieren, liegt dein Geld in ihrer Hand. Für eine Software-Wallet, die deinen Schlüssel aus einem Geheimnis auf deinem Gerät ableitet, ist es dieses eine Geheimnis. Wenn die App durch ein vergiftetes Update kompromittiert wird oder dein Gerät wegkommt, ist das Geheimnis freigelegt.

Der Grund, warum diese Designs eine einzelne Angriffsfläche haben, ist, dass sie bequem sind. Ein Ort für den Schlüssel bedeutet einen Ort zum Unterschreiben und einen Ort zum Sichern. Bequemlichkeit und Sicherheit ziehen in entgegengesetzte Richtungen, und die meisten Produkte wählen Bequemlichkeit.

Es gibt eine bessere Form. Teile die Befugnis, dein Geld zu bewegen, auf zwei oder mehr Dinge, die ein Angreifer zusammen nehmen müsste, und achte darauf, dass keines von ihnen den ganzen Schlüssel allein hält. Dann gewinnt kein einzelner Kompromittierung, ein schlechtes Paket, ein gehackter Server, ein gestohlenes Telefon, ein bösartiges Update, allein. Der Angreifer muss zweimal erfolgreich sein, an zwei verschiedenen Orten, zur gleichen Zeit. Das ist der Unterschied zwischen einem Ziel und einer Festung.

Wie Nuri sie entfernt

Nuri ist auf einem Split-Unterschriften-Schema namens MuSig2 gebaut, in der 2-von-2-Form, die auf 2-von-3 erweitert werden kann. Zwei getrennte Anteile sind nötig, um zu unterschreiben und das Geld zu bewegen, und kein einzelner Anteil kann es allein tun.

Auf deinem Telefon existiert nur ein Schlüssel je: dein eigener Schlüssel. Er wird lokal aus deinem Passkey, dem biometrischen oder Geräte-Zugang, der dein Telefon entsperren kann, über eine Funktion abgeleitet, die ihn zu einem Schlüssel macht. Dieser Schlüssel wird auf deinem Gerät erzeugt und verlässt es nie. Er wird nicht hochgeladen, er wird nicht an einen Server zum Speichern geschickt, und er ist nicht in die App eingebacken, so dass er aus einem kompromittierten Build herausgezogen werden könnte.

Den zweiten Anteil hält der Nuri-Mitzeichnungs-Dienst. Hier ist der Teil, der für diese Geschichte zählt. Dieser Dienst ist stateless gebaut. Er hält die Befugnis, innerhalb der von dir für deine Wallet gesetzten Politik mitzuzeichnen, aber er speichert keine Kopie deines Schlüssels. Es gibt keinen Vault mit Benutzerschlüsseln auf Nuri-Servern, der kompromittiert werden könnte. Wenn die App, die du ausführst, durch einen Supply-Chain-Bug kompromittiert wird, bekommt der Angreifer eine kompromittierte App, nicht deinen Schlüssel. Wenn Nuri-Server gehackt werden, bekommt der Angreifer einen stateless Dienst ohne Benutzerschlüssel, die er nehmen könnte. Keines dieser Ereignisse legt den privaten Schlüssel frei.

Das Ergebnis ist, dass das arrayref-Muster, eine vergiftete Abhängigkeit, die Code beim Build ausführt, nicht in eine gestohlene Wallet übersetzt. Der Schlüssel, der zählt, liegt auf dem Telefon, abgeleitet aus etwas auf dem Telefon, und das zweite Unterschriften-Stück liegt bei einem Dienst, der nichts zu geben hat. Um das Geld zu stehlen, braucht es zwei ganze Anteile, und sie liegen an zwei verschiedenen Orten, die der Angreifer gleichzeitig erreichen müsste.

Das Design behält auch einen Ausgang. Die Mitzeichnungs-Einrichtung ist zeitlich begrenzt. Nach einem festen Fenster hat der Benutzer einen unabhängigen Wiederherstellungsweg, der nicht vom Mitzeichner abhängt. Und wenn du noch mehr Trennung willst, kann eine Hardware-Wallet als dritter Anteil hinzukommen, so dass es 2-von-3 ist, damit kein einzelnes Gerät oder ein Dienst, Telefon oder Server, genug hält, um dein Geld zu bewegen.

Wallet-Modelle, auf eine Frage verglichen

Der Vergleich, der zählt, ist nicht die Funktionen. Es ist, was ein einziger Bruch freilegt. Hier sind vier häufige Custody-Modelle, die dieselbe Frage gestellt bekommen.

Custody-Modelle im Vergleich, Stand Mitte 2026
Modell	Wo der Schlüssel liegt	App kompromittiert	Server des Anbieters kompromittiert	Was der Angreifer braucht
Custodial-Börse	Auf den Servern der Börse	Du kannst dein Geld nicht bewegen	Gelder können eingefroren oder genommen werden	Eine Sache, die Börse
Ein-Schlüssel-Software-Wallet	Ein Geheimnis auf deinem Gerät	Das Geheimnis kann freigelegt werden	Meist nicht im Pfad, aber die App ist das Risiko	Eine Sache, das Geheimnis deines Geräts
MPC mit gespeichertem Server-Anteil	Geteilt, ein Anteil auf dem Server	App kann Anteil-Handhabung freilegen	Ein gespeicherter Anteil kann gestohlen werden	Der gespeicherte Anteil plus der Geräte-Anteil
Nuri, stateless Mitzeichnung	Ein Schlüssel auf dem Telefon, ein stateless Anteil bei Nuri	Kein brauchbarer Schlüssel in der App	Kein Benutzerschlüssel gespeichert, um zu nehmen	Zwei ganze Anteile, an zwei Orten

Nicht dokumentiert bedeutet, dass die Fähigkeit nicht Teil des beschriebenen Designs ist, nicht dass sie nie existieren kann.
Die Nuri-Spalte beschreibt das 2-von-2-Modell mit einem stateless Mitzeichner, erweiterbar auf 2-von-3 mit einer Hardware-Sicherung.
Kein Modell ist gegen jeden Angriff immun. Dies ist ein Vergleich der einzelnen Angriffsfläche, die jedes davon zurücklässt.

Das kleine Glossar

Supply-Chain-Angriff: Eine Kompromittierung eines Bausteins oder einer Abhängigkeit, auf die andere vertrauen, damit der Angreifer alle erreicht, die ihn nutzen.
Typosquatting: Ein Name, der wie ein bekannter aussieht, mit einer kleinen Schreibänderung, damit er versehentlich aufgenommen wird. proc-macro1 für proc-macro2.
Build-Skript: Code, der automatisch beim Bauen eines Projekts läuft. In Rust kann er vor deinem eigenen Code laufen, weshalb er ein prime Ziel ist.
Einzige Angriffsfläche: Die eine Komponente, deren Verlust oder Kompromittierung das ganze System zum Scheitern bringt.
Self-Custody: Du hältst die Befugnis, dein eigenes Geld zu bewegen, statt dass ein Unternehmen es für dich hält.
MuSig2: Ein Unterschriftenschema, das das Recht zu unterschreiben über mehrere Schlüssel teilen kann, so dass kein einzelner Schlüssel das Geld allein bewegen kann.
Stateless: Der Dienst behält keine dauerhafte Kopie deines Schlüssels. Es gibt nichts Gespeichertes, das ein Bruch stehlen könnte.
Passkey: Der biometrische oder Geräte-Zugang, der dein Telefon entsperren kann, hier genutzt, um deinen Schlüssel lokal abzuleiten.

Fragen, die Menschen stellen

Was hat dieser Rust-Angriff mit meiner Wallet zu tun?

Indirekt viel. Die Lektion ist nicht über Rust. Es ist, dass die Software zwischen dir und deinem Geld aus Teilen gebaut ist, die du nicht kontrollierst, und jeder von ihnen kann vergiftet werden. Eine Wallet ist Software, deren Aufgabe es ist, dein Geld zu bewegen, so dass ein Supply-Chain-Kompromittierung ein direktes Risiko für dieses Geld ist, nicht nur für eine Entwicklermaschine.

Hat dieser Angriff eine Wallet oder einen Bitcoin-Nutzer getroffen?

Es gibt keinen Hinweis, dass die bösartigen Versionen genutzt wurden, um eine Wallet oder einen Einzelperson zu treffen. Das Rust-Team berichtete keine Hinweise auf tatsächliche Nutzung, und eine gepatchte Version existiert nicht, weil das war, die bösartigen Veröffentlichungen zu löschen. Das Risiko ist das Muster, das auf jede Software zutrifft, die von drittem Code abhängt, und Wallets sind Hochwert-Ziele für dieses Muster.

Schützt mich Self-Custody vor Supply-Chain-Angriffen?

Kommt auf das Design an. Self-Custody bedeutet, dass du die Befugnis hältst, aber wenn diese Befugnis ein Schlüssel an einem Ort ist, gewinnt ein einzelner Kompromittierung trotzdem. Der Schutz kommt vom Weglassen der einzelnen Angriffsfläche, damit die Befugnis geteilt ist und keine einzelne Komponente, App, Server oder Gerät, genug allein hält.

Was sollte ich jetzt konkret tun?

Für deine Software: Halte Abhängigkeitsversionen fest und auf dem neuesten Stand, und achte nach Vorfällen wie diesem auf neue bösartige Abhängigkeitsnamen. Für dein Geld: Wähle ein Custody-Modell, bei dem ein einziger Bruch deinen Schlüssel nicht freilegt. Wenn du Nuri nutzt, musst du nichts tun. Das Design hält bereits einen Schlüssel auf deinem Telefon und einen stateless Anteil auf unserer Seite, so dass eine kompromittierte App oder ein kompromittierter Server dem Angreifer keinen Schlüssel aushändigt.

Löst eine Hardware-Wallet das?

Eine Hardware-Wallet verlagert das Unterschreiben weg vom Telefon und der App, was viel des App-Supply-Chain-Risikos entfernt. Es ist eine starke Wahl. Nuri kann eine als dritten Anteil in einem 2-von-3-Setup nutzen, was zur stateless Mitzeichnung zusätzlich Trennung hinzuadds, statt sie zu ersetzen.

Was bedeutet stateless für den Nuri-Server?

Das bedeutet, der Mitzeichnungs-Dienst speichert deinen Schlüssel nicht. Er hält die Fähigkeit, innerhalb deiner Wallet-Politik mitzuzeichnen, nicht eine Kopie des privaten Schlüssels selbst. Also gibt es keinen Schlüssel-Vault auf Nuri-Servern, den ein Angreifer kompromittieren kann. Der private Schlüssel wird lokal auf deinem Telefon aus deinem Passkey abgeleitet und bleibt dort.

Wenn die App kompromittiert ist, kann ein Angreifer meinen Kontostand sehen oder Geld senden?

Eine kompromittierte App kann sehen, was die App selbst sehen kann, und ein bösartiges Update könnte falsche Informationen anzeigen. Aber dein Geld zu bewegen braucht eine Unterschrift, und die Unterschrift braucht beide Anteile zusammen. Ein stateless Mitzeichner ohne gespeicherten Schlüssel kann diese Unterschrift nicht allein erzeugen, und der Telefon-Schlüssel verlässt das Gerät nie.

Warum sollte ein Angreifer überhaupt an einer Wallet interessiert sein?

Weil es direktes Geld ist. Die arrayref-Backdoor wurde gebaut, um Zugangsdaten zu stehlen, die gehandelt oder genutzt werden können, um mehr zu erreichen. Ein Wallet-Schlüssel ist die direkteste Zugangsdaten überhaupt. Genau deshalb ist die einzelne Angriffsfläche das, was zu entfernen ist. Mach den Schlüssel unmöglich von einem einzigen Ort zu bekommen, und der Angreifer muss doppelt so glücklich und doppelt so koordiniert sein.

Was kann ich als Entwickler tun, um meine Builds zu schützen?

Halte deine Abhängigkeitsversionen fest und aktualisiere nicht automatisch auf eine brandneue Veröffentlichung an dem Tag, an dem sie erscheint. Viele Teams warten ein paar Tage, damit Prüfer und Sicherheitsfirmen sich zuerst eine neue Version ansehen können. Führe ein Audit deines Abhängigkeitsbaums und achte nach Vorfällen wie diesem auf neue Abhängigkeitsnamen. Diese Schritte verringern das Fenster, in dem eine vergiftete Veröffentlichung dich erreichen kann.

Wie oft passieren Angriffe wie dieser?

Häufiger als die Schlagzeilen vermuten lassen. Anbieter, die Paket-Registries verfolgen, zählen Tausende neue bösartiger Pakete jedes Quartal, und die Zahl steigt von Jahr zu Jahr. Die meisten werden nie Schlagzeilen, weil sie Typosquatting sind, die niemand installiert. Die, die Schlagzeilen machen, wie arrayref, sind die, die ein beliebtes, vertrauenswürdige Paket treffen. Das ist die Klasse von Ereignis, die für jeden zählt, dessen Geld an Software hängt.

Quellen und Hinweis zur Aktualität

Anggriffsdetails sind Stand 2026-08-21 und stammen aus dem verlinkten Rust-Team-Post, Berichten von Sicherheitsanbietern und dem Hacker-News-Thread. Statistiken sind Schätzungen aus den verlinkten Branchenberichten 2026 und variieren je nach Quelle. Bestätige aktuelle Zahlen, bevor du sie für eine Entscheidung verwendest.