Ein Kompilierungsfehler von vor fünf Jahren führte dazu, dass 1.816 Bitcoins bei den vier Angriffswellen abgezogen wurden

8. August 2026 · Beobachtung von Self-Custody und der Sicherheit von Schlüsseln
In der Nacht zum 30. Juli begannen die Angreifer, Bitcoin aus Coldcard-Hardware-Wallets zu transferieren. Die erste Welle verlegte innerhalb von 25 Minuten aus etwa 500 Wallets 594 BTC – zu dem Zeitpunkt im Wert von etwa 38 Millionen US-Dollar.[1] Galaxy Research ordnete diese Entleerungsaktionen in ein 41-Minuten-Fenster von UTC 1:10 bis 1:51 ein, verteilt auf neun Blöcke.[5]
Das war erst der Anfang. Bis zum 5. August hat TRM Labs Verfolgungsdaten von Galaxy zitiert: In vier Angriffswellen wurden insgesamt etwa 1.816 BTC abgezogen, was mehr als 5.200 Adressen betrifft; basierend auf den damaligen Preisen entspricht das nahezu 116 Millionen US-Dollar.[1] Das ist der drittgrößte groß angelegte Krypto-Angriff im Jahr 2026 und brachte die in diesem Jahr gestohlene Gesamtsumme über 1,2 Milliarden US-Dollar – bei insgesamt 276 Vorfällen.[1]
Der Angreifer hatte niemals Kontakt mit irgendeinem Gerät. [5]
## Das Problem liegt nicht am Gerät, sondern am Zufallszahlengenerator
Der Kernversprechen von Hardware-Wallets ist: Der private Schlüssel verlässt das Gerät nie. Diese Schwachstelle umgeht dieses Versprechen – denn sie greift nicht die Speicherung des Schlüssels an, sondern die Erzeugung des Schlüssels.
Eine Codeänderung vom 1. März 2021 ließ die Firmware bei der Seed-Erzeugung still auf einen Software-Zufallszahlengenerator zurückfallen, statt auf die Hardware-Entropy-Quelle des Geräts. [6] Die offizielle Ankündigung von Coinkite bestätigt, dass Firmware-Versionen von Mk2/Mk3, die von 4.0.1 bis 4.1.9 reichen, betroffen sind. [4]
Die technische Analyse des Block-Teams macht den Kern noch konkreter aus: In der Kompilierkonfiguration ist `MICROPY_HW_ENABLE_RNG` auf 0 gesetzt, weil Coldcard selbst einen Hardware-RNG-Wrapper implementiert; aber die Bibliothek libngu prüft mit `#ifndef` nur, ob dieses Makro „existiert“, und verifiziert nicht, ob es „aktiviert“ ist. [6] Dadurch läuft die Kompilierung zwar erfolgreich durch, tatsächlich gebunden ist jedoch der MicroPython-Softwaregenerator Yasmarang. Dessen Initialisierungseingaben sind die Chip-UID und Register des Timers – feste Gerätekennungen und beobachtbarer zeitlicher Zustand, keine kryptografische Entropiequelle. [6] libngu führt zudem ein XOR mit einem zweiten Yasmarang-Generator durch, der mit öffentlich bekannten Konstanten initialisiert wurde. Wie der Bericht von Block sagt: XOR erzeugt keine Entropie – zwei reproduzierbare Eingaben, und das XOR-Ergebnis ist ebenfalls reproduzierbar. [6]
Zur effektiven Stärke auf Mk3 gehen die beiden Quellen unterschiedlich. Laut Sekundärberichten kollabiert der effektive Suchraum auf etwa 40 Bit. [5] Blocks Analyse hingegen zeigt, dass in der Mk2/Mk3-v4-Pfadführung keine kryptografische Entropie hinzugefügt wurde. Unter den bekannten Voraussetzungen von UID, Timer-Status und Aufrufhistorie ist die Wallet-Generierung deterministisch. [6] Für Mk4/Q/Mk5 sagt Coinkite, dass die tatsächliche Entropie etwa 72 Bit beträgt, nicht die entworfenen 128 Bit; [4] Block wiederum behauptet, dass das Replay des Seeds im sicheren Element nur ein 32-Bit-Statuswort ersetzt, womit die Obergrenze des Kandidaten-Ausgabestroms bei 2^32 liegt. [6] Diese beiden Beschreibungen sind nicht gegeneinander austauschbar; in diesem Text werden beide Seiten aufgeführt.
Egal, welchen Maßstab man nimmt, das Fazit ist dasselbe: Das ist kein Unterschied im Grad. 128 Bit lassen sich nicht ausrechnen, aber ein paar Dutzend Bit bekommt man durch das Anmieten von Cloud-Rechenleistung zum Durchprobieren. Dem Angreifer ist es nicht nötig, irgendeine Barriere zu überwinden: Er kann den Seed offline neu generieren, die Adressen ableiten und dann prüfen, in welchen Adressen Geld liegt. [5] Block weist außerdem auf die nötige Zurückhaltung hin: Das bedeutet nicht, dass jeder entfernte Angreifer sofort jeden beliebigen Seed wiederherstellen kann. Die tatsächlichen Kosten hängen von UID-Informationen, Startzeitabläufen und den Derivationsaufwänden ab; der Bericht liefert keine End-to-End-Benchmark für das vollständige Durchprobieren. [6]
In der Ankündigung von Coinkite gibt es einen besonders wichtigen Satz: Ein Firmware-Update verändert oder behebt die bereits generierten Seeds nicht. [4] Das heißt: Das Patch schützt nur zukünftige Wallets, die neu erstellt werden. Wer nach März 2021 Seeds mit der betroffenen Firmware generiert hat, bei dem ist diese Seed-Phrase ab dem Moment der Generierung schwach – und sie bleibt schwach.
## Die Angriffsfläche ist breiter als der Schaden
Bestätigte Angriffe konzentrieren sich auf Mk2 und Mk3. Aber die Ankündigung von Coinkite zieht den Rahmen weiter: Mk4, Mk5 und Q-Geräte, die Seeds erzeugten, bevor es die reparierenden Versionen gab – dabei lag die effektive Entropie bei etwa 72 Bit und nicht bei den vorgesehenen 128 Bit. [4] Das ist deutlich besser als 40 Bit. In dieser Runde wurde es zwar nicht ausgenutzt, aber es bleibt unter dem Standard.
Zwei Arten von Menschen sind nicht im Risiko: Erstens diejenigen, die beim Seed-Erstellen zusätzlich mindestens 50 unabhängige Würfe mit separaten Zufallsquellen eingesetzt haben, weil dieser externe Entropieanteil nicht durch den Firmware-Fehler ausgelöscht wird. Und zweitens diejenigen, die der Wallet einen starken und einzigartigen BIP-39-Passphrase gegeben haben. [4] Coinkite weist gleichzeitig darauf hin, dass eine Passphrase die unmittelbare Exponierung senkt, aber die betroffenen Seeds nicht repariert. Auch diese Nutzer sollten daher so schnell wie möglich migrieren. [4]
## Zwei Dinge, die man sich merken sollte
Erstens: Der Audit hat es nicht gefunden. Coinkite erklärt, dass das Unternehmen in den Wochen vor dem Angriff einmal eine KI-Überprüfung der Firmware durchgeführt hat. Diese Prüfung hat den Bug nicht entdeckt und auch keine anderen gravierenden Probleme. Der Bug lag mehr als fünf Jahre lang im Code. TRMs Kommentar bringt es recht direkt auf den Punkt: Open Source und Audits verbessern zwar die Sicherheit, aber sie sind keine Garantie. [1]
Zweitens: Das Geld ist noch nicht bewegt. TRMs Nachverfolgung zeigt, dass sich der Großteil der gestohlenen Gelder auf wenige Angreifer-Adressen konzentriert. Geldwäsche-Aktionen gab es bis zum 4. August nur eine einzige: 64,9 BTC in Wasabi und 200 ETH in Tornado Cash. [1] Im Vergleich dazu starten professionelle Gruppen wie der nordkoreanische TraderTraitor-Werbeblock innerhalb von Stunden mit aggressiver Geldwäsche – das wirkt eher so, als hätten sie noch nicht entschieden, wie sie mit einem so offensichtlichen Geldbetrag umgehen sollen. [1] TRM vermutet zudem aufgrund der unterschiedlichen Konstruktionsweisen der Transaktionen über die Wellen hinweg, dass es möglicherweise mehrere Angreifer gibt; es wird derzeit keiner konkreten Organisation zugeschrieben. [1]
## Was diese Sache zeigt
In seinem Bericht gibt TRM einen abschließenden Satz, den man sich unbedingt merken sollte: Self-Custody verlagert das Risiko – nicht es zu beseitigen. Die Obergrenze der Vertrauenswürdigkeit eines Wallets entspricht der Vertrauenswürdigkeit des Prozesses, der seine Schlüssel erzeugt. [1]
Dieser Satz gilt viel breiter als nur für Coldcard. Jede Lösung, die die Sicherheit von Vermögenswerten auf genau einen einzelnen Schlüsselträger setzt – egal ob der Träger ein netzwerkabgeschaltetes Gerät ist, ein Stück Papier oder eine verschlüsselte Datei – hat dasselbe strukturelle Problem: Wenn irgendwo in dieser Kette ein Fehler passiert – beim Erzeugen, Speichern oder Sichern on-chain –, gibt es keine zweite Verteidigungslinie. Bei diesem Vorfall traf es genau die Stelle, die am schwersten zu überprüfen ist, denn die Qualität der Entropie lässt sich nicht so leicht anhand einer Firmware-Version „auf einen Blick“ bestätigen.
TRM nennt als Richtung: Kombiniere eigenständig konstruierte Geräte und eigenständig generierte Entropie, sodass die Implementierungen sich nicht gegenseitig beeinflussen. So entsteht eine Verteidigungstiefe mit unabhängigen Schichten. [1]
Aber hier gibt es eine Einschränkung, die im Bericht von Block sehr klar formuliert ist und die man getrennt betrachten sollte: Wenn in einem Multisig-Schema alle Geräte Modelle sind, die betroffen sind, bleibt die Auswirkung der Schwachstelle bestehen. Um das zu verhindern, braucht man „die vorgeschriebene Anzahl sicherer Geräte“, die zusammenkommen. [6]
Dieser Satz verschiebt den Fokus von „Anzahl der Anteile“ zu „Unabhängigkeit der Anteile“. Eine verteilte Signaturberechtigung allein bietet keinen Schutz – drei Anteile, die aus derselben fehlerhaften Implementierung erzeugt wurden, werden gemeinsam schwach. Echte Verteidigungstiefe entsteht erst, wenn die Erzeugungsprozesse der einzelnen Anteile gegenseitig unabhängig sind: unterschiedliche Implementierungen, unterschiedliche Entropiequellen, unterschiedliche Annahmen darüber, was man vertraut. Threshold-Signaturen und Key-Sharing-Modelle erfüllen hier dieselben Prüfstandards wie Multisig; man sollte diese Standards bei jedem Produkt hinterfragen, das behauptet, „Keys aufzuteilen“.
## Wenn du oder jemand in deinem Umfeld Coldcard nutzt
Coinkite hat bereits reparierte Firmware für alle betroffenen Modelle veröffentlicht: Mk2/Mk3 auf 4.2.0 und höher, Mk4/Mk5 Standardversion auf 5.6.0 und höher, Q Standardversion auf 1.5.0Q und höher. Für die Edge-Variante gibt es entsprechende Versionen. [4] Achtung: Standardversion und Edge sind zwei unabhängige Veröffentlichungsstrecken. Verlass dich nicht darauf, dass es schon repariert ist, nur weil die Edge-Version eine größere Versionsnummer hat. [4]
Die Migrationsschritte werden gemäß der offiziellen Ankündigung durchgeführt. Dabei gibt es zwei Stellen, an denen leicht etwas schiefgehen kann: Erst sicherstellen, dass es eine schriftliche Sicherung des alten Seeds und Wallet-Fingerprints gibt, bevor man loslegt. Außerdem zuerst eine kleine Test-Transaktion senden, um zu bestätigen, dass die neue Wallet nutzbar ist, und danach erst den Restbetrag übertragen. [4] Coinkite weist selbst darauf hin, dass das Risiko einer überstürzten Migration möglicherweise unmittelbarer ist als das ursprüngliche Problem. [4]
Datenhinweis: Das hier genannte Ausmaß des Diebstahls bezieht sich auf die bis zum 5. August nachverfolgten Daten. TRM macht klar, dass dies als vorläufige Zahlen zu betrachten ist – das Geld bewegt sich noch. Die vierte Welle ist zum Zeitpunkt der Bewertung noch im Mempool; Opfer entdecken den Diebstahl oft erst nach Monaten oder sogar Jahren. [1]
Der Autor baut gerade eine MPC-Wallet ohne Seed mit, daher bezieht er in diesem Thema Stellung. Alle Daten sind mit Quellen versehen – die Bewertung muss man selbst vornehmen.
https://cowallet.ai/en?pid=jingle