ZetaChains Bug wurde von einem White Hat gemeldet, als „erwartet" abgetan und trieb später einen Exploit im Wert von 334.000 US-Dollar an
ZetaChains Bug wurde von einem White Hat gemeldet, als „erwartet" abgetan und trieb später einen Exploit im Wert von 334.000 US-Dollar an
Ende April 2026 bewies die Cross-Chain-Infrastruktur einmal mehr, wie kleine Designannahmen zu übermäßigen Risiken führen können. ZetaChain bestätigte, dass ein Angreifer durch eine Kette von Schwachstellen, die die Initiierung von Nachrichten, die Ausführungsregeln auf der Zielkette und langlebige ERC-20-Berechtigungen umfassten, rund 334.000 US-Dollar aus von Protokollen kontrollierten Wallets abgezogen hat. Die Gelder der Nutzer waren nicht betroffen, aber der Vorfall ist dennoch eine deutliche Mahnung: In Cross-Chain-Systemen bleiben „risikoarme“ Komponenten selten risikoarm, wenn sie interagieren.
Was diesen Fall besonders lehrreich macht, ist das Prozessversagen hinter dem technischen Versagen. ZetaChain räumte ein, dass das Kernproblem zuvor über seinen Bug-Bounty-Kanal gemeldet worden war, jedoch zunächst als beabsichtigtes Verhalten und nicht als etwas behandelt wurde, das eine Abhilfemaßnahme oder strengere Beschränkungen erforderte. Berichte über die Offenlegung und Details nach dem Vorfall sind in Artikeln wie dem Rückblick von Cointelegraph auf die abgelehnte Meldung und den anschließenden Exploit zu finden: ZetaChain hat einen Bug-Report abgelehnt, der den Exploit hätte verhindern können.
Nachfolgend finden Sie eine benutzerfreundliche Aufschlüsselung dessen, was passiert ist, warum der Exploit-Pfad funktionierte, was ZetaChain geändert hat und was Entwickler und Nutzer im Jahr 2026 mitnehmen sollten – wenn die Cross-Chain-Aktivität breiter ist als je zuvor und die Angreifer-Playbooks zunehmend standardmäßig „Multi-Vektor“ sind.
Vorfall-Momentaufnahme: Cross-Chain-Designschulden kommen zum Tragen
Die Handlungen des Angreifers führten letztendlich zu 9 Transaktionen, die sich über Ethereum, Arbitrum, Base und BNB Smart Chain erstreckten, wobei die gestohlenen Vermögenswerte aus von ZetaChain kontrollierten Wallets und nicht von Endnutzern stammten. ZetaChain pausierte die Cross-Chain-Operationen, während das Problem eingedämmt wurde; die anfängliche Unterbrechung wurde weithin berichtet, als der Vorfall erstmals öffentlich bekannt wurde (siehe: Bericht von The Block über die Pause und Abhilfemaßnahmen).
Obwohl der Dollarbetrag nicht die Größenordnung eines „Bridge-Mega-Hacks“ erreichte, ist das Muster entscheidend: Ein Cross-Chain-Gateway, das beeinflusst werden kann, um protokollsignierte Aufrufe auf externen Ketten zu erzeugen, ist ein Ziel mit hohem Hebel, auch wenn die unmittelbare Gruppe der Opfer begrenzt ist.
Die unbequeme Lektion: „Erwartetes Verhalten“ kann immer noch ausnutzbares Verhalten sein
Bug-Bounty-Programme sollen die Neugier von Gegnern in defensive Verbesserungen umwandeln – aber nur, wenn die Triage so aufgebaut ist, dass das Kompositionsrisiko erkannt wird.
ZetaChain hat sein Bounty-Programm zuvor in Partnerschaft mit Immunefi gestartet (Hintergrund: Ankündigung des Bug-Bounty-Programms von ZetaChain). Dieser Vorfall unterstreicht jedoch eine wiederkehrende Herausforderung in der Branche: Ein Bericht kann „korrekt“ sein, auch wenn jede einzelne Komponente isoliert betrachtet nicht kritisch erscheint. Immunefi selbst betont, dass reale Auswirkungen und Umfangsdefinitionen wichtig sind (siehe: Leitfaden von Immunefi zu Programmregeln und Auswirkungen).
Für Cross-Chain-Protokolle sollte die Latte höher gelegt werden: Wenn eine Funktion einen beliebigen Pfad ermöglicht, bei dem „das Protokoll dazu gebracht werden kann, etwas zu signieren, das es nicht sollte“, dann verdient sie eine tiefe Verteidigung – auch wenn die Funktion technisch gesehen wie vorgesehen funktioniert.
Wie drei „kleine“ Probleme zu einem großen Exploit verbunden wurden
Eine detaillierte technische Analyse des Anrufablaufs und des Vertragsverhaltens wurde von unabhängigen Forschern veröffentlicht; eine der klarsten Schritt-für-Schritt-Analysen ist: Analyse des ZetaChain Gateway-Hacks.
Aus der Perspektive des Sicherheitsdesigns kann die Exploit-Kette in drei Stufen zusammengefasst werden:
1) Genehmigungsfreie Initiierung von Cross-Chain-Anweisungen auf Gateway-Ebene
Ein Kernproblem war, dass ein Pfad auf Seiten des Gateways aufgerufen werden konnte, der es einem Angreifer ermöglichte, Cross-Chain-Absichten einzuschleusen (d. h. „senden Sie diese Nachricht/diesen Aufruf an die Zielkette“), ohne dass das System die erwartete Vertrauensgrenze dafür durchsetzte, wer solche Anweisungen initiieren darf.
In Cross-Chain-Systemen ist wer ein Signal „Dies sollte remote ausgeführt werden“ aussenden darf, die erste und wichtigste Verteidigungslinie.
2) Zu permissive Ausführungsregeln auf der Zielkette (und zu stark auf eine schmale Deny-List angewiesen)
Auf der Empfängerseite ermöglichte der Ausführungspfad im Wesentlichen „willkürliche“ Aufrufe, mit Einschränkungen, die nicht breit genug waren, um gefährliche Token-Operationen zu blockieren. Eine Blacklist, die nur ein paar Selektoren blockiert, ist selten ausreichend, wenn die Angriffsfläche des EVM enorm ist – und wenn Angreifer nur ein einziges erlaubtes Primitiv (wie transferFrom) benötigen, um Profit zu machen.
Dies ist ein häufiges Fehlermuster: Deny-Lists altern in feindlichen Umgebungen schlecht.
3) Veraltete ERC-20-Berechtigungen machten aus „Ausführung“ „Vermögensbewegung“
Das letzte Glied war betrieblich und nicht rein Codebasiert: Einige Wallets unterhielten unbegrenzte Genehmigungen (oder anderweitig übermäßige Berechtigungen) für den Gateway-Vertrag und löschten diese nicht, nachdem sie nicht mehr benötigt wurden.
Bei ERC-20 ist eine Berechtigung im Wesentlichen eine stehende Erlaubnis. Sobald ein Vertrag die Fähigkeit erlangt, einen Token-Aufruf in seinem eigenen Namen zu tätigen, wird jede verbleibende Berechtigung zu einer geladenen Waffe. Für den Kontext, wie Genehmigungen auf Standardebene funktionieren, siehe: ERC-20-Dokumentation von OpenZeppelin.
Forschungen haben auch gezeigt, wie weit verbreitet unbegrenzte Genehmigungen sind – und warum sie systemische Risiken schaffen – weit über jedes einzelne Protokoll hinaus (siehe: Studie zur Genehmigungsrisiken „Penny Wise and Pound Foolish“).
Angreifer-Handwerkskunst: nicht opportunistisch, sondern inszeniert
ZetaChain beschrieb den Exploit als klar geplant, darunter:
- Vorfakturierung über Tornado Cash Tage im Voraus
- Bereitstellung eines dedizierten „Drainer“-Vertrags
- Durchführung einer Adress-Vergiftungskampagne
Adress-Vergiftung verdient besondere Aufmerksamkeit, da sie zunehmend in breitere Exploit-Operationen integriert wird – nicht nur als Betrug für Kleinanleger, sondern auch als Mittel zur Verwirrung während der Reaktion auf Vorfälle. Wenn Sie einen rigorosen Überblick über die Technik und warum sie so oft funktioniert wünschen, pflegen Forscher der Carnegie Mellon University hier eine spezielle Ressource: Übersicht über Blockchain-Adressvergiftung.
Was ZetaChain geändert hat: Fußangeln entfernen, nicht nur Bugs patchen
Korrekturen nach dem Vorfall sind am wichtigsten, wenn sie Klassenrisiken reduzieren und nicht nur eine beobachtete Payload blockieren. Basierend auf der gemeldeten Reparaturrichtung von ZetaChain (wie in öffentlichen Berichten und technischen Analysen zusammengefasst), umfassen die wichtigsten Änderungen:
- Ausrollen von Patches auf die Mainnet-Infrastruktur, um den ausgenutzten Pfad zu schließen.
- Dauerhaftes Deaktivieren der Fähigkeit zu willkürlichen Aufrufen, die das Ergebnis „Ausführen beliebiger Calldata, die das Protokoll signiert“ ermöglichte.
- Ersetzen von Mustern unbegrenzter Genehmigungen in Einzahlungsströmen durch Genehmigungen für genaue Beträge, sodass eine einzelne Genehmigung nicht mehr stillschweigend Monate später nutzbar bleibt.
Das wichtigste Thema ist der Wandel von „mächtiger, aber gefährlicher Allgemeinheit“ hin zu „eng definierten, überprüfbaren Absichten“. Cross-Chain-Protokolle, die 2026 sicher skalieren wollen, müssen zunehmend standardmäßig auf zulässige Ziele, typisierte Nachrichten und fähigkeitsbeschränkte Ausführung setzen.
Entwickler-Takeaways: Cross-Chain-Sicherheit im Jahr 2026 ist eine Frage der Komposition, nicht der Komponenten
Auch außerhalb von ZetaChain werden Cross-Chain-Systeme weiterhin angegriffen, da sie sich an der Schnittstelle von:
- komplexen Zustandsmaschinen,
- verteiltem Signieren/Validieren
- und hochgradig monetarisierbaren Token-Schnittstellen befinden.
Branchenberichte über Verluste zeigen weiterhin, dass die Schwere von Exploits hoch bleibt und Extremrisikoereignisse die Ergebnisse dominieren (siehe ein Beispiel für aggregiertes Branchen-Tracking in: Immunefis Bericht über „Krypto-Verluste im Q1 2025“ (PDF)).
Wenn Sie Cross-Chain-Messaging entwickeln oder integrieren, sollten Sie diese praktischen Schutzmaßnahmen in Betracht ziehen:
- Machen Sie die Nachrichteninitiierung explizit und authentifiziert: „Jeder kann einen Cross-Chain-Aufruf anfordern“ sollte niemals gleichbedeutend sein mit „das Protokoll wird ihn signieren und ausführen“.
- Vermeiden Sie Deny-Lists für Ausführungs-Sinks: Bevorzugen Sie Allow-Lists und minimale Schnittstellen.
- Betrachten Sie Berechtigungen als Teil Ihres Bedrohungsmodells: Schatzkammer-/Betreiber-Wallets sollten strenge Genehmigungsrichtlinien, Überwachung und regelmäßige Bereinigungen haben.
- Planen Sie die Notfallkoordination: Reaktionsnetzwerke für Vorfälle wie SEAL 911 existieren, weil Minuten zählen, wenn Signaturen und Cross-Chain-Ausführung beteiligt sind.
Nutzer-Checkliste: Was Sie nach einem Cross-Chain-Vorfall tun sollten (auch wenn „Nutzer nicht betroffen waren“)
Selbst wenn ein Protokoll besagt, dass Nutzergelder nicht betroffen waren, ist es ratsam, 10 Minuten zu investieren, um Ihren persönlichen Gefahrenbereich zu reduzieren – insbesondere, wenn Sie jemals mit den betroffenen Gateway-Verträgen interagiert haben.
1) Widerrufen Sie unnötige Berechtigungen
Zwei zuverlässige Optionen:
- Verwenden Sie ein Tool zur Verwaltung von Genehmigungen wie den Leitfaden zur Token-Genehmigungsverwaltung von Revoke.cash
- Oder verwenden Sie den integrierten Prüfer eines Block-Explorers wie Etherscans Token Approval Checker
2) Verteidigen Sie sich gegen Adress-Vergiftung im täglichen Verhalten
- Kopieren Sie Empfänger nicht aus der Transaktionshistorie.
- Verwenden Sie nach Möglichkeit Adressbücher / vertrauenswürdige Kontakte.
- Überprüfen Sie mehr als die ersten/letzten paar Zeichen – Vergiftungsangriffe sind darauf ausgelegt, das abzugleichen, was Wallet-UIs abschneiden.
3) Verwenden Sie hardwarebasierte Adressverifizierung für hochwertige Überweisungen
Eine Hardware-Wallet kann einen Smart-Contract-Bug in einem Protokoll, das Sie nicht kontrollieren, nicht verhindern – aber sie kann die Wahrscheinlichkeit verringern, dass Sie persönlich den falschen Empfänger während eines Adress-Vergiftungs- oder Zwischenablage-Manipulationsszenarios autorisieren.
Hier passt OneKey natürlich gut: Indem es das Signieren isoliert und die Verifizierung auf dem Gerät betont, hilft es, „was Sie signieren“ näher an „was Sie beabsichtigen“ zu bringen – besonders in stressigen Momenten, in denen Angreifer versuchen, Verwirrung auszunutzen.
Abschließende Gedanken
Der Exploit von ZetaChain ist eine kompakte Fallstudie über die moderne Realität der Krypto-Sicherheit:
- ein zuvor gemeldeter Vorfall
- abgetan aufgrund einer „per Design“ Annahme
- kombiniert mit permissiver Ausführung und verbleibenden Genehmigungen
- ausgeführt von einem Angreifer, der im Voraus Finanzierung, Werkzeuge und Verschleierung auf sozialer Ebene vorbereitet hatte.
Wenn uns das Jahr 2025–2026 in der Branche eines gelehrt hat, dann, dass Cross-Chain-Systeme für adversarische Kompositionen konstruiert sein müssen. Die sicherste Funktion ist die, die man nicht versehentlich in ein Signierungs-Orakel verwandeln kann – selbst wenn alles „wie erwartet funktioniert“.
