Verus Ethereum Bridge Exploit: Derselbe 11,58-Millionen-Dollar-Fehler
Am 18. Mai 2026 wurde die Verus-Ethereum-Bridge für 11,58 Millionen Dollar leergeräumt. Laut CoinDesks Berichterstattung war es der achte Bridge-Hack des Jahres. Der Verus-Ethereum-Bridge-Exploit nutzte keine exotische neue Angriffskategorie. Es war dasselbe Versagen, das Bridges seit 2021 das Leben kostet: Der Contract gab Mittel auf einer Chain frei, ohne korrekt zu verifizieren, was auf der anderen tatsächlich passiert war.
Die anfällige Funktion hatte diesmal einen Namen: checkCCEValues. Das ist die Routine, die bestätigen sollte, dass die Cross-Chain-Exportwerte der Realität entsprachen, bevor auf der Ethereum-Seite geminted oder freigegeben wurde. Sie tat ihren Job nicht, und der Angreifer entkam.
Ich habe vier Jahre damit verbracht, bridgenahe Infrastruktur in einem regulierten Umfeld aufzubauen, und das Deprimierende daran ist, wie vorhersehbar das alles geworden ist. Wir geben derselben Wunde immer neue Namen.
Der Verus-Ethereum-Bridge-Exploit war ein Quellvalidierungsfehler
Streicht man das Marketing weg, tut jede Bridge genau eine Sache. Sie beobachtet ein Ereignis auf Chain A (eine Einzahlung, ein Lock, ein Export) und erzeugt eine entsprechende Aktion auf Chain B (ein Mint, ein Unlock, eine Freigabe). Das gesamte Sicherheitsmodell reduziert sich auf eine einzige Frage: Glaubt Chain B wirklich, was Chain A ihr mitgeteilt hat, und hat sie das überprüft?
Wenn die Validierung, die die quellseitigen Beträge bestätigt, fehlerhaft ist, lautet die Antwort "Nein." Der Angreifer fälscht oder übertreibt den behaupteten Exportwert, der Ziel-Contract vertraut ihm, und Token, die nie gedeckt waren, werden geminted oder freigegeben. The Block berichtete den Verlust auf rund 11,58 Millionen Dollar, abgeschöpft durch genau diese Art von Bilanzierungslücke im Cross-Chain-Export-Check.
Das ist Quellbetrag-Validierung in einer Bridge, und es ist die tragende Funktion des gesamten Systems. Ein einziger falscher Vergleich, und die Bridge wird zur kostenlosen Gelddruckmaschine.
checkCCEValues ist nur der neueste Name für eine alte Schwachstelle
Die checkCCEValues-Schwachstelle ist strukturell identisch mit Bugs, die die Branche bereits Milliarden gekostet haben. Die Namen wechseln. Der Mechanismus nicht.
- Wormhole, 2022: Eine Lücke bei der Signaturverifizierung ermöglichte es einem Angreifer, 120.000 Wrapped ETH zu minten, die nie hinterlegt wurden.
- Nomad, 2022: Eine fehlerhafte Initialisierung des Merkle-Root sorgte dafür, dass jede Nachricht als gültig erkannt wurde, und die Bridge wurde von einer Menge per Copy-Paste leergeräumt.
- Multichain, 2023: Schlüssel und Vertrauensannahmen, die von außen niemand wirklich verifizieren konnte.
Jeder dieser Fälle war im Kern dasselbe: Die Zielkette gab Werte frei, ohne einen soliden Beweis für das Quellereignis zu haben. checkCCEValues ist die Schreibweise desselben Wortes im Jahr 2026.
Ich glaube, die Branche behandelt diese Vorfälle weiterhin als individuelle Engineering-Fehler, obwohl es sich um ein kategorisches Versagen handelt. Eine Kategorie lässt sich nicht beheben, indem man eine Funktion gründlicher auditiert.
Tornado Cash finanzierte den Angreifer, was etwas über die Absicht verrät
Das Wallet des Angreifers wurde vor dem Exploit über Tornado Cash aufgefüllt. Dieses Detail ist weniger für die Zuordnung relevant als für das, was es über die Vorbereitung aussagt. Das war kein Whitehat, der einen Contract testete und vom Ergebnis überrascht wurde. Das Muster eines über Tornado Cash finanzierten Angreifers ist das Kennzeichen von jemandem, der seine operative Deckung Tage im Voraus aufgebaut hat und davon ausging, dass die Gelder beim Herausschaffen gewaschen werden müssten.
Das ist der Teil, den Verteidiger unterschätzen. Wenn die Exploit-Transaktion eingeht, ist der Ausstiegsweg bereits gebaut. Nachträgliches Tracing hilft Staatsanwälten, nützt aber dem Protokoll, das gerade achtstellige Summen verloren hat, kaum etwas.
Bridge-Sicherheitslücken sind jetzt eine monatliche Abgabe
Tritt man einen Schritt zurück, ist der Verus-Hack ein Posten, kein Ausreißer. Laut von Bitcoin.com zitierten PeckShield-Daten beliefen sich Krypto-Bridge-Exploits allein im Mai 2026 auf rund 328 Millionen Dollar. Acht Bridge-Vorfälle in weniger als fünf Monaten des Jahres.
Der Markt hat das stillschweigend als Kosten des Cross-Chain-Geschäfts eingepreist. Das ist die falsche Lehre. Ein wiederkehrender neunstelliger monatlicher Verlust ist keine Volatilität, sondern ein struktureller Defekt, den der Designraum beharrlich ignoriert.
Für jeden, der echte Werte bewegt, ist die Schlussfolgerung unbequem: Die meisten Bridges sind Vertrauensannahmen im mathematischen Kostüm. Ich habe bereits in How Stablecoin Bridges Actually Fail argumentiert, dass die sicherste Bridge oft diejenige ist, die zugibt, wie wenig sie tatsächlich verifiziert.
Wie ein wirklich verteidigbarer Bridge-Check aussieht
Wenn du eine Bridge baust oder auditierst, ist die Quellbetrag-Validierung der Bereich, in dem du einen unverhältnismäßig großen Teil deiner Paranoia einsetzen solltest. Einige Dinge, die ich als nicht verhandelbar betrachten würde:
- Der Ziel-Contract muss einen kryptografischen Beweis des Quellereignisses verifizieren, nicht das Wort eines Relayers. Light-Client- oder ZK-Beweise gegenüber Multisig-Attestierungen, wo immer das Latenzbudget es erlaubt.
- Betragsprüfungen müssen auf jedem Pfad erschöpfend sein. Die
checkCCEValues-Klasse von Bugs versteckt sich üblicherweise in einem Zweig, den einige Eingaben überspringen. Führe Fuzzing für den Vergleich durch, verlasse dich nicht auf Augenschein. - Rate-Limits und Circuit-Breaker pro Asset, damit ein gefälschter Wert nicht die gesamte Reserve in einer einzigen Transaktion abschöpfen kann. Eine Obergrenze, die sich automatisch bei beispielsweise 5 % des TVL pro Stunde pausiert, hätte die meisten Vorfälle von 2026 abgemildert.
- Unabhängiges Invarianten-Monitoring, das den Gesamtbetrag der geminteten Token gegenüber dem gesperrten Gesamtbetrag in Echtzeit überwacht und bei Abweichungen stoppt.
Nichts davon ist neu. Das Audit-Stack zum Aufspüren dieser Fehler existiert, was ich in dem Audit-Stack-Artikel untersucht habe. Das Problem ist, dass Bridges die Validierung weiterhin als nachträglichen Gedanken liefern statt als das eigentliche Produkt.
Der nächste Bridge-Hack von 2026 wird bereits geschrieben. Er wird einen anderen Funktionsnamen und dieselbe Grundursache haben, und wir werden wieder überrascht tun. Das sollten wir nicht.