Krypto-Hacks im dritten Quartal 2026: 1,18 Milliarden Dollar verloren, und 77 % liefen an den Sicherheitsprüfungen vorbei

Zwischen dem 1. Juli und dem 28. September 2026 wurden bei 107 Vorfällen 1.180,8 Millionen Dollar gestohlen, 55 % mehr als im zweiten Quartal. Das meldet Hacken, ein Unternehmen für Blockchain-Sicherheit, in seinem Quartalsbericht. Nicht die Gesamtsumme verdient genaues Lesen. Laut Hacken liefen 77 % der Verluste, 906,8 Millionen, über einen kompromittierten Lieferanten, eine bereits öffentliche, aber noch nicht ausgerollte Korrektur oder eine Komponente außerhalb der letzten Sicherheitsprüfung. Dieser Beitrag geht die Fälle einzeln durch, stützt sich wo möglich auf Primärquellen und trennt Dokumentiertes von bloßen Schätzungen.

Das Quartal in Hackens Zahlen

Der Bericht deckt den Zeitraum vom 1. Juli bis 28. September 2026 ab. Die wichtigsten Zahlen, alle aus Hackens Dokument:

• 1.180,8 Millionen Dollar gestohlen bei 107 Vorfällen, wertmäßig 55 % mehr als im zweiten Quartal.
• Anwendungs-Smart-Contracts machten 71 der 107 Vorfälle aus, aber nur 228,2 Millionen, 19 % der Verluste. Der größte Teil des Werts floss über Code auf Chain-Ebene, Lieferanten, Verwahrung und Wallets ab.
• Nach Angriffsart ordnet Hacken 48 % der Verluste Smart-Contract-Exploits zu und 40,4 % (477,6 Millionen) Zugriffskontrolle und betrieblichen Fehlern.
• Die weltweit verhängten Bußgelder gegen Krypto-Dienstleister beliefen sich auf nur 450.000 Dollar.

Ein vorsichtiger Vergleich: Andere Beobachter zählen für denselben Zeitraum andere Zahlen, weil Stichtage, Aufnahmeschwellen und Bewertungsmethoden abweichen. Sekundärberichte nennen etwa für CertiK rund 1,26 Milliarden. Wir haben diesen Bericht nicht selbst gelesen und erwähnen ihn nur als Größenordnung. Entscheidend ist, dass die Schätzungen bei einem Quartal nahe 1,2 Milliarden zusammenlaufen.

Die 77 %: drei Wege, elf Vorfälle

Hackens Tabelle ist der Kern des Dokuments. Sie besagt, dass drei Angriffswege den Großteil der Verluste in nur 11 Vorfällen bündelten:

Zwei Hinweise zum richtigen Lesen. Erstens heißt 77 % nicht „77 % Schuld der Lieferanten“. Kompromittierte Lieferanten sind der erste Weg, mit 35 %. Die anderen beiden betreffen bereits öffentliche, aber nicht angewandte Korrekturen und Komponenten, die keine aktuelle Prüfung abgedeckt hatte. Wer „77 % der Hacks kommen von Lieferanten“ zitiert, liest die Tabelle falsch. Zweitens übertreffen zwei Lieferantenvorfälle allein, 411,5 Millionen, die übrigen 96 Vorfälle zusammen (274,0 Millionen). Diese Schieflage, mehr als die Gesamtsumme, erklärt, warum das Thema wichtig ist.

Noch ein Hinweis für alle, die die Fälle verfolgen: Die Drei-Wege-Tabelle enthält Coldcard nicht. Hacken behandelt den Fall getrennt, im Abschnitt über Vorfälle, bei denen frühere Prüfungen die Bedingungen des Problems übersehen haben. Wir kommen weiter unten darauf zurück.

Bitget: 387,5 Millionen über ein Sicherheitsprodukt eines Drittanbieters

Was dokumentiert ist. Am 24. September 2026 um 18:31 UTC begann ein Angreifer mit unautorisierten Überweisungen aus bestimmten Hot- und Warm-Wallets von Bitget. Um 19:05 meldete das Abgleichsystem die Auffälligkeit, und die Risikokontrolle blockierte automatisch die Auszahlungen. So steht es auf Bitgets offizieller Vorfallseite. Hacken beziffert den Diebstahl auf 387,5 Millionen Dollar über 11 Blockchains, darunter Ethereum, XRP Ledger, TRON, Arbitrum, Base und BNB Chain, wobei XRP mit etwa 158 Millionen der größte Einzelwert war. Bitget nennt eine „final verifizierte“ Zahl von rund 388 Millionen über 12 Adressen.

Wie, laut Bitget. Das Unternehmen sagt, der Angreifer habe eine Zero-Day-Schwachstelle in einem Sicherheitsprodukt eines Drittanbieters ausgenutzt, interne Zugangsdaten mit hohen Rechten erlangt und gefälschte Auszahlungsbefehle in das Wallet-System geschrieben, das sie als normale Auszahlungen behandelte und die Risikokontrollen umging. Nach den Überweisungen, so Bitget, löschten die Täter Spuren. Private Schlüssel und Cold Wallets seien, sagt die Börse, nicht betroffen gewesen. Am 30. September veröffentlichte Bitget zwei unabhängige Berichte von Mandiant (Google Cloud) und SlowMist, die nach seiner Darstellung den Angriffsweg bestätigen. Hacken ergänzt, dass die von Bitget freigegebenen Berichte den Einstieg im Drittanbieterprodukt verorten und die früheste bösartige Aktivität in den verfügbaren Logs auf den 31. August datieren, fast vier Wochen vor dem Diebstahl.

Was nicht dokumentiert ist. In den Quellen, die wir lesen konnten, wird der Hersteller des Produkts nicht genannt. Wir können daher keinem bestimmten Unternehmen Verantwortung zuschreiben und tun es nicht. Hacken berichtet außerdem, Bitget halte eine nordkoreanische Beteiligung für „sehr wahrscheinlich“ und verweise auf das Verhalten von IP-Adressen. Das ist die Einschätzung einer Partei, keine von einer Behörde bestätigte Zuschreibung, und wir geben sie als solche wieder. Die Berichte von Mandiant und SlowMist haben wir nur über Bitgets Seite und Hackens Bericht gelesen.

Die Nutzer. Bitget erklärt, die Nutzersalden seien unberührt geblieben und der Schaden werde aus dem eigenen Schutzfonds gedeckt. Hacken verzeichnet, dass Betreiber rund 410 Millionen Dollar für Nutzer aus eigenen Mitteln abdeckten, davon 387,5 Millionen aus Bitgets Nutzerschutzfonds. Die Auszahlungen wurden stufenweise wiederhergestellt: BTC am 28. September, ETH am 29., USDT am 30., der Rest am 2. Oktober. Ein Lesehinweis: Bitgets Seite nennt für den Schutzfonds an verschiedenen Stellen unterschiedliche Zahlen (im Kopf 3.705 BTC und über 314 Millionen Dollar, in den FAQ 5.500 BTC und über 464 Millionen). Sie können sich auf verschiedene Zeitpunkte beziehen, aber wer die Zahl prüfen will, sollte die von der Börse angegebenen On-Chain-Adressen ansehen, nicht die Zusammenfassung.

Die Rückholung. Laut Hacken froren Circle und Tether aus dem Bitget-Diebstahl nur rund 0,34 Millionen Dollar ein. Die Nachverfolgung der Gelder, sagt Bitget, laufe weiter, und das Unternehmen bietet 5 % Belohnung auf eingefrorene oder zurückgeholte Beträge, die über gemeldete Hinweise ermittelt wurden.

Liquid Network: 36 Minuten und eine halbe Korrektur

Liquid ist der Fall, der Hackens zweiten Weg, „öffentliche Korrektur vor dem Rollout ausgenutzt“, am besten zeigt. Der Ablauf, aus dem Bericht und aus dem Repository der Software Elements, auf der Liquid aufbaut:

• 1. September: Eine Teilkorrektur, die den Transaktionskontext in den Cache-Schlüssel aufnimmt, ist im Elements-Repository öffentlich. Sie lässt die Kodierung jedoch mehrdeutig.
• 6. September: Ein Angreifer nutzt die Mehrdeutigkeit im Cache der Range-Proof-Prüfung aus, also der Prüfungen, die die Gültigkeit eines Betrags beweisen, ohne ihn zu offenbaren. Ein für einen Asset und Kontext validierter Beweis wird für einen anderen wiederverwendet. Ergebnis: 3.998,5 L-BTC ohne zugehörige BTC geprägt. Eine Peg-out-Transaktion über rund 4.000 BTC wird anschließend auf Bitcoin bestätigt.
• 7. September: Der Angreifer, der sich als White Hat bezeichnet, gibt rund 3.400 BTC (272 Millionen Dollar) unter der Bedingung zurück, dass der Fehler behoben wird, und behält 598,5 BTC, etwa 47 Millionen, als selbst zugewiesene Belohnung.
• 8. September: Die vollständige Korrektur wird eingepflegt (Pull Request Nr. 1600 im Elements-Repository, von uns geprüft). 9. September: Elements 23.3.4 erscheint.

Zwei Vorbehalte. Die Rückgabe von 85 % ist ein von Hacken dokumentiertes Faktum, aber „White Hat“ ist die Selbstbezeichnung des Angreifers, kein Urteil Dritter: In den von uns gelesenen Quellen findet sich keine vorherige Genehmigung, diese 47 Millionen zu behalten, und sie Belohnung zu nennen ist die Definition des Angreifers selbst. Zweitens betrifft Hackens Lehre den Umgang mit dem Korrekturzyklus: Zwischen dem öffentlichen Teilpatch und dem Release der endgültigen Korrektur lagen acht Tage. Die öffentlichen Aufzeichnungen zeigen die Chronologie, sie legen nicht fest, wie der Angreifer den Fehler fand, und wir behaupten es nicht.

Tectonic und Cronos: ein korrekter Preis, den man nicht nutzen konnte

Am 30. August manipulierte ein Angreifer, laut dem von Cronos veröffentlichten und von crypto.news wiedergegebenen Post-Mortem, den Preis von TONIC, dem dünn gehandelten Governance-Token des Kreditprotokolls Tectonic, und nutzte ihn als Sicherheit, um 120,4 Millionen Dollar über neun Märkte zu leihen. Hacken ergänzt, der Preis sei in etwa 11 Minuten gegen dünne Liquidität hochgetrieben worden und Tectonic habe den aufgeblähten Preis als Sicherheitenwert akzeptiert.

Der Punkt, den Hacken aus den veröffentlichten Parametern des Protokolls ableitet: Keine von drei Kontrollen, die es hätten stoppen können, war vorhanden, nämlich ein Limit für die Liquiditätstiefe, ein Limit für die Geschwindigkeit, mit der die Kreditkapazität dem Spotpreis folgen darf, und eine funktionierende Kreditobergrenze. Tectonics Parameter nennen für jeden Markt eine Kreditobergrenze von 0, und im von Compound abgeleiteten Code bedeutet null „keine Obergrenze“. Der Mitgründer von RedStone, Marcin Kazmierczak, sagte crypto.news, es sei kein Orakelversagen gewesen: Das Orakel meldete den Preis des beobachteten Marktes korrekt, und das Protokoll akzeptierte ihn, ohne zu prüfen, ob genug Liquidität vorhanden war, um die Sicherheit zu diesem Wert zu verkaufen. Tectonics Code hatte vier Audits durchlaufen, eines davon zur zentralen Kreditlogik. Hacken zieht eine wichtige Unterscheidung: Die Prüfung, ob ein Vertrag Sicherheiten korrekt berechnet, belegt nicht, dass die Parameter eines einzelnen Sicherheiten-Assets in seinem realen Markt sicher sind. Das nennt die Tabelle eine „Komponente außerhalb der letzten Prüfung“.

Die Reaktion war ungewöhnlich. Die Validatoren von Cronos hielten die Chain bei Block 90.907.150 an und setzten sie auf Block 90.896.188 zurück, den letzten vor dem Angriff, und verwarfen 10.961 Blöcke, also 1 Stunde und 54 Minuten Geschichte. Rund 111,2 Millionen der betroffenen 120,4 Millionen wurden rückgängig gemacht. 9,19 Millionen (7,6 %), die die Chain bereits verlassen hatten, bleiben außer Reichweite. Das Cronos-Post-Mortem räumt ein, es sei eine „schwere Entscheidung“ gewesen, und der Rollback habe auch die Transaktionen gewöhnlicher Nutzer im selben Zeitfenster gelöscht. Der Preis der Rückholung war, in diesem Fall, die Unumkehrbarkeit der aufgezeichneten Geschichte aufzugeben, ein Prinzip, das viele für öffentliche Blockchains als zentral ansehen. Hacken nennt das eine regulatorische Lücke: Keiner der geprüften Rahmen verlangt von Unternehmen, offenzulegen, ob die Abwicklung auf einer Chain rückgängig gemacht werden kann.

Coldcard: ein Build-Fehler, der fünf Jahre überlebte

Hier beschreibt Hacken keinen kompromittierten Lieferanten. Coldcard betrifft Entropie, also die Zufälligkeit, mit der Seeds erzeugt werden. Deshalb behandeln wir den Fall getrennt von der 77-%-Tabelle und halten ihn vom Ledger-Fall auseinander, der ein Angriff auf die Auslieferung ist, kein Konstruktionsfehler.

Was der Hersteller sagt. Coinkite, der Hersteller von Coldcard, veröffentlichte eine technische Analyse. Laut dem Unternehmen führte eine Änderung von 2021 beim Wechsel zu einer Bibliothek für Operationen auf elliptischen Kurven dazu, dass die Seed-Erzeugung auf den Software-Pseudozufallsgenerator von MicroPython zurückgriff statt auf den Hardware-Generator. Coinkite beschreibt einen Integrationsfehler beim Bauen und Linken, keine Konstruktionsentscheidung: In seinen Worten gab es „keinen beabsichtigten Fallback“ auf einen schwachen Generator. Die Codeprüfung testete, ob eine Einstellung definiert war, statt ob sie aktiviert war, sodass der Build nicht stoppte. Betroffen sind die Firmware 4.0.1 bis 4.1.9 für Mk2 und Mk3 sowie die entsprechenden Versionen für spätere Modelle. Coinkite schätzt vorläufig einen effektiven Suchraum von etwa 40 Bit bei Mk2 und Mk3 und etwa 72 Bit bei Mk4, Mk5 und Q, gegenüber den 128 Bit, die für einen 12-Wörter-Seed vorgesehen sind. Das Unternehmen erklärt außerdem, die Geräte seien nicht gehackt oder aus der Ferne übernommen worden: Die Angreifer hätten die zugehörigen Schlüssel offline neu erzeugt.

Was die Diebstahlsdaten sagen. Die ersten Abflüsse begannen am 30. Juli. TRM Labs zählte in einer Analyse vom 5. August bereits rund 1.816 BTC (etwa 116 Millionen Dollar) von mehr als 5.200 Adressen in vier Wellen, unter Berufung auf die Zählung von Galaxy Research, und betonte, die Daten seien vorläufig und die Transaktionsmuster deuteten auf mehr als einen Angreifer hin: TRM ordnete den Diebstahl keinem bestimmten Akteur zu. In seinem späteren Bericht nennt Hacken 1.789,28 BTC über 8.865 Adressen, die Galaxy Research dem Vorfall zuordnet, etwa 114,7 Millionen Dollar zum Diebstahlszeitpunkt, und beziffert die Verluste auf rund 115 Millionen. Die Zahlen unterscheiden sich, weil Stichtag und Methode verschieden sind. Anfang August kursierte unter externen Forschern eine Schätzung von etwa 130 Millionen; Coinkite sagte, es werde nicht über das Ausmaß der Verluste spekulieren und eine vollständige Analyse veröffentlichen, sobald das sicher möglich sei.

Der Punkt, der für diese Recherche zählt. Hacken schreibt, eine bezahlte Prüfung vom März 2022 habe die Härtung der Entropie abgedeckt, aber die Build-Bedingung nicht erkannt. Coinkite bestätigt das im Kern: Die bestehende Prüfung „bestätigte, dass die vorgesehene TRNG-Implementierung im Firmware-Binary vorhanden war, prüfte aber nicht, welche Implementierung der Pfad der Seed-Erzeugung tatsächlich erreichte“. Das ist das Thema des Berichts: Eine Prüfung, die die richtige Komponente ansieht, kann die falsche Verbindung übersehen. Der Defekt, so Hacken, blieb mehr als fünf Jahre unentdeckt. Coinkite fügt hinzu, wenige Wochen vor dem Vorfall habe es eines der besten verfügbaren KI-Modelle zur Prüfung seines Codes eingesetzt, und es habe das Problem nicht gefunden. Das ist die Aussage des Unternehmens; wir haben sie nicht überprüft.

Was es für Besitzer heißt. Ein Firmware-Update repariert bereits erzeugte Seeds nicht. Laut Coinkite sind Seeds, die auf betroffener Firmware ohne mindestens 50 unabhängige, private Würfelwürfe und ohne starke, einzigartige BIP-39-Passphrase erzeugt wurden, als gefährdet zu betrachten und zu ersetzen, indem man auf korrigierter Firmware einen neuen Seed erzeugt und die Gelder verschiebt. Seeds, die mit mindestens 50 Würfelwürfen erzeugt wurden, hält das Unternehmen allein durch diesen Fehler nicht für gefährdet. Die vollständigen Anweisungen stehen in seinem offiziellen Hinweis: Folgen Sie ihnen von dort, nicht einer Zusammenfassung.

Nicht in den Quartalsdaten: der Fall Ledger

Hackens Zeitraum endet am 28. September. Der Vorfall Ledger/CryptoBilis stammt aus dem Oktober: Die ersten Abflüsse wurden am 9. Oktober gemeldet, und zu den Verlusten gibt es nur Schätzungen Dritter, zwischen 86 und 103 Millionen Dollar. Er steckt also nicht in den Zahlen dieses Beitrags, und Ledger hat keine Gesamtsumme veröffentlicht. Es ist aber dasselbe Muster in anderer Form: Ein Teil der Kette, hier der Vertrieb, liegt außerhalb dessen, was Sicherheitsprüfungen untersuchen. Wir haben den Fall, mit dem, was bestätigt ist und was nicht, in unserem Beitrag Ledger-LTE-Implantat: Was bestätigt ist und was nicht rekonstruiert.

Eine Stelle in Hackens Bericht verbindet die beiden Welten. Die Analyse europäischer Vorschriften stellt fest, dass keiner der untersuchten Rahmen Geräte abdeckt, die Kunden für die Selbstverwahrung kaufen, und dass DORA einen Hardwarelieferanten nur erreicht, wenn er Dienstleistungen für ein reguliertes Unternehmen erbringt. Der Coldcard-Defekt, so Hacken, blieb mehr als fünf Jahre unentdeckt. Wer heute eine Hardware-Wallet kauft, steht praktisch außerhalb fast aller regulatorischen Schutzvorkehrungen für die Sicherheit der Komponenten.

Rückholung: ein Drittel, über sehr verschiedene Mechanismen

Hacken berechnet, dass etwa 387 Millionen Dollar, 33 % der Bruttoverluste, zurückgegeben oder rückgängig gemacht wurden. Der Bericht unterscheidet drei Mechanismen, die verschieden funktionieren und nicht gleichwertig sind:

• Rückgabe durch den Angreifer: 272 Millionen (Liquid Network, 85 % der 319 entwendeten Millionen). Sie hängt vollständig vom Willen dessen ab, der die Gelder genommen hat.
• Eingriff in den Chain-Zustand: rund 116 Millionen, darunter der Cronos-Rollback (111,2 Millionen der betroffenen 120,4), eine Snapshot-Wiederherstellung bei BounceBit und die Sicherstellung von 2,1 Millionen in ATOM auf dem Cosmos Hub. Sie hängt von Validatoren ab und kostet Finalität.
• Einfrieren durch Emittenten: rund 0,34 Millionen (Circle und Tether, aus dem Bitget-Diebstahl). Sie hängt vom Emittenten und von der Geschwindigkeit ab.

Zusätzlich deckten Betreiber rund 410 Millionen Dollar für Nutzer aus eigenen Mitteln ab; diese Nutzer wurden entschädigt, während die gestohlenen Werte bei den Angreifern blieben. Das Bild ist klar: Die echte Rückholung vom Markt war klein, und das Sicherheitsnetz war vor allem die Bilanzstärke derer, die die Gelder verwalteten.

Was Regulierer tun, laut Hacken

Der regulatorische Teil des Berichts ist kürzer, enthält aber zwei Signale. Erstens beginnen Regulierer zu prüfen, ob Kontrollen im laufenden Betrieb halten und nicht nur zu einem einzelnen Prüfzeitpunkt. Zweitens merkt Hacken an, dass Regulierer zunehmend bestimmte Gründer und Führungskräfte persönlich für Exploits und Vorfälle verantwortlich machen. Die weltweiten Bußgelder gegen Krypto-Dienstleister, 450.000 Dollar, sind winzig neben 1,18 Milliarden Diebstahl. Wir weisen auf den Vergleich hin, ohne daraus ein Urteil über das Sanktionssystem zu ziehen: Es sind Daten über verschiedene Dinge (verhängte Sanktionen und erlittene Verluste) und verschiedene Rechtsordnungen.

Was es für Sie bedeutet

Dieser Abschnitt ist allgemeine Information, keine Finanzberatung.

Wenn Sie Guthaben auf einer Börse halten

Der Fall Bitget zeigt, dass ein Reservenachweis das eine misst und ein Angriff etwas anderes trifft. Ein Proof of Reserves sagt, ob die Börse genug Vermögen ausweist, um die Salden zu decken; über den Schutz interner Zugänge und Auszahlungssysteme sagt er nichts. Er bleibt ein nützliches Werkzeug, beantwortet aber nicht die Frage, wie ein Unternehmen seine Lieferanten steuert. Wie man ihn liest und prüft, erklären wir in unserem Leitfaden zum Proof of Reserves. In diesem Quartal wurden Nutzer der betroffenen Börsen laut Hacken von den Betreibern entschädigt: Das ist keine Garantie für alle künftigen Fälle, sondern eine beobachtete Tatsache dieses Zeitraums.

Wenn Sie selbst verwahren

• Wenn Sie eine Coldcard besitzen, prüfen Sie Coinkites offiziellen Hinweis für Ihr Modell und das Erstellungsdatum Ihres Seeds. Ein Firmware-Update genügt nicht.
• Wenn Sie eine Hardware-Wallet kaufen, kaufen Sie beim Hersteller und misstrauen Sie inoffiziellen Kanälen. Der Fall Ledger ist der Beleg.
• Verlassen Sie sich bei einem großen Betrag nicht auf ein einzelnes Gerät. TRM Labs merkt zum Fall Coldcard an, dass Multisignature-Aufbauten, die unabhängig entworfene Geräte und unabhängig erzeugte Entropie kombinieren, eine gestaffelte Verteidigung bieten, weil sie die Abhängigkeit von einer einzigen Implementierung verringern. Das ist ein Aufbau, der Sorgfalt braucht: Unsere Anleitung zur 2-von-3-Multisig-Wallet erklärt, wie. Und denken Sie daran, dass ein vollständiger Verwahrplan auch regelt, wer an die Gelder kommt, wenn Sie es nicht können: der Bitcoin-Nachlassplan.

Wenn Sie dezentrale Finanzen nutzen

Der Fall Tectonic handelt nicht von falschem Code im engeren Sinn. Er handelt von den Parametern eines einzelnen Assets in einem Kreditprotokoll. Wenn ein Protokoll einen dünn gehandelten Token als Sicherheit akzeptiert, kann der „korrekte“ Preis ein nicht nutzbarer Preis sein. Bevor Sie in ein Protokoll einzahlen, lohnt es sich zu wissen, welche Assets es als Sicherheit akzeptiert und ob reale Kreditgrenzen bestehen, nicht auf null gesetzt.

Was wir noch nicht wissen

• Den Namen des Herstellers des von Bitget genutzten Sicherheitsprodukts. In den konsultierten Quellen taucht er nicht auf.
• Die Identität der Angreifer bei Bitget, Liquid, Tectonic und Coldcard. Bitget hält eine nordkoreanische Verantwortung für wahrscheinlich, aber das ist die Einschätzung einer Partei.
• Die endgültige Bilanz bei Coldcard: TRM und Hacken nennen die Daten beide vorläufig, und Coinkite muss seine vollständige Analyse noch veröffentlichen.
• Ob die Berichte von Mandiant und SlowMist zu Bitget vollständig veröffentlicht werden. Wir haben sie nur in den Zusammenfassungen von Bitget und Hacken gelesen.
• Den Teil der Quartalsverluste, der noch nicht erfasst ist. Hacken und TRM warnen, dass Opfer oft erst nach Monaten auftauchen.
• Wie weit Hackens Entscheidung, als Anbieter von Sicherheitsprüfungen Verluste als „außerhalb der letzten Prüfung“ einzuordnen, davon abhängt, wie es seine Kategorien gezogen hat. Die Einteilung ist seine eigene, und ein anderer Analyst könnte die Grenzen anders ziehen.

Unsere Einschätzung

Die dokumentierten Fakten sagen etwas Präzises und Unbequemeres als die übliche Erzählung über Hacks. Im dritten Quartal 2026 floss der größte Teil des Geldes nicht über einen schlecht geschriebenen Vertrag ab, sondern über Stellen der Kette, die keine Prüfung im Blick hatte: das Sicherheitswerkzeug eines Lieferanten, einen Fehler, dessen Korrektur öffentlich, aber unvollständig war, einen Risikoparameter, eine Zeile Compiler-Konfiguration. Anwendungs-Smart-Contracts, das klassische Ziel von Audits, verursachten die meisten Vorfälle, aber nur 19 % der Verluste.

Das macht Audits nicht nutzlos, und es erlaubt nicht, den Lieferanten die Schuld zu geben. Wer eine Börse oder ein Protokoll betreibt, wählt seine Lieferanten, und Hacken selbst merkt an, dass Prüfungen Komponenten nicht abdeckten, die dennoch Preise, Nachrichten, Governance oder Kredite berühren konnten. Für den gewöhnlichen Leser ergibt sich ein praktischer Test: Die Frage an einen Dienst lautet nicht nur „wurde er geprüft?“, sondern „was wurde nicht geprüft?“. Wenige Betreiber beantworten diese zweite Frage ausdrücklich, und die Daten dieses Quartals legen nahe, dass sie die wichtigere ist.

Wir aktualisieren diesen Beitrag, wenn Coinkite seine vollständige Analyse veröffentlicht, wenn Bitget die unabhängigen Berichte offenlegt oder den beteiligten Hersteller nennt oder wenn Hacken seine Zahlen korrigiert.

Häufig gestellte Fragen