LayerZero veröffentlicht rsETH Vorfallbericht: Wiederaufbau betroffener Infrastruktur und Anhebung der Messlatte für Cross-Chain-Sicherheit
LayerZero veröffentlicht rsETH Vorfallbericht: Wiederaufbau betroffener Infrastruktur und Anhebung der Messlatte für Cross-Chain-Sicherheit
Cross-Chain-Interoperabilität ist 2025-2026 zu einem Kernstück von DeFi geworden: Liquid Restaking Tokens, Multi-Chain-Kreditmärkte und Omnichain-Ausgabe-Standards setzen voraus, dass Vermögenswerte sicher zwischen Netzwerken bewegt werden können. Doch der rsETH-Vorfall ist eine Erinnerung daran, dass Bridgesicherheit nicht nur aus Smart Contracts besteht – sie hängt ebenso von der Off-Chain-Verifizierung, der Integrität der Infrastruktur und den Konfigurationsentscheidungen ab.
Im Nachgang zum KelpDAO rsETH Exploit (18. April 2026) veröffentlichte LayerZero eine detaillierte Vorfallerklärung und ein Nachtragsupdate, das erklärt, wie eine gefälschte Cross-Chain-Nachricht unter einer Single-Verifier-Konfiguration letztendlich akzeptiert wurde und welche operativen und politischen Änderungen nun vorgenommen werden. Die ursprünglichen Berichte können hier gelesen werden: KelpDAO Incident Statement und LayerZero Update.
Was geschah (und was nicht)
Die Auswirkungen: rsETH-Bridge geleert durch gefälschte Nachricht
Am 18. April 2026 veranlasste ein Angreifer die auf LayerZero basierende rsETH-Bridge-Route von KelpDAO zur Freigabe von etwa 116.500 rsETH (zu diesem Zeitpunkt rund 292 Mio. USD), indem er eine gefälschte Cross-Chain-Nachricht auf Ethereum verifizieren und ausführen ließ. LayerZero betonte, dass dies nur KelpDAOs rsETH-Konfiguration betraf und das LayerZero-Protokoll selbst nicht ausgenutzt wurde. Siehe LayerZeros Zusammenfassung in der Vorfallerklärung.
Zuschreibung: DPRK-verbundener „TraderTraitor“
LayerZero gab an, anfängliche Zuversicht zu haben, dass der Angreifer ein hochspezialisierter staatlicher Akteur war, und schrieb den Vorfall der nordkoreanischen Lazarus-Gruppe zu, insbesondere dem von US-Behörden erwähnten TraderTraitor-Cluster. Hintergründe zum „TraderTraitor“-Handwerk (Social Engineering, Malware-Bereitstellung und gezielte Angriffe auf Krypto-Organisationen) finden sich in der gemeinsamen US-Warnung: CISA’s TraderTraitor advisory (AA22-108A).
Was nicht kompromittiert wurde (laut LayerZero)
LayerZeros Vorfallerklärung stellt ausdrücklich fest, dass der Angriff kein Ergebnis eines LayerZero-Protokollfehlers war, und erklärt, dass die DVN-Signaturschlüssel nicht direkt gestohlen wurden. Stattdessen zielte der Angreifer auf die Datenabhängigkeiten (RPC) des DVN und die damit verbundenen Verfügbarkeitsannahmen ab. Details finden sich in der Vorfallerklärung.
Die Kernursache des Versagens: „Single Verifier“ trifft auf RPC Poisoning + Forced Failover
LayerZeros Erklärung konzentriert sich auf eine wachsende Angriffsart: RPC-Poisoning (die Zufuhr manipulierter Chain-Zustände an einen Verifier) kombiniert mit DoS / DDoS (die das System zwingt, sich auf die vergifteten Quellen zu verlassen).
1) Nachgeschaltete RPC-Knoten wurden kompromittiert und logen selektiv
Laut LayerZero verschaffte sich der Angreifer Zugang zur Liste der RPC-Knoten, die vom LayerZero Labs DVN verwendet wurden, kompromittierte eine Teilmenge und änderte das Verhalten der Knoten so, dass der DVN gefälschte Chain-Zustände erhielt – während viele Überwachungssysteme weiterhin „normale“ Antworten sahen. LayerZero beschreibt diese selektive Täuschung in seiner Vorfallerklärung.
Wenn Sie eine praktische Einführung wünschen, warum RPC-Endpunkte eine hochwirksame Angriffsfläche für Kryptosysteme darstellen, ist die Übersicht von Chainstack eine hilfreiche Referenz: RPC poisoning attacks in crypto. Eine allgemeine Definition von RPC in verteilten Systemen finden Sie in der Übersicht von IBM: Remote Procedure Call (RPC).
2) Die Verfügbarkeit externer RPCs wurde angegriffen, um eine Abhängigkeit von kompromittierten Knoten auszulösen
LayerZero berichtet, dass DDoS-Aktivitäten gegen gesunde externe RPC-Endpunkte das Fallback-Verhalten des DVN zu den vergifteten Endpunkten drängten und die Verifizierung einer Nachricht ermöglichten, die mit Transaktionen verbunden war, die nie wie angegeben stattgefunden hatten. Dieser „Verfügbarkeitsdruck“ ist eine entscheidende Lektion für alle, die Off-Chain-Verifizierungssysteme aufbauen: Redundanz bedeutet nicht nur, mehr Endpunkte zu haben; es geht darum, gezielte Ausfälle zu überstehen, ohne den falschen zu vertrauen.
3) KelpDAOs 1-von-1 DVN-Konfiguration verwandelte Kompromittierung in Verlust
Das wichtigste Konfigurationsdetail: KelpDAOs rsETH-Route verwendete eine 1-von-1 DVN-Konfiguration, wobei LayerZero Labs als alleiniger Verifier fungierte. LayerZero argumentiert, dass dies einen Single Point of Failure schuf – es gab keinen unabhängigen Verifier, der die gefälschte Nachricht hätte ablehnen können. Dies wird direkt in der Vorfallerklärung diskutiert.
Eine externe Tiefenanalyse, die den „Warum das für das DeFi-Risiko wichtig war“-Winkel einfängt, ist Galaxy’s Research Note: KelpDAO / LayerZero exploit analysis.
Warum dieser Vorfall über eine einzelne Bridge hinaus wichtig ist
Die Realität 2025-2026: „Infrastruktur-Exploits“ skalieren schneller als Vertrags-Exploits
DeFi-Sicherheitsgespräche konzentrieren sich immer noch zu sehr auf Audits und On-Chain-Bugs. Doch viele der größten Vorfälle ähneln inzwischen Enterprise-Intrusionen: Endpunkt-Kompromittierung, Manipulation der Lieferkette, Session-Hijacking und Verfügbarkeitsangriffe – gefolgt von On-Chain-Extraktion.
Im rsETH-Fall funktionierten die On-Chain-Verträge wie vorgesehen; die Eingaben in den Verifizierungsprozess wurden vergiftet.
DeFi-Komposition verwandelte eine Bridge-Leere in einen Liquiditätsschock
Eine wesentliche nachgeschaltete Sorge war, wie unbesicherte oder kompromittierte Sicherheiten in Kreditmärkte gelangen. Die Analyse nach dem Vorfall hob hervor, wie schnell Vertrauensschocks Liquidität abziehen können, selbst wenn der Kerncode des Kreditprotokolls wie beabsichtigt funktioniert. Glassnodes Bericht bietet eine Perspektive auf die Marktstruktur: Anatomy of a Liquidity Freeze.
LayerZeros Reaktion: Richtlinienänderungen, Konfigurationshärtung und DVN-Änderungen
LayerZeros Veröffentlichungen beschreiben drei praktische Richtungen:
1) „Kein 1-von-1 mehr“ für den LayerZero Labs DVN
LayerZero erklärt, dass es keine Nachrichten für Anwendungen signieren/attestieren wird, die eine 1-von-1 DVN-Konfiguration verwenden, und dass es Projekte kontaktiert, die noch mit Single-Verifier-Setups arbeiten. Dies ist in der Vorfallerklärung dargelegt und in der LayerZero Update bekräftigt.
2) Anhebung der Standard-Messlatte, aber Aufforderung an Teams, Konfigurationen zu fixieren
In seinem Update vom 8. Mai empfiehlt LayerZero Entwicklern:
- Konfigurationen fixieren (sich nicht auf veränderbare Standardeinstellungen verlassen)
- Höhere Block-Bestätigungen verwenden, die für die Chain angemessen sind
- Multi-DVN-Redundanz (mindestens 2, idealerweise 3–5) einsetzen
Diese Empfehlungen sind in der LayerZero Update aufgeführt. Für Implementierer verweist LayerZero auch auf eine Integrations-Checkliste in seinen Dokumenten: LayerZero integrations checklist.
3) Betroffene RPC-Komponenten neu aufbauen und ersetzen
LayerZero gibt an, dass die betroffenen RPC-Knoten stillgelegt und ersetzt wurden und der DVN-Betrieb mit Änderungen am RPC-Quorum und den Redundanzannahmen wieder aufgenommen wurde (Details in der Vorfallerklärung und dem Update).
Auch wenn die interne Sicherheitsarchitektur jedes Teams unterschiedlich ist, stimmt die Richtung mit dem breiteren „Zero Trust“-Denken überein: Minimierung von Stehberechtigungen, Segmentierung von Produktionssystemen und Behandlung interner Netzwerke als standardmäßig feindlich – insbesondere, wenn Ihr System als Verifier für externe Werte dient.
Praktische Erkenntnisse für Entwickler: Ein Checkliste für Cross-Chain-Bridgesicherheit 2026
Wenn Sie einen Omnichain-Asset (OFT-ähnliche Wrapper, kanonische Bridges, Restaking-Derivate) entwickeln oder integrieren, legt der rsETH-Vorfall eine klare Prioritätenordnung nahe:
-
Einseitige Verifizierung eliminieren
- Erfordern Sie N von M unabhängigen Verifizierern (nicht „zwei Marken auf demselben Stack“).
- Unabhängigkeit muss umfassen: Betreiberorganisation, Hosting, RPC-Quellen, Überwachung und Reaktion auf Vorfälle.
-
RPC-Vertrauen und Fallback-Logik härten
- Behandeln Sie RPC-Endpunkte als nicht vertrauenswürdige Eingaben.
- Stellen Sie sicher, dass Fallback nicht leise die Sicherheit reduziert (z. B. „wenn Endpunkte ausfallen, vertraue weniger Endpunkten“ ist gefährlich).
- Entwickeln Sie Verhaltensweisen im „degradierten Modus“: Verifizierung stoppen, anstatt unter Druck schwächere Beweise zu akzeptieren.
-
Für feindliche Verfügbarkeit entwerfen
- Gehen Sie davon aus, dass gezielte DDoS-Angriffe Teil der Angriffskette sind.
- Simulieren Sie, was passiert, wenn nur der vom Angreifer kontrollierte Teil erreichbar bleibt.
-
Sicherheitshaltung beobachtbar machen
- Veröffentlichen Sie Ihre Verifizierungsannahmen in einem Dashboard oder in Dokumenten:
- DVN-Set, Schwellenwerte, Bestätigungen, Pause-Schlüssel, Notfallverfahren
- Benutzer und Risikoteams müssen das Konfigurationsrisiko sehen, bevor ein Vorfall eintritt.
- Veröffentlichen Sie Ihre Verifizierungsannahmen in einem Dashboard oder in Dokumenten:
Praktische Erkenntnisse für Benutzer: Wie man das Exposure an Cross-Chain-Risiken reduziert
Selbst wenn Sie nie eine Zeile Code schreiben, können Sie das Risiko erheblich reduzieren:
- Behandeln Sie gebundene Assets als eigene Risikoklasse, getrennt von „nativen“ Assets.
- Wenn die Rendite über verschiedene Chains hinweg ähnlich aussieht, bevorzugen Sie Orte, an denen die Sicherheiten von weniger Off-Chain-Annahmen abhängen.
- Behalten Sie nur operative Salden auf L2 / gebundenen Darstellungen; lagern Sie langfristige Bestände in Cold Storage.
Self-Custody ist wichtig: Warum eine Hardware-Wallet immer noch eine Kernkontrolle ist
Vorfälle wie rsETH drehen sich um Verifizierung und Infrastruktur, aber viele große Verluste beginnen immer noch mit kompromittierten Geräten, dem Diebstahl von Anmeldedaten und Social Engineering. Eine Hardware-Wallet reduziert den potenziellen Schaden, indem sie private Schlüssel vom täglichen Surfen und von Workstation-Malware isoliert.
Wenn Sie es mit langfristiger Self-Custody ernst meinen, hilft die Verwendung einer Hardware-Wallet wie OneKey sicherzustellen, dass die Transaktionssignierung außerhalb Ihrer internetverbundenen Umgebung bleibt – eine wichtige Ebene, wenn das breitere Ökosystem mit zunehmend professionellen, staatlich verbundenen Bedrohungsmodellen konfrontiert ist.
Abschließender Gedanke: „Konfigurationen sind Sicherheit“
Der rsETH-Exploit wird wahrscheinlich weniger als „ein Bridge-Hack“ in Erinnerung bleiben, sondern mehr als eine systemische Lektion: Protokollsicherheit ist jetzt modular, und das schwächste Modul (oft Konfiguration + Infrastruktur) definiert das tatsächliche Risiko.
Da Cross-Chain-Messaging zum Standard-Plumbing für DeFi und tokenisierte Assets wird, muss die Messlatte der Branche von „auditiertem Code“ zu auditierten Annahmen übergehen – einschließlich DVN-Vielfalt, RPC-Integrität und Fallback-Sicherheit.
