Secret Network verliert 4,67 Mio. $ durch Axelar Cross-Chain Exploit — Sieben Tage unentdeckt
Secret Network verliert 4,67 Mio. $ durch Axelar Cross-Chain Exploit — Sieben Tage unentdeckt
Am 21. Juni 2026 veröffentlichten Forscher von Common Prefix Erkenntnisse über einen Vorfall mit einer Cross-Chain-Bridge, der das Secret Network und einen mit Axelar verbundenen Vertrag betraf. Der Angreifer nutzte angeblich eine Schwachstelle in einem ICS-20-Bridge-Vertrag auf der Secret-Seite aus, fälschte „Einzahlungen“, prägte nicht gedeckte Token und zog Liquidität im Wert von schätzungsweise 4,67 Millionen Dollar ab.
Was dieses Ereignis besonders lehrreich macht, ist nicht nur die Höhe des Verlusts, sondern auch die Zeitleiste: Der Exploit dauerte Berichten zufolge etwa eine Woche, bevor jemand ihn bemerkte, und das erste deutliche Signal war kein Alarm, sondern ein Betriebsfehler, als eine legitime Überweisung nicht abgeschlossen werden konnte.
Dieser Beitrag untersucht, was passiert ist, warum die Fehlermuster in Cross-Chain-Systemen häufig vorkommen und was sowohl Benutzer als auch Entwickler tun können, um ihre Exposition zu reduzieren, da Interoperabilität im Krypto-Produktdesign 2025–2026 zum Standard wird.
Was Berichten zufolge geschah: eine klare Zeitleiste, ein verspäteter Alarm
Basierend auf der veröffentlichten Untersuchung:
- 10. Juni 2026: Der Angreifer begann, eine Schwachstelle in einem Secret Network ↔ Axelar Cross-Chain-Bridge-Vertrag auszunutzen, indem er zustellungsseitige Übertragungszustände fabrikierte und Token ohne Deckung prägte.
- 10.–17. Juni 2026: Der Angreifer konvertierte die geprägten Vermögenswerte wiederholt in liquiderer Token und leitete die Erlöse nach außen.
- 17. Juni 2026: Eine normale Cross-Chain-Überweisung schlug fehl, da das Custody/Escrow-Konto der Bridge nicht mehr über ausreichende Mittel verfügte – das Problem wurde dadurch aufgedeckt.
Dieses Muster des „stillen Abfluss, bis ein Benutzer auf die Wand trifft“ ist ein wiederkehrendes Betriebsrisiko für Bridges: Wenn die Überwachung sich auf Verfügbarkeit und Nachrichtendurchsatz konzentriert (anstatt auf wirtschaftliche Invarianten), können Exploits offen versteckt sein.
Für Leser, die eine Auffrischung dazu wünschen, wie IBC-ähnliche Token-Überweisungen typischerweise modelliert werden (Verwahrung auf einer Seite, Prägung der Darstellung auf der anderen), ist die Dokumentation des Secret Network zu IBC- und ICS-20-bezogenen Werkzeugen ein guter Ausgangspunkt.
Grundursache (wie beschrieben): Wenn ein Escrow-Modell zu einem Prägungsmodell wird
Die offengelegte Analyse führt den Kernfehler auf eine Vertragsrefaktorierung zurück: eine Verschiebung von einem Custody / Escrow-Fluss zu einem Prägungs-Fluss – während kritische Prüfungen entfernt wurden, die den Ursprung der Übertragung nachwiesen.
Einfach ausgedrückt:
- Ein Bridge-Vertrag empfängt eine Cross-Chain-Nachricht mit der Behauptung: „X Token wurden auf Chain A für Benutzer Y eingezahlt.“
- Der Zielvertrag muss überprüfen, ob diese Nachricht tatsächlich vom erwarteten Kanal / Gateway / Absender stammt.
- Erst dann sollte er Vermögenswerte prägen oder freigeben.
Laut der Offenlegung entfernte der anfällige Vertrag zwei Schlüsselfunktionen, die für die Validierung der Quelle von Übertragungen zuständig waren, was es einem Angreifer ermöglichte, Daten einzureichen, die wie eine gültige zustellungsseitige Übertragung aussahen, und Prägungen ohne echte Deckung auszulösen.
Schlimmer noch, der Bericht besagt, dass der Vertrag seit Anfang 2023 bereitgestellt war und nie einer externen Prüfung unterzogen wurde – eine Lücke in Governance und Prozess, die für jeden Vertrag, der die Cross-Chain-Prägebefugnis kontrolliert, schwer zu rechtfertigen ist.
Als Kontext dafür, wie ernsthaft Bridge-Prüfungen auf Infrastrukturebene sein sollten, können Sie die öffentlichen Prüfungsressourcen von Axelar im Audits-Repository von Axelar Network und Axelars eigene Perspektive in seinem Beitrag zur Sicherheit im Axelar-Kern einsehen.
Warum es unbemerkt blieb: „Keine Sirenen“, bevor das Tresorfach leer war
Eine zentrale Behauptung seitens des Secret Network ist, dass die Bridge-Infrastruktur von Axelar keine wirksame Anomalieerkennung oder einen Notfall-Pause-Mechanismus auslöste, bevor bereits erhebliche Werte das System verlassen hatten.
Unabhängig davon, ob die Verantwortung letztendlich beim Anwendungsvertrag, dem Bridge-Anbieter oder dem gemeinsamen Betrieb liegt, ist die Lehre allgemeiner:
Cross-Chain-Systeme benötigen wirtschaftliche Überwachung, nicht nur technische
Bridges sind nicht nur „Nachrichtenrohre“. Sie sind Finanzsysteme mit Invarianten:
- Geprägte Menge vs. verwahrte Deckung
- Tägliche Prägelimits
- Expositionsgrenzen pro Route
- Abnormale Einlösungs-/Austauschmuster
- Anstieg fehlgeschlagener Überweisungen (oft ein spätes Symptom)
Im Jahr 2026 wird die Branche dieses Risiko bereits neu bewerten. Aave hat beispielsweise nach einem separaten, durch eine Bridge verursachten Vorfall seine Listing- und Risikostandards verschärft – was zeigt, wie Zerbrechlichkeit von Bridges in DeFi-Geldmärkte überschwappen kann (CoinDesk-Berichterstattung).
Wohin die Gelder flossen: Osmosis-Routing, Ethereum-Abwicklung, dann CEX-Offramps
Die offengelegte Aufzeichnung deutet auf einen bekannten Geldwäscheweg hin:
- Die Vermögenswerte wurden durch Cosmos-Liquiditätsschienen geleitet, gemeldet über Osmosis, das als wichtiger Cross-Chain-DEX-Hub fungiert (siehe Osmosis-Dokumentation).
- Die Erlöse wurden dann auf Ethereum gebrückt und mithilfe des CoW-Protokolls (siehe CoW-Protokoll-Dokumentation) in ETH umgetauscht, bevor sie sich über mehrere Adressen fragmentierten.
- Einige Gelder erreichten angeblich zentralisierte Orte, darunter KuCoin, ChangeNow und HitBTC.
Der Bericht behauptet auch, dass zum Zeitpunkt der Veröffentlichung etwa 672.000 US-Dollar in einer von einem Angreifer kontrollierten Axelar-Wallet verblieben waren und dass Anträge zur Sperrung dieser Adresse abgelehnt wurden – während Axelar betonte, dass der ausgenutzte Vertrag nicht von Axelar entwickelt oder gewartet wurde und dass Axelars Kernprotokoll nicht kompromittiert war.
Was dieser Vorfall über das Risiko von Bridges 2025–2026 aussagt
Interoperabilität beschleunigt sich – die UX von Wallets tendiert zu „Cross-Chain mit einem Klick“, und Apps gehen zunehmend von Kettengeneralisierung als Standard aus. Aber dieser Komfort erweitert die Angriffsfläche auf drei Arten:
- Mehr Verträge erhalten irgendwo Prägebefugnisse (und Prägebefugnis ist das höchste Privileg im Token-Design).
- Refaktorisierungen sind häufig, da Teams nach schnelleren Routen, niedrigeren Gebühren und besserer UX suchen – was oft Regressionsrisiken mit sich bringt.
- Die Zuständigkeit wird uneindeutig zwischen App-Teams, Bridge-Anbietern, Relais und Überwachungsstapeln.
Das Ergebnis: Selbst wenn ein Bridge-Netzwerk robust ist, kann ein einziger schwacher Integrationsvertrag zum Ausfallpunkt werden.
Praktische Erkenntnisse
Für Entwickler: Reduzieren Sie den „Blast Radius der Prägebefugnisse“
- Behandeln Sie jeden Cross-Chain-Prägevertrag wie eine systemisch wichtige Komponente: obligatorische externe Prüfungen, formale Überprüfungsgateways und kontinuierliche Überwachung.
- Fügen Sie Schutzschalter hinzu: Ratenbegrenzungen, pro Vermögenswert Obergrenzen und automatische Pausenauslöser, die an die Verletzung von Invarianten gebunden sind.
- Überwachen Sie die Deckung gegenüber der geprägten Menge auf jeder Route; alarmieren Sie bei Abweichungen, nicht nur bei Ausfallzeiten.
- Vermeiden Sie das Entfernen von Validierungslogik während „Modelländerungen“ (Escrow → Prägung oder umgekehrt) ohne feindliche Überprüfung und Regressionstests.
Für Benutzer: Gehen Sie davon aus, dass Bridges risikoreicher sind als Spot-Swaps
- Bewahren Sie nur das Notwendige in gebrückten Darstellungen auf; behandeln Sie gepackte Vermögenswerte nicht als langfristige Kaltlagerung.
- Überprüfen Sie nach dem Bridging nach Möglichkeit, ob Sie Ihre Gelder in Eigenverwahrung übertragen und ob Sie die erhaltene Berechtigung verifiziert haben (Kette, Denom, Vertrag), bevor Sie weiter interagieren.
- Bevorzugen Sie Arbeitsabläufe, bei denen Sie unabhängig verifizieren können, was Sie unterzeichnen und wohin es geht – insbesondere beim Bridging und Swapping über mehrere Hops hinweg.
Wo OneKey passt: Eigenverwahrung in einer Cross-Chain-Welt
Bridge-Vorfälle sind eine Erinnerung daran, dass „nicht Ihre Schlüssel, nicht Ihre Münzen“ nur die halbe Wahrheit ist – die andere Hälfte ist, die Zeit und den Wert zu minimieren, die Sie in komplexen Smart-Contract-Routen belassen.
Eine Hardware-Wallet wie OneKey hilft, indem sie private Schlüssel offline hält und es einfacher macht, Zieladressen und Transaktionsabsichten zu überprüfen und zu bestätigen, bevor sie signiert werden – eine wichtige Gewohnheit, wenn die Cross-Chain-UX verbergen kann, was unter der Haube vor sich geht.
In der Multi-Chain-Realität von 2026 ist die sicherste Standardeinstellung: Nur bei Bedarf bridgen, jede Signatur verifizieren und zur Eigenverwahrung zurückkehren, wenn Sie fertig sind.
