Wöchentliche Web3-Sicherheitsvorfälle im Überblick | 13.–19. April 2026

In der vergangenen Woche (2026/04/13 - 2026/04/19) hat BlockSec vier Angriffsvorfälle erkannt und analysiert, mit einem geschätzten Gesamtschaden von etwa $310M. Die folgende Tabelle fasst diese Vorfälle zusammen, und detaillierte Analysen zu jedem Fall werden in den folgenden Unterabschnitten bereitgestellt.

Wöchentlicher Schwerpunkt: KelpDAO

Für einen ausführlichen Bericht über die Kaskadeneffekte nach dem Exploit, Arbitrums On-Chain-Wiederherstellungsmechanismus und die weiterreichenden Governance-Implikationen, siehe: Das Dezentralisierungsdilemma: Kaskadenrisiko und Notfallbefugnisse in der KelpDAO-Krise

Dieser Vorfall wird hervorgehoben wegen seines neuartigen Angriffsvektors auf Infrastrukturebene (RPC-Vergiftung gegen das einzige DVN statt Smart-Contract-Ausbeutung), seiner kaskadierenden Auswirkungen auf mehrere Chains durch DeFi-Komposabilität sowie der durch Arbitrums erzwungenen Zustandsübergabe zur Rückgewinnung gestohlener Gelder aufgeworfenen Governance-Fragen.

Am 18. April 2026 wurde KelpDAOs rsETH LayerZero OFT Bridge für rund 290 Millionen Dollar ausgebeutet – ein Angriff, der einem staatlich geförderten Akteur, wahrscheinlich Nordkoreas Lazarus Group, zugeschrieben wird [1]. Die Grundursache war KelpDAOs 1-von-1-DVN-Konfiguration, die die kettenübergreifende Nachrichtenverifizierung auf einen einzigen Fehlerpunkt reduzierte. Der Angreifer vergiftete die RPC-Infrastruktur, der der LayerZero Labs DVN vertraute, und zwang ihn, eine gefälschte kettenübergreifende Nachricht zu beglaubigen, die dazu führte, dass 116.500 rsETH auf Ethereum freigegeben wurden, ohne dass auf Unichain ein entsprechendes quellseitiges Ereignis stattgefunden hatte.

Hintergrund

LayerZero ist ein kettenübergreifendes Messaging-Protokoll, das auf einer modularen Sicherheitsarchitektur aufbaut. Im Kern wird die Integrität kettenübergreifender Nachrichten durch Dezentralisierte Verifizierer-Netzwerke (DVNs) sichergestellt – Off-Chain-Einheiten, die dafür zuständig sind, unabhängig zu überprüfen, dass eine auf einer Quell-Chain gesendete Nachricht tatsächlich stattgefunden hat, bevor sie auf der Ziel-Chain ausgeführt wird. Jede Anwendung, die auf LayerZero eingesetzt wird, konfiguriert ihre eigene DVN-Einrichtung, einschließlich der zu vertrauenden DVNs, der erforderlichen Anzahl und des einzuhaltenden Konsensschwellenwerts. Diese Modularität gibt Anwendungen die volle Kontrolle über ihr Sicherheitsmodell, aber auch die volle Verantwortung: Eine schwache Konfiguration kann nicht durch das Protokoll selbst abgesichert werden.

KelpDAOs rsETH ist als OFT (Omnichain Fungible Token) auf LayerZero eingesetzt, mit einer Bridge-Route zwischen Unichain (Quelle) und Ethereum Mainnet (Ziel). Der OFT-Standard ermöglicht es, Token auf der Quell-Chain zu verbrennen und aus einer Sperre auf der Ziel-Chain freizugeben, wobei die kettenübergreifende Nachricht als einzige Autorisierung für die Freigabe dient. Der Ethereum-seitige Adapter (0x85d456...e98ef3) ist dafür zuständig, rsETH an Empfänger freizugeben, sobald eine gültige kettenübergreifende Nachricht verifiziert und zugestellt wurde. Entscheidend ist, dass KelpDAO diesen Pfad mit einer 1-von-1-DVN-Konfiguration einrichtete und LayerZero Labs als einzigen Verifizierer bestimmte. Das bedeutete, dass eine einzige DVN-Beglaubigung ausreichte, um jede Token-Freigabe zu autorisieren, ohne eine zweite Meinung zu erfordern.

Um seine Verifizierungsaufgaben wahrzunehmen, fragt der LayerZero Labs DVN mehrere RPC-Knoten ab, um zu bestätigen, dass ein kettenübergreifendes Sendeereignis tatsächlich auf der Quell-Chain stattgefunden hat. Diese RPC-Knoten umfassen sowohl selbst betriebene Infrastruktur als auch externe Anbieter, und der DVN verlässt sich auf ihre kollektiven Antworten, bevor er eine Beglaubigung unterzeichnet. Die Integrität dieses Prozesses hängt von der Annahme ab, dass eine Mehrheit der abgefragten Knoten wahrheitsgemäße Daten zurückgibt.

Schwachstellenanalyse

Die Schwachstelle ist ein systemisches Versagen auf Infrastruktur- und Konfigurationsebene, zusammengesetzt aus drei sich gegenseitig verstärkenden Schwächen.

Erstens eliminierte KelpDAOs 1-von-1-DVN-Konfiguration jede Redundanz in der Verifizierungsschicht. LayerZeros empfohlene Sicherheitshaltung erfordert ausdrücklich Multi-DVN-Setups mit unabhängigen Verifizierern, sodass kein einzelner DVN einseitig eine Nachricht autorisieren kann. Indem KelpDAO ausschließlich auf den LayerZero Labs DVN setzte, stellte es sicher, dass jede Kompromittierung dieses einzelnen Verifizierers ausreichen würde, um eine beliebige Token-Freigabe zu autorisieren.

Zweitens leitet der Failover-Mechanismus des DVN Verifizierungsanfragen an alle erreichbaren RPC-Knoten weiter. Dieses Design geht davon aus, dass die Nichtverfügbarkeit von Knoten zufällig und nicht absichtlich ist. Es schafft jedoch eine Bedingung, unter der ein Angreifer nicht alle Datenquellen kompromittieren muss: Indem die gesunden Knoten per DDoS offline genommen werden und vergiftete Knoten als einzige erreichbare Alternative bereitstehen, kann der Angreifer die volle Kontrolle über die vom DVN empfangenen Daten erlangen.

Drittens erforderte das Ersetzen der op-geth-Ausführungsdatei auf den RPC-Knoten OS-Zugriff auf die zugrunde liegenden Server. Der genaue anfängliche Zugriffsvektor wurde nicht offengelegt, aber das Kompromittieren zweier unabhängiger Knoten auf getrennten Clustern könnte auf eine gemeinsame Schwäche in der Zugriffssteuerung dieser Server hinweisen.

Zusammen bildeten diese drei Bedingungen eine vollständige Angriffskette: Die erste stellte sicher, dass kein unabhängiger DVN vorhanden war, um die beglaubigte Nachricht gegenzuprüfen; die zweite stellte sicher, dass der Angreifer die vom einzigen DVN empfangenen Daten vollständig kontrollieren konnte; und die dritte lieferte den anfänglichen Einstiegspunkt, der die Datenmanipulation erst ermöglichte. Keine einzelne Schwäche allein wäre ausreichend gewesen. Ohne die 1-von-1-Konfiguration hätte ein zweiter DVN, der unabhängige Infrastruktur abfragt, die gefälschte Nachricht abgelehnt. Ohne das Failover-Verhalten hätten die gesunden Knoten die vergifteten überstimmt. Ohne die Server-Kompromittierung hätte der Angreifer keine Möglichkeit gehabt, gefälschte Daten einzuspeisen.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x1ae232...4222 und der offiziellen Vorfallsmeldung von LayerZero Labs.

• Schritt 1: Der Angreifer erhielt die Liste der spezifischen RPC-Knoten, denen der LayerZero Labs DVN vertraute. Diese Liste stellte ein hochwertiges Aufklärungsziel dar, da die Kenntnis der genauen Knoten es dem Angreifer ermöglichte, einen chirurgischen Angriff statt eines breit angelegten Infrastrukturangriffs zu planen.

• Schritt 2: Der Angreifer erlangte OS-Schreibzugriff auf zwei der RPC-Knoten und ersetzte die laufenden op-geth-Binärdateien durch bösartige Versionen. Diese beiden Knoten liefen auf unabhängigen Clustern ohne direkte Verbindung zueinander, was darauf hindeutet, dass der anfängliche Zugriffsvektor eine gemeinsam genutzte vorgelagerte Abhängigkeit involvierte (z.B. kompromittierte Deployment-Zugangsdaten, eine CI/CD-Pipeline oder Social Engineering eines Betreibers mit Zugang zu beiden). Die genaue Methode des anfänglichen Zugriffs wurde von LayerZero Labs nicht offengelegt. Dieser Schritt war die Voraussetzung für alle nachfolgenden Datenmanipulationen.

• Schritt 3: Die bösartige op-geth-Binärdatei implementierte zielgerichtete Antwortlogik: Sie lieferte gefälschte Transaktionsdaten ausschließlich an die IP-Adresse des DVN, während sie allen anderen Anfragenden – einschließlich LayerZeros eigener Überwachungsinfrastruktur, Block-Explorern und Scan-Diensten – wahrheitsgemäße Blockchain-Zustände lieferte. Diese selektive Vergiftung machte den Angriff für alle bestehenden Beobachtungssysteme unsichtbar; aus jeder externen Perspektive erschien die Quell-Chain normal.

• Schritt 4: Der interne Konsens des DVN erforderte Übereinstimmung zwischen vergifteten und unkompromittierten RPC-Knoten. Um diesen Konflikt zu lösen, führte der Angreifer während des Angriffsfensters (10:20 bis 11:40 Uhr PT) einen DDoS gegen die verbleibenden gesunden Knoten durch und löste damit die Failover-Logik des DVN aus, was ihn zwang, sich ausschließlich auf die vergiftete Infrastruktur zu verlassen. Dieser Schritt war notwendig, da die gesunden Knoten andernfalls wahrheitsgemäße Daten zurückgegeben hätten, die den gefälschten Antworten widersprochen hätten.

• Schritt 5: Da der DVN nun ausschließlich vom Angreifer kontrollierte Daten empfing, wurde eine gefälschte kettenübergreifende LayerZero-Nachricht als gültig präsentiert. Der DVN beglaubigte Nonce 308 am Ethereum-Zielendpunkt – eine Nonce, der kein entsprechendes ausgehendes Ereignis auf Unichain entsprach (bestätigt durch den Quellendpunkt, der weiterhin eine maximale ausgehende Nonce von 307 meldete).

• Schritt 6: Der Ethereum-seitige rsETH-Adapter, der eine gültig beglaubigte Nachricht empfing, gab 116.500 rsETH an die Empfängeradresse des Angreifers frei (0x8b1b6c...0d3b), die Stunden zuvor über Tornado Cash vorfinanziert worden war. Die gestohlenen Token wurden sofort auf sieben Zweig-Wallets verteilt und über Aave-Sicherheitenpositionen, direkte ETH-Tausche und Rück-Bridging zu Arbitrum liquidiert, wobei die endgültigen Erlöse bei 0x5d3919...7ccc auf Ethereum und einem entsprechenden Sammler auf Arbitrum konsolidierten.

• Schritt 7: Die bösartige Binärdatei führte nach Abschluss eine Selbstzerstörungsroutine aus und löschte sich selbst zusammen mit allen lokalen Protokollen und Konfigurationsdateien. Dies behinderte die forensische Aufarbeitung nach dem Vorfall erheblich und veranschaulicht die operative Raffinesse des Angreifers.

• Schritt 8: Ein anschließender Versuch des Angreifers, denselben Pfad für weitere 40.000 rsETH (~$95M) auszunutzen, wurde blockiert, nachdem KelpDAO die Anomalie erkannte und alle relevanten Verträge auf Ethereum Mainnet und L2s pausierte [2].

Breitere Auswirkungen

Der Schaden ging weit über den anfänglichen Bridge-Exploit von $290M hinaus. Der Angreifer hinterlegte etwa 89.567 rsETH (~$221M) auf Aave über mehrere Märkte und lieh sich WETH im E-Mode mit 93% LTV [4]. Da Aave legitim überbrücktes rsETH nicht von Token unterscheiden konnte, die über eine gefälschte Nachricht freigegeben wurden, wurde die „vergiftete" Sicherheit als vollständig gültig behandelt. Das daraus resultierende Einfrieren der WETH-Reserve breitete sich auf Ethereum, Arbitrum, Base, Mantle und Linea aus und betraf Nutzer, die keinerlei Engagement in rsETH hatten. Diese kaskadierende Ausbreitung – von einem einzelnen Bridge-Konfigurationsfehler zu einer Multi-Chain-Kreditmarkt-Störung – veranschaulicht, wie DeFi-Komposabilität sowohl die Reichweite als auch die Kosten eines einzelnen Fehlerpunkts verstärkt.

Die Nachfolge warf ebenso wichtige Fragen über die operative Realität der Dezentralisierung auf. LayerZero Labs kündigte an, dass sein DVN keine Nachrichten mehr für Anwendungen mit 1-von-1-Konfigurationen signieren wird [1], was impliziert, dass Dezentralisierung auf Protokollebene allein keine Schwächen bei der Anwendungskonfiguration ausgleichen kann.

Auf Chain-Ebene führte der Arbitrum Security Council eine Notfallmaßnahme durch, um 30.766 ETH des Angreifers auf Arbitrum One einzufrieren. Wie von BlockSec analysiert [5], wurde dies durch einen kettenweiten erzwungenen Zustandsübergang erreicht: Der Security Council aktualisierte temporär den Ethereum-Inbox-Vertrag, injizierte eine unsignierte L1-zu-L2-Nachricht, die die Adresse des Angreifers imitierte, und stellte die ursprüngliche Implementierung wieder her – alles ohne die Signatur des Inhabers zu benötigen [3].

Diese Maßnahme war eine legitime Ausübung governance-definierter Notfallbefugnisse, die transparent und in Abstimmung mit den Strafverfolgungsbehörden durchgeführt wurde. Sie zeigt jedoch auch, dass L2-Chains konzeptionell zentralisierte Eingriffsmöglichkeiten behalten: Jedes Asset auf Arbitrum One kann grundsätzlich vom Security Council über denselben Mechanismus bewegt werden. Die Lücke zwischen dem theoretischen Vertrauensmodell eines Systems und seiner tatsächlichen Vertrauensgrenze ist – wie dieser Vorfall auf jeder Ebene zeigt – der Ort, an dem die folgenreichsten Risiken liegen.

Fazit

Dieser Vorfall zeigt, dass Bridge-Sicherheit nicht allein auf Protokollkorrektheit reduziert werden kann. Das LayerZero-Protokoll selbst funktionierte wie vorgesehen; die Schwachstelle lag vollständig in der operativen Schicht darüber. Die Kernlektion lautet: Off-Chain-Verifizierungsinfrastruktur ist Teil der Vertrauensgrenze, und ihr Sicherheitsniveau muss dem Wert entsprechen, den sie schützt.

Drei Abhilfemaßnahmen hätten dieses Ergebnis jeweils einzeln verhindert:

• Multi-DVN-Konfiguration: Das Erfordern von Konsens über mehrere unabhängige DVNs hinweg hätte eine einzelne DVN-Kompromittierung unzureichend gemacht, um eine Nachricht zu autorisieren, unabhängig davon, wie vollständig dieser DVN getäuscht wurde.

• Failover-bewusste RPC-Auswahl: Ein plötzlicher Rückgang der erreichbaren Knoten während eines aktiven Verifizierungsfensters sollte als potenzielles Angriffssignal behandelt werden, nicht als routinemäßiges Verfügbarkeitsereignis. DVN-Implementierungen sollten anhalten oder alarmieren, anstatt mit einer reduzierten Knotenanzahl fortzufahren.

• Härtung der RPC-Infrastruktur: Die Möglichkeit, eine laufende Ausführungsdatei auf einem Produktions-RPC-Knoten zu ersetzen, deutet auf unzureichende Zugriffskontrollen auf den zugrunde liegenden Servern hin. Infrastruktur, von der DVNs für die Grundwahrheit der Quell-Chain abhängen, sollte derselben Sicherheitsgrenze unterliegen wie die DVN-Signierinstanzen selbst.

Allgemeiner gesagt sollte jede Bridge oder jedes kettenübergreifende Protokoll, das auf Off-Chain-Beglaubigung angewiesen ist, nicht nur die Smart-Contract-Schicht prüfen, sondern die gesamte Datenpipeline vom Quell-Chain-Ereignis bis zur Ziel-Chain-Ausführung. Die Annahme, dass RPC-Infrastruktur standardmäßig vertrauenswürdig ist, ist nicht mehr haltbar, wenn Hunderte von Millionen Dollar davon abhängen.

Referenzen

[1] LayerZero Labs, „KelpDAO Incident Statement," 20. April 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO, „April 18 Incident: Additional Context," 21. April 2026. https://x.com/KelpDAO/status/2046332070277091807

[3] Arbitrum, „Security Council Emergency Action," 21. April 2026. https://x.com/arbitrum/status/2046435443680346189

[4] LlamaRisk, „rsETH Incident Report," 20. April 2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[5] BlockSec, „Arbitrum Security Council Freeze Mechanism Analysis," 21. April 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

Weitere Vorfälle dieser Woche

Rhea Finance

Am 16. April 2026 wurde Burrowland, ein Kredit- und Margin-Trading-Protokoll auf NEAR unter Rhea Finance, aufgrund eines Fehlers in der Geschäftslogik seines Margin-Trading-Moduls für rund 18,4 Millionen Dollar ausgebeutet. Beim Öffnen einer gehebelten Position verlässt sich das Protokoll auf verify_token_out(), um den erwarteten Swap-Output vor der Akzeptanz der Position zu validieren. Diese Funktion summierte jedoch fälschlicherweise token_out-Beträge aus Zwischenschritten des Swaps, wann immer das Token mit dem endgültigen Ausgabe-Token übereinstimmte, ohne zu berücksichtigen, dass diese Zwischenbeträge anschließend als token_in wiederverwendet wurden. Der Angreifer setzte gefälschte Token und Pools ein und konstruierte dann einen zirkulären Swap-Pfad, der den wahrgenommenen Ausgabebetrag aufblähte und Solvenzprüfungen bestand, wodurch rund 18,4 Millionen Dollar aus dem Protokoll abgezogen wurden.

Hintergrund

Burrowland ist ein Open-Source-Kredit- und Margin-Trading-Protokoll auf NEAR. Neben standardmäßiger Angebots- und Leihfunktionalität unterstützt es Margin Trading und führt drei Schlüsselvariablen ein, um die gehebelte Position eines Nutzers darzustellen: token_c (Sicherheit), token_d (Schuld-Asset) und token_p (Positions-Asset).

Bei einer Long-Position hinterlegt der Nutzer token_c als Sicherheit und leiht sich token_d mit einem gewählten Hebel (z.B. 5x). Das geliehene token_d wird dann auf einem DEX in token_p getauscht, das Asset, dem der Nutzer ausgesetzt sein möchte. Unter normalen Bedingungen entspricht der Wert des empfangenen token_p ungefähr dem Wert des ausgegebenen token_d. Das Protokoll hält token_p im Namen des Nutzers, während das geliehene token_d als Schuld verbucht wird.

Bei einer Short-Position hinterlegt der Nutzer ebenfalls token_c und leiht sich token_d (das Asset, das er shorten möchte) mit Hebel. Das geliehene token_d wird gegen ein anderes Asset (token_p) getauscht, was effektiv eine Short-Exposition gegenüber token_d darstellt. Auch hier wird erwartet, dass der Swap unter normalen Marktbedingungen den Wert erhält.

Während des gesamten Lebenszyklus der Position bleibt token_p im Protokoll verwahrt und der Nutzer kann es nicht direkt abheben. Die Position muss geschlossen werden, um Gewinn oder Verlust zu realisieren, woraufhin token_p zurück in token_d getauscht wird, um die Schuld zurückzuzahlen.

Das Öffnen einer Margin-Position wird von internal_margin_open_position() gehandhabt, das die Positionsparameter einrichtet und den Kredit an den DEX weiterleitet.

Bevor das Protokoll eine neue Position akzeptiert, wertet es vier Schutzmaßnahmen der Reihe nach aus: is_min_amount_out_reasonable() gleicht den vom Nutzer deklarierten min_token_p_amount mit dem Pyth-Oracle-implizierten Swap-Output ab, um Slippage zu begrenzen; is_open_position_liquidatable() überprüft, ob der erwartete Positions- und Sicherheitenwert die Liquidationsgrenze überschreitet; is_open_position_forcecloseable() überprüft, ob das Konto nicht bereits auf dem Papier insolvent ist; und get_open_position_lr() stellt sicher, dass der Wert von token_d / token_c die maximale Hebelrate nicht überschreitet.

Alle vier Prüfungen verwenden min_token_p_amount als Wert des Positions-Assets, da der Swap noch nicht ausgeführt wurde und kein realisierter Betrag zur Verfügung steht. Die Korrektheit jedes Kontrollpunkts hängt daher davon ab, dass min_token_p_amount an das gebunden ist, was der DEX tatsächlich liefern wird. Diese Bindung soll genau verify_token_out(), implementiert über RefV1TokenReceiverMessage::get_token_out(), in der vom Nutzer eingereichten Swap-Nachricht durchsetzen.

Schwachstellenanalyse

Der Fehler befindet sich in verify_token_out(). Die Funktion wählt das token_out des letzten Swap-Schritts als finales Ausgabe-Token und summiert dann den deklarierten min_amount_out jedes Swap-Schritts, der dasselbe Token produziert, in der Annahme, dass jede solche Produktion zum finalen Output beiträgt. Dies ist korrekt für einen echten Multi-Pfad-Swap (Split-Route), schließt aber keine Schritte aus, deren token_out sofort als token_in des nächsten Schritts verbraucht wird. Ein Rundreise-Pfad wie A->B->A->B bewirkt, dass jeder ->B-Schritt zur Summe gezählt wird, obwohl sein Output im folgenden B->A-Schritt verbraucht wird und nie bei Burrowland ankommt. Der summierte min_amount_out, den verify_token_out() genehmigt, repräsentiert nicht mehr das, was der DEX tatsächlich zurückgeben wird.

Sobald verify_token_out() umgangen ist, wird der aufgeblähte min_token_p_amount in internal_margin_open_position() als Grundwahrheit behandelt. Jeder Solvenz-Kontrollpunkt, der dazu gedacht war, eine unsichere Eröffnung zu verhindern, rechnet gegen eine fabrizierte Zahl, sodass die Position akzeptiert und das Protokoll das geliehene token_d mit der angehängten zirkulären Swap-Nachricht an den DEX weiterleitet.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion GcXEKm...fnFT.

Phase 1: Einsatz gefälschter Token und Pools

Der Angreifer setzte drei gefälschte Token ein und erstellte fünf gefälschte Pools.

1. Gefälschte Token-IDs:

   1. Fake1: 31623e1d98275d2b0db4f50e102f6bf40877c1345e06e4ca6727f58c89564bb2

   2. Fake2: 6a28e3d3c7af1415ec22c6264013e1138bab00f85b8b6055d882d7d46afdf49b

   3. Fake3: e081e03daf58f5bb04cf95a03017e58449b76e704f1974771d7e3bd52835b6e5

2. Gefälschte Pool-IDs:

   1. Zec-Fake1: 7509

   2. Fake1-Fake2: 7510

   3. USDC-Fake2: 7511

   4. Fake2-Fake3: 7512

   5. Fake3-USDC: 7513

Phase 2: Eröffnung der Margin-Position

• Schritt 1: Mithilfe der Margin-Trading-Funktion von Burrowland eröffnete der Angreifer eine gehebelte Position mit einem legitim wertvollen Asset als token_c und einem echten Reserve-Asset als token_d, wobei eine Swap-Nachricht angehängt wurde, deren Aktionsliste ein Rundreise-Pfad A->B->A->B ist, der vollständig durch die in Phase 1 vom Angreifer kontrollierten Pools geleitet wird.

• Schritt 2: Da verify_token_out() min_amount_out über jeden Schritt summiert, dessen token_out mit dem terminalen Output übereinstimmt, ermöglichte der Rundreise-Pfad dem Angreifer, den deklarierten min_token_p_amount auf einen beliebigen Wert aufzublähen.

• Schritt 3: Der aufgeblähte min_token_p_amount bestand jede Gesundheitsprüfung zur Eröffnungszeit in internal_margin_open_position(), sodass die Position akzeptiert und das Protokoll token_d an Ref-Finance weiterleitete.

• Schritt 4: Der zirkuläre Swap gab nur eine winzige Menge token_p zurück; on_open_trade_return() verbuchte es ohne erneute Überprüfung und ließ die Position von Anfang an insolvent.

• Schritt 5: Das geliehene token_d landete in den vom Angreifer kontrollierten Pools entlang des Pfades; der Angreifer zog es über remove_liquidity() ab.

• Schritt 6: Da das Darlehen gehebelt ist, ist das abgezogene token_d mehr wert als das hinterlegte token_c. Die Differenz ist Nettogewinn pro Zyklus, und die uneinbringliche Schuld wird in protocol_debts zwangsgeschlossen. Der Angreifer wiederholte die Konstruktion, bis rund 18,4 Millionen Dollar abgezogen worden waren.

Fazit

Dieser Vorfall wurde durch einen Geschäftslogikfehler in Burrowlands Margin-Öffnungspfad verursacht. Die Funktion RefV1TokenReceiverMessage::get_token_out() aggregierte fälschlicherweise Zwischenausgaben, wann immer sie mit dem finalen Token übereinstimmten, in der Annahme, dass diese Beträge als endgültiger Output verbleiben würden. Zirkuläre Swap-Pfade brechen jedoch diese Annahme, da diese Token innerhalb des Pfades wiederverwendet und verbraucht werden können. Infolgedessen kann der berechnete min_token_p_amount künstlich aufgebläht werden, was dazu führt, dass alle nachfolgenden Solvenzprüfungen auf einem falschen Wert basieren und Positionen gegen einen fabrizierten Gesundheitszustand eröffnet werden können, ohne den tatsächlich empfangenen Betrag zu validieren.

Für produktive Margin-Trading-Verträge sollten Entwickler:

• Den vom Nutzer deklarierten min_amount_out als unverifizierte Eingabe behandeln und entweder nur den min_amount_out des letzten Hops verwenden oder Swap-Pfade explizit ablehnen, die einen zuvor produzierten token_out wiederverbrauchen (keine Zyklen durch das Ziel-Token).

• Den deklarierten Slippage sowohl nach unten als auch nach oben mit dem Oracle-implizierten Swap-Output eingrenzen, sodass ein Angreifer den deklarierten Wert nicht einseitig aufblähen kann, um Solvenzprädikate zu umgehen.

Hyperbridge

Am 13. April 2026 wurde Hyperbridge, eine kettenübergreifende Messaging-Bridge auf Ethereum, aufgrund fehlender Eingabevalidierung in der MMR-Beweisverifizierungslogik (Merkle Mountain Range) für rund 242.000 Dollar ausgebeutet. Die Funktion MerkleMountainRange.VerifyProof() erzwang nicht, dass leaf_index < leafCount, was dem Angreifer ermöglichte, einen kettenübergreifenden Beweis zu fälschen und privilegierte Aktionen durchzuführen, einschließlich des Mintens von 1.000.000.000 DOT-Token.

Hintergrund

Hyperbridge verwendet auf Ethereum ein Verifizierer- und Dispatcher-Modell für kettenübergreifende Nachrichten. Auf Ethereum validiert der Vertrag HandlerV1 die bereitgestellten Beweise gegen den gespeicherten overlayRoot, und wenn der Beweis akzeptiert wird, leitet er die Nachricht an Zielmodule wie den Vertrag TokenGateway weiter.

Der Vertrag TokenGateway ist ein privilegiertes Asset-Management-Modul. Neben normalem Asset-Bridging unterstützt er auch Governance-artige Aktionen wie Asset-Erstellung, -Deregistrierung und Admin-Verwaltung. Für überbrückte Assets, die als ERC6160Ext20 implementiert sind, kann der Admin die Minting-Berechtigung direkt übertragen, indem er die Funktion changeAdmin() aufruft, und der neue Admin kann dann beliebige Versorgungen über die Funktion mint() minten.

Das bedeutet, dass die Sicherheit der gesamten Asset-Bridge von der Korrektheit des Beweisverifizierungspfades in HandlerV1 abhängt. Wenn eine gefälschte Nachricht die Verifizierung passieren kann, behandeln nachgelagerte Module vom Angreifer kontrollierte Payloads als authentische kettenübergreifende Anweisungen.

Schwachstellenanalyse

Das Kernproblem liegt im MMR-Beweisverifizierungsfluss im Vertrag HandlerV1 (0x6c84ed...6d64). Die Einstiegsfunktion handlePostRequests() erstellt zunächst MmrLeaf(leaf.kIndex, leaf.index, commitment) auf Basis der vom Angreifer gelieferten Eingaben. Dann wird MerkleMountainRange.VerifyProof() aufgerufen, um die Beweisvalidierung durchzuführen.

MerkleMountainRange.VerifyProof(root, request.proof.multiproof, leaves, request.proof.leafCount)

VerifyProof() prüft jedoch nur, ob root == CalculateRoot(proof, leaves, mmrSize) und validiert nicht, dass jeder leaf.index im gültigen Bereich liegt (d.h. leaf.index < leafCount). Indem der Angreifer leafCount = 1 und leaf_index = 1 wählt, bewirkt er, dass CalculateRoot() das Einfalten des gefälschten Anforderungs-Commitments in den berechneten Root überspringt und den Peak-Root direkt zurückgibt. Dies bricht die Nachrichten-zu-Beweis-Bindung und ermöglicht es beliebigen Payloads, als gültig gegen einen historischen overlayRoot zu bestehen.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x240aeb...1109 [1].

• Schritt 1: Die Angreifer-EOA 0xC513...F8E7 setzte in derselben Transaktion Hilfsverträge 0x518A...8f26 und 0x31a1...ca9AB ein.

• Schritt 2: Der Hilfsvertrag 0x31a1...ca9AB übermittelte eine gefälschte Anfrage über den anfälligen Verifizierungspfad in HandlerV1. Da VerifyProof() den außerhalb des Bereichs liegenden leaf_index nicht ablehnte, wurde das gefälschte Anforderungs-Commitment aus der Root-Berechnung weggelassen, dennoch passte der Beweis zu einem historischen overlayRoot.

• Schritt 3: Nachdem die gefälschte Nachricht akzeptiert wurde, leitete HandlerV1 sie an TokenGateway weiter und führte die ChangeAssetAdmin-Aktion aus. Dadurch wurde der Admin des DOT-Tokens auf den vom Angreifer kontrollierten Hilfsvertrag 0x31a1...ca9AB geändert.

• Schritt 4: Der Hilfsvertrag mintete 1.000.000.000e18 DOT-Token.

• Schritt 5: Der Hilfsvertrag tauschte die neu geminteten DOT-Token über Odos Router V3 gegen 108,2 ETH.

• Schritt 6: Der Angreifer überwies 108,2 ETH auf sein EOA-Konto.

Fazit

Dieser Vorfall wurde durch unzureichende Beweisvalidierung in Hyperbridges MMR-Verifizierungslogik verursacht. Da leaf_index < leafCount nicht erzwungen wurde, konnte der Angreifer eine Nachricht fälschen, deren Commitment nie tatsächlich in den berechneten Root einbezogen wurde, aber dennoch die Verifizierung gegen einen historischen Zustandsroot bestand. Abhilfemaßnahmen sollten strenge Bereichsprüfungen wie leaf_index < leafCount vor der Beweisverifizierung erzwingen.

Referenzen

[1] BlockSec, „Hyperbridge-Angriffsanalyse," 13. April 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

Am 13. April 2026 wurde Dango, eine Perpetual-Futures-DEX, die als Cosmos AppChain aufgebaut ist, aufgrund einer fehlenden Vorzeichenprüfung für rund 1,5 Millionen Dollar ausgebeutet. Die Funktion replenish_insurance_fund() verwendete is_non_zero() anstelle von is_positive() zur Validierung des Eingabebetrags, was es dem Angreifer ermöglichte, einen negativen UsdValue anzugeben und den Versicherungsfonds in seine Margin-Position zu leeren.

Hintergrund

Dango ist eine Perpetual-Futures-DEX, die als Cosmos AppChain aufgebaut ist. Nutzer hinterlegen USDC als Sicherheit im Perps-Vertrag und eröffnen gehebelte Long- oder Short-Positionen auf Assets wie BTC, ETH und SOL über ein On-Chain Central Limit Order Book (CLOB). Der Sicherheitensaldo jedes Nutzers wird als Margin-Konto innerhalb des Perps-Vertrags verwaltet.

Um Liquiditätsanbieter (LPs) vor Forderungsausfällen zu schützen, unterhält das Protokoll einen Versicherungsfonds: eine Reserve aus USDC, die innerhalb des Perps-Vertrags gehalten wird und Fehlbeträge deckt, wenn die Sicherheit einer liquidierten Position nicht ausreicht, um ihre Schuld vollständig zurückzuzahlen. Ohne ihn würden solche Fehlbeträge direkt auf die LPs sozialisiert. Jeder Nutzer konnte Margin aus seinem Perp-Konto zum Versicherungsfonds beitragen.

Schwachstellenanalyse

Die Grundursache liegt in der Funktion replenish_insurance_fund() des Vertrags 0x90bc84...bea4f, die negative Eingabebeträge nicht ablehnt. Die Funktion hat zwei Sicherheitsprüfungen, aber keine davon hält einen negativen amount auf:

1. ensure!(amount.is_non_zero()) prüft, dass der Betrag nicht null ist, prüft aber nicht, ob er positiv ist.
2. ensure!(user_state.margin >= amount) prüft, dass der Nutzer ausreichende Margin hat, aber jede positive Margin erfüllt >= negative_number.

Nachdem beide Prüfungen bestanden sind, führt die Funktion user_state.margin.checked_sub_assign(amount) und state.insurance_fund.checked_add_assign(amount) aus. Wenn amount negativ ist, erhöht das Subtrahieren die Margin des Nutzers, und das Addieren verringert den Versicherungsfonds, was den beabsichtigten Geldfluss vollständig umkehrt.

Angriffsanalyse

Transaktionen:

Phase 1:

In Tx 1 führte der Angreifer die folgenden Schritte durch, um Assets aus Dangos Versicherungsfonds abzuziehen:

• Schritt 1: Der Angreifer eröffnete eine Margin-Position durch Hinterlegung von 1e6 USDC. Dies war eine Voraussetzung für den Aufruf von replenish_insurance_fund().

• Schritt 2: Der Angreifer rief replenish_insurance_fund() mit einem negativen amount auf (d.h. -1500000). Aufgrund der unzureichenden Validierung wurde der negative amount akzeptiert, wodurch Assets aus dem Versicherungsfonds in die Margin-Position des Angreifers abgezogen wurden.

• Schritt 3: Der Angreifer zog alle Assets aus der Margin-Position ab und erhielt $1.500.000 in USDC.

Phase 2:

In Tx 2-8 rief der Angreifer transfer_remote() auf, um gestohlene Assets nach Ethereum zu überbrücken. Infolgedessen wurden $410.000 in USDC nach Ethereum überbrückt.

Fazit

Das Wesen dieses Angriffs ist ein vorzeichenbehafteter Integer-Typ, der in einem vorzeichenlosen Kontext ohne Vorzeichenprüfung verwendet wird. Der UsdValue-Typ ist konstruktionsbedingt vorzeichenbehaftet (Perps-PnL kann negativ sein), aber der Spendenweg des Versicherungsfonds ergibt nur für positive Beiträge Sinn. Die Verwendung von is_non_zero() anstelle von is_positive() ließ eine Ein-Wort-Lücke, die jedem Aufrufer ermöglichte, die Richtung des Geldflusses umzukehren und USDC aus dem Versicherungsfonds in die eigene Margin zu leiten. Der Angreifer führte den gesamten Angriff in einer einzigen Transaktion aus (1 Dollar einzahlen, 1,5 Mio. Dollar leeren, 1.500.001 Dollar abheben) und überbrückte dann langsam Gelder. Das Bridge-Ratenlimit war der einzige Mechanismus, der den Schaden begrenzte: Ohne es wäre das gesamte ~$1,5M unwiederbringlich nach Ethereum überbrückt worden.

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchains und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zurückzuverfolgen und AML/CFT-Verpflichtungen zu erfüllen – über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg.

BlockSec hat mehrere Blockchain-Sicherheitspapiere auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert und dabei mehr als 20 Millionen Dollar gerettet sowie Milliarden von Kryptowährungen gesichert.

• Offizielle Website: https://blocksec.com/

• Offizielles Twitter-Konto: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Anfrage stellen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance