Der 11,5‑Millionen‑Dollar‑Exploit der Verus‑Ethereum‑Bridge erklärt

Anschließend tauschte der Angreifer die Assets und bündelte sie zu etwa 5.402 ETH, vermutlich um die spätere Weiterbewegung oder Verschleierung der Gelder zu erleichtern.

Warum die kryptografischen Beweise trotzdem gültig wirkten

Der ungewöhnliche Teil dieses Hacks: Die zugrunde liegende Kryptografie der Bridge scheint korrekt funktioniert zu haben.

Die Verus‑Bridge nutzte sogenannte notarisierte State Roots und Merkle‑Beweise, um zu bestätigen, dass eine bestimmte Transaktion auf der Ursprungs‑Blockchain stattgefunden hat, bevor auf Ethereum eine Auszahlung erlaubt wird.

Ein Merkle‑Proof bestätigt jedoch nur eines:

• dass ein bestimmter Dateneintrag tatsächlich in einem Block oder State‑Tree enthalten war.

Er bestätigt nicht automatisch, dass diese Daten wirtschaftlich korrekt sind oder durch hinterlegte Vermögenswerte gedeckt werden.

Genau hier lag die Schwachstelle.

Laut Untersuchungen prüfte der Bridge‑Contract zwar korrekt:

• notarisierten State Root
• Merkle‑Inklusionsbeweis

Aber er überprüfte nicht, ob die behauptete Transfermenge tatsächlich durch gesperrte Assets auf der Ursprungs‑Chain gedeckt war.

Das bedeutete: Ein Angreifer konnte Cross‑Chain‑Transferdaten konstruieren, die kryptografisch gültig aussahen – aber eine größere Auszahlung auslösten als tatsächlich hinterlegt war.

Kurz gesagt: Der Beweis bestätigte die Nachricht, doch der Smart Contract prüfte nicht ausreichend, ob diese Nachricht die Auszahlung wirklich autorisierte.

Die fehlende Validierungsprüfung

Sicherheitsforscher ordnen den Fehler als klassische Business‑Logic‑Schwachstelle ein.

Der Ethereum‑Contract hätte laut Analyse zusätzliche Prüfungen durchführen müssen, etwa ob folgende Werte exakt mit dem Transfer auf der Ursprungs‑Chain übereinstimmen:

• Token‑Typ
• Transfermenge
• Empfängeradresse
• interner Kontostand bzw. Accounting‑Status der Bridge

Da diese Kontrolllogik fehlte, konnten Auszahlungen erfolgen, ohne dass entsprechende Einzahlungen existierten.

Berichten zufolge musste der Angreifer auf der Verus‑Seite lediglich Transaktionsgebühren von etwa 10 Dollar in VRSC bezahlen, um Auszahlungen im Wert von Millionen auf Ethereum auszulösen.

Da es sich um einen Logikfehler und nicht um gebrochene Kryptografie handelt, arbeiteten Entwickler laut Berichten bereits an einem Solidity‑Patch, um die Lücke zu schließen.

Parallelen zu früheren Bridge‑Hacks

Der Vorfall passt in ein bekanntes Muster mehrerer großer DeFi‑Bridge‑Angriffe.

Wormhole (2022)

Beim Wormhole‑Hack im Februar 2022 gelang es einem Angreifer, 120.000 Wrapped ETH (wETH) zu erzeugen – damals mehr als 320 Millionen US‑Dollar wert – nachdem die Signaturprüfung der Bridge umgangen wurde.

Das System wurde dadurch dazu gebracht zu glauben, dass Sicherheiten hinterlegt wurden, obwohl das nicht der Fall war.

Nomad (2022)

Der Nomad‑Bridge‑Hack im August 2022 führte zu Verlusten von etwa 190 Millionen US‑Dollar. Eine Konfigurationsänderung führte dazu, dass Nachrichten praktisch automatisch als gültig akzeptiert wurden, wodurch Angreifer Transaktionen kopieren oder fälschen konnten.

Einordnung des Verus‑Angriffs

Der Verus‑Exploit ähnelt in seiner Struktur eher dem Nomad‑Fall:

• Nachrichten oder Beweise wurden als gültig akzeptiert
• doch die Logik, die deren Bedeutung prüfen sollte, war fehlerhaft

Das Ergebnis war in beiden Fällen gleich: nicht gedeckte Auszahlungen aus den Bridge‑Reserven.

Warum Cross‑Chain‑Bridges besonders riskant bleiben

Bridges gehören weiterhin zu den am häufigsten angegriffenen Komponenten im DeFi‑Ökosystem. Der Grund ist ihre komplexe Architektur. Sie kombinieren mehrere kritische Systeme gleichzeitig:

• kryptografische Beweisprüfung
• Cross‑Chain‑Nachrichtenübermittlung
• Smart‑Contract‑Accounting
• Verwahrung großer Asset‑Reserven

Versagt auch nur ein einzelner Schritt in dieser Validierungskette, kann das System Auszahlungen autorisieren, die nicht durch reale Sicherheiten gedeckt sind.

Der Verus‑Fall unterstreicht eine zentrale Design‑Lehre für DeFi:

„Beweis verifiziert“ bedeutet nicht automatisch „Transfer gültig“.

Smart Contracts müssen zusätzlich strikt prüfen, ob Betrag, Asset‑Typ, Empfänger und Kontostände tatsächlich zusammenpassen.

Was als Nächstes passiert: Rückerstattung und Versicherung

Zum Zeitpunkt der ersten Berichte waren Details zu möglichen Rückerstattungen oder Recovery‑Plänen noch begrenzt. Einige Meldungen betonten, dass offizielle Stellungnahmen oder vollständige Incident‑Reports zunächst noch ausstanden.

Ob Nutzer entschädigt werden können, hängt typischerweise von mehreren Faktoren ab, etwa:

• Projekt‑Treasury oder Reservefonds
• Governance‑Entscheidungen der Community
• mögliche Verhandlungen mit dem Angreifer
• DeFi‑Versicherungen oder Drittanbieter‑Cover

Für Versicherungsanbieter im DeFi‑Bereich stellt sich erneut die Frage, ob solche Vorfälle als Smart‑Contract‑Bug, Infrastrukturfehler oder Design‑Risiko eingestuft werden.

Die wichtigste Lehre für DeFi

Der Angriff auf die Verus‑Ethereum‑Bridge zeigt ein wiederkehrendes Muster im DeFi‑Sektor: Die gefährlichsten Schwachstellen entstehen oft nicht durch gebrochene Kryptografie, sondern durch kleine Fehler in der Geschäftslogik eines Smart Contracts.

Ein Bridge‑System kann Signaturen, State Roots und Merkle‑Beweise vollkommen korrekt verifizieren – und dennoch angreifbar sein, wenn der Contract nicht prüft, ob die bewiesenen Daten tatsächlich die ausgeführte Auszahlung rechtfertigen.

Diese scheinbar kleine Unterscheidung hat die DeFi‑Branche bereits Milliarden gekostet. Der Verus‑Exploit ist ein weiteres Beispiel dafür, wie entscheidend saubere Accounting‑Logik in Cross‑Chain‑Systemen ist.