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

Schlüsselerkenntnis:

• Zwischen dem 13. und 19. April 2026 wurden vier Angriffsereignisse auf mehreren Chains wie Ethereum, Unichain, Arbitrum und NEAR festgestellt, mit geschätzten Gesamtschäden von rund 310 Mio. USD.
• Angriffsvektoren umfassen die Vergiftung der RPC-Infrastruktur gegen einen LayerZero DVN, Fälschung von MMR-Nachweisen, Missbrauch vorzeichenbehafteter Ganzzahlen in einem Versicherungsfonds und Ausnutzung von zirkulären Swap-Pfaden in einem Margin-Trading-Protokoll.
• Der KelpDAO-Vorfall (290 Mio. USD) zeigt, dass die Sicherheit von Brücken über Smart Contracts hinaus bis zur Off-Chain-Verifizierungsinfrastruktur reicht. Das kaskadierende Einfrieren von WETH über fünf Chains und Arbitrums erzwungene Zustandsübergänge verdeutlichen weiter, wie Kompositionalität einzelne Fehlerpunkte verstärkt und wo die tatsächlichen Vertrauensgrenzen "dezentraler" Systeme liegen.

Geschätzte Lesezeit: 18 Minuten

In der vergangenen Woche (13.04.2026 - 19.04.2026) hat BlockSec vier Angriffsereignisse mit geschätzten Gesamtschäden von rund 310 Mio. USD festgestellt und analysiert. Die folgende Tabelle fasst diese Vorfälle zusammen, und detaillierte Analysen für jeden Fall werden in den folgenden Unterabschnitten bereitgestellt.

Wöchentlicher Highlight: KelpDAO

Dieser Vorfall wird wegen seines neuartigen Angriffsvektors auf Infrastrukturebene (RPC-Vergiftung gegen den einzigen DVN anstelle von Smart-Contract-Exploitation), seiner kaskadierenden Auswirkungen auf mehreren Chains über DeFi-Kompositionalität und der Governance-Fragen hervorgehoben, die durch Arbitrums erzwungene Zustandsübergänge zur Wiedererlangung gestohlener Gelder aufgeworfen wurden.

Am 18. April 2026 wurde KelpDaos rsETH LayerZero OFT-Bridge für rund 290 Mio. USD bei einem Angriff ausgenutzt, der einem staatlich geförderten Akteur, wahrscheinlich der Lazarus-Gruppe der DVRK, zugeschrieben wird [1]. Die Grundursache war KelpDaos 1-von-1-DVN-Konfiguration, die die Cross-Chain-Nachrichtenverifizierung auf einen einzelnen Fehlerpunkt reduzierte. Der Angreifer vergiftete die RPC-Infrastruktur, der der LayerZero Labs DVN vertraute, und zwang ihn, eine gefälschte Cross-Chain-Nachricht zu bestätigen, die zur Freigabe von 116.500 rsETH auf Ethereum führte, ohne dass ein entsprechendes Quellseitiges Ereignis auf Unichain stattfand.

Hintergrund

LayerZero ist ein Cross-Chain-Messaging-Protokoll, das auf einer modularen Sicherheitsarchitektur basiert. Im Kern wird die Integrität von Cross-Chain-Nachrichten durch dezentrale Verifizierungsnetzwerke (DVNs) durchgesetzt, off-chain-Entitäten, die für die unabhängige Verifizierung verantwortlich sind, dass eine auf einer Quellkette gesendete Nachricht tatsächlich stattgefunden hat, bevor sie auf der Zielkette ausgeführt wird. Jede Anwendung, die auf LayerZero bereitgestellt wird, konfiguriert ihre eigene DVN-Einrichtung, einschließlich, welchen DVNs vertraut wird, wie viele erforderlich sind und welcher Konsensschwellenwert erreicht werden muss. Diese Modularität gibt Anwendungen die volle Kontrolle über ihr Sicherheitsmodell, aber auch die volle Verantwortung: Eine schwache Konfiguration kann nicht vom Protokoll selbst gesichert werden.

KelpDaos rsETH wird als OFT (Omnichain Fungible Token) auf LayerZero bereitgestellt, mit einer Bridge-Route, die Unichain (Quelle) und das Ethereum-Hauptnetz (Ziel) verbindet. Der OFT-Standard ermöglicht das Verbrennen von Tokens auf der Quellkette und die Freigabe aus einer Sperre auf der Zielkette, wobei die Cross-Chain-Nachricht die alleinige Autorisierung für die Freigabe dient. Der Ethereum-seitige Adapter (0x85d456...e98ef3) ist für die Freigabe von rsETH an Empfänger verantwortlich, sobald eine gültige Cross-Chain-Nachricht verifiziert und übermittelt wurde. Entscheidend ist, dass KelpDAO diesen Pfad mit einer 1-von-1-DVN-Einrichtung konfigurierte und LayerZero Labs als alleinigen Verifier designated hat. Das bedeutet, eine einzige DVN-Attestation war ausreichend, um jede Token-Freigabe zu autorisieren, ohne dass eine zweite Meinung erforderlich war.

Um seine Verifizierungsaufgaben durchzuführen, fragt der LayerZero Labs DVN mehrere RPC-Knoten ab, um zu bestätigen, dass ein Cross-Chain-Sendevorgang tatsächlich auf der Quellkette stattgefunden hat. Diese RPC-Knoten umfassen sowohl eigene Infrastruktur als auch externe Anbieter, und der DVN verlässt sich auf deren kollektive Antworten, bevor er eine Attestation unterzeichnet. Die Integrität dieses Prozesses hängt von der Annahme ab, dass eine Mehrheit der abgefragten Knoten wahrheitsgemäße Daten liefert.

Schwachstellenanalyse

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

Erstens eliminierte KelpDaos 1-von-1-DVN-Konfiguration jegliche Redundanz in der Verifizierungsschicht. LayerZeros empfohlene Sicherheitsposition erfordert ausdrücklich Multi-DVN-Einrichtungen mit unabhängigen Verifizierern, sodass kein einzelner DVN eine Nachricht unilateral autorisieren kann. Indem sich KelpDAO ausschließlich auf den LayerZero Labs DVN verließ, stellte es sicher, dass jede Kompromittierung dieses einzelnen Verifizierers ausreichte, um eine willkürliche Token-Freigabe zu autorisieren.

Zweitens leitet der Failover-Mechanismus des DVN Verifizierungsanfragen an die jeweils erreichbaren RPC-Knoten weiter. Dieses Design geht davon aus, dass die Knotenverfügbarkeit versehentlich und nicht absichtlich ist. Es schafft jedoch eine Bedingung, unter der ein Angreifer nicht alle Datenquellen kompromittieren muss: Indem die gesunden Knoten über DDoS außer Betrieb genommen und vergiftete Knoten als einzige erreichbare Alternative bereitgehalten werden, kann der Angreifer die vollständige Kontrolle über die Daten erlangen, die der DVN empfängt.

Drittens erforderte der Austausch der op-geth-Executable auf den RPC-Knoten einen Zugriff auf Betriebssystemebene auf die zugrunde liegenden Server. Der genaue ursprüngliche Zugriffsvektor wurde nicht offengelegt, aber die Kompromittierung zweier unabhängiger Knoten in getrennten Clustern kann auf eine gemeinsame Schwäche bei der Kontrolle des Zugriffs auf diese Server hinweisen.

Zusammen bildeten diese drei Bedingungen eine vollständige Angriffskette: Die erste stellte sicher, dass kein unabhängiger DVN die attestierte Nachricht abglich, die zweite stellte sicher, dass der Angreifer die Daten vollständig kontrollieren konnte, die der einzige DVN erhielt, und die dritte lieferte den anfänglichen Fuß in der Tür, der die Datenmanipulation 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 Serverkompromittierung hätte der Angreifer keine Möglichkeit gehabt, gefälschte Daten einzuschleusen.

Angriffs-Analyse

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

• Schritt 1: Der Angreifer erhielt die Liste der spezifischen RPC-Knoten, denen der LayerZero Labs DVN vertraute. Diese Liste war ein hochwertiges Aufklärungsziel, da die Kenntnis der genauen Knoten eine gezielte Operation anstelle eines breiten Infrastrukturangriffs ermöglichte.

• Schritt 2: Der Angreifer erlangte Schreibzugriff auf Betriebssystemebene auf zwei der RPC-Knoten und ersetzte die laufenden op-geth-Binaries durch bösartige Versionen. Diese beiden Knoten liefen Berichten zufolge auf unabhängigen Clustern ohne direkte Verbindung zueinander, was darauf hindeutet, dass der anfängliche Zugriffsvektor eine gemeinsame vorgelagerte Abhängigkeit (z.B. kompromittierte Berechtigungsnachweise für die Bereitstellung, eine CI/CD-Pipeline oder Social Engineering eines Betreibers mit Zugriff auf beide) beinhaltete. 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-Binary implementierte eine gezielte Antwortlogik: Sie gab gefälschte Transaktionsdaten ausschließlich an die IP-Adresse des DVN zurück, während sie ehrliche Blockchain-Zustände für alle anderen Anfragen bereitstellte, einschließlich LayerZeros eigener Überwachungsinfrastruktur, Block-Explorer und Scan-Dienste. Diese selektive Vergiftung machte den Angriff für alle bestehenden Beobachtungssysteme unsichtbar; aus jeder externen Perspektive erschien die Quellkette normal.

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

• Schritt 5: Da der DVN nun nur noch vom Angreifer kontrollierte Daten erhielt, wurde eine gefälschte LayerZero Cross-Chain-Nachricht als gültig präsentiert. Der DVN attestierte Nonce 308 am Ethereum-Zielendpunkt, eine Nonce, für die kein entsprechender ausgehender Ereignis auf Unichain vorhanden war (bestätigt durch den Quellendpunkt, der immer noch eine maximale ausgehende Nonce von 307 meldete).

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

• Schritt 7: Die bösartige Binary führte nach Abschluss eine Selbstzerstörungsroutine aus und löschte sich selbst sowie alle lokalen Protokolle und Konfigurationsdateien. Dies behinderte die forensische Wiederherstellung nach dem Vorfall erheblich und unterstreicht die operative Raffinesse des Angreifers.

• Schritt 8: Ein nachfolgender Versuch des Angreifers, denselben Pfad für zusätzliche 40.000 rsETH (ca. 95 Mio. USD) auszunutzen, wurde blockiert, nachdem KelpDAO die Anomalie erkannt und alle relevanten Verträge auf Ethereum Mainnet und L2s pausiert hatte [2].

Breitere Auswirkungen

Der Schaden reichte weit über den ursprünglichen 290-Millionen-Dollar-Bridge-Exploit hinaus. Der Angreifer hinterlegte rund 89.567 rsETH (ca. 221 Mio. USD) auf Aave in mehreren Märkten und lieh sich WETH mit 93 % LTV im E-Mode [4]. Da Aave legitim gebrückte rsETH von über eine gefälschte Nachricht freigegebene Tokens nicht unterscheiden konnte, wurde die "vergiftete" Collateral als vollständig gültig behandelt. Die resultierende WETH-Reserveeinfrierung breitete sich über Ethereum, Arbitrum, Base, Mantle und Linea aus und betraf Nutzer, die keinerlei rsETH-Exposition hatten. Diese kaskadierende Verbreitung von einem einzigen Bridge-Konfigurationsfehler zur Störung von Multi-Chain-Kreditmärkten veranschaulicht, wie die DeFi-Komposition sowohl die Reichweite als auch die Kosten eines einzelnen Fehlerpunkts verstärkt.

Die Folgen warfen 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 signieren wird, die 1-von-1-Konfigurationen verwenden [1], was impliziert, dass die Dezentralisierung auf Protokollebene allein keine Schwächen auf Anwendungsebene kompensieren kann.

Auf Chain-Ebene führte der Arbitrum Security Council eine Notfallaktion durch, um 30.766 ETH einzufrieren, die sich im Besitz des Angreifers auf Arbitrum befanden. Wie von BlockSec analysiert [5], wurde dies durch einen erzwungenen Zustandsübergang auf Chain-Ebene erreicht: Der Security Council führte ein temporäres Upgrade des Ethereum Inbox-Vertrags durch, injizierte eine nicht signierte L1-zu-L2-Nachricht, die die Adresse des Angreifers impersonierte, 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 von durch Governance definierten Notfallbefugnissen, die transparent und in Abstimmung mit der Strafverfolgung durchgeführt wurde. Sie zeigt jedoch auch, dass L2-Chains per Design zentralisierte Interventionsfähigkeiten behalten: Jedes Asset auf Arbitrum One kann prinzipiell durch den Security Council über denselben Mechanismus verschoben werden. Die Lücke zwischen dem theoretischen Vertrauensmodell eines Systems und seiner tatsächlichen Vertrauensgrenze ist, wie dieser Vorfall auf jeder Ebene zeigt, dort, wo die folgenreichsten Risiken liegen.

Fazit

Dieser Vorfall zeigt, dass die Sicherheit von Bridges nicht allein auf die Protokollkorrektheit reduziert werden kann. Das LayerZero-Protokoll selbst funktionierte wie vorgesehen; die Schwachstelle lag ausschließlich in der darüber liegenden operativen Schicht. Die Kernlektion ist, dass die Off-Chain-Verifizierungsinfrastruktur Teil der Vertrauensgrenze ist und ihre Sicherheitshaltung dem Wert entsprechen muss, den sie schützt.

Drei Abhilfemaßnahmen hätten diesen Ausgang einzeln verhindert:

• Multi-DVN-Konfiguration: Die Erfordernis eines Konsenses zwischen mehreren unabhängigen DVNs hätte eine einzelne DVN-Kompromittierung als unzureichend für die Autorisierung einer Nachricht angesehen, unabhängig davon, wie vollständig dieser DVN getäuscht wurde.

• Failover-bewusste RPC-Auswahl: Ein plötzlicher Ausfall von erreichbaren Knoten während eines aktiven Verifizierungsfensters sollte als potenzielles Angriffssignal und nicht als Routineverfügbarkeitsereignis behandelt werden. DVN-Implementierungen sollten stoppen oder Alarm schlagen, anstatt mit einer reduzierten Anzahl von Knoten fortzufahren.

• Härtung der RPC-Infrastruktur: Die Möglichkeit, eine laufende Executable auf einem Produktions-RPC-Knoten zu ersetzen, deutet auf unzureichende Zugriffskontrollen auf den zugrunde liegenden Servern hin. Infrastruktur, auf die sich DVNs für die Wahrheit auf der Quellkette verlassen, sollte derselben Sicherheitsgrenze unterliegen wie die DVN-Signaturinstanzen selbst.

Umfassender sollten Brücken oder Cross-Chain-Protokolle, die auf Off-Chain-Attestierung angewiesen sind, nicht nur die Smart-Contract-Schicht, sondern die gesamte Datenpipeline vom Ereignis auf der Quellkette bis zur Ausführung auf der Zielkette prüfen. Die Annahme, dass die 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 diese Woche

Hyperbridge

Am 13. April 2026 wurde Hyperbridge, eine Cross-Chain-Messaging-Bridge auf Ethereum, wegen fehlender Eingabevalidierung in der MMR (Merkle Mountain Range)-Nachweisüberprüfungslogik für rund 242.000 USD ausgenutzt. Die Funktion MerkleMountainRange.VerifyProof() erzwang nicht, dass leaf_index < leafCount gilt, wodurch der Angreifer einen Cross-Chain-Nachweis fälschen und privilegierte Aktionen durchführen konnte, einschließlich der Prägung von 1.000.000.000 DOT-Tokens.

Hintergrund

Hyperbridge verwendet ein Ethereum-seitiges Verifizierer- und Dispatcher-Modell für Cross-Chain-Nachrichten. Auf Ethereum validiert der Vertrag HandlerV1 die bereitgestellten Nachweise gegen den gespeicherten overlayRoot, und wenn der Nachweis akzeptiert wird, dispatcht er die Nachricht an Zielmodule wie den Vertrag TokenGateway.

Der Vertrag TokenGateway ist ein privilegiertes Asset-Management-Modul. Neben dem normalen Asset-Bridging unterstützt er auch Governance-ähnliche Aktionen wie die Asset-Erstellung, -Registrierung und -Admin-Verwaltung. Für gebrückte Assets, die als ERC6160Ext20 implementiert sind, kann der Administrator die Prägeberechtigung durch Aufruf der Funktion changeAdmin() direkt ändern, und der neue Administrator kann dann eine beliebige Menge über die Funktion mint() prägen.

Das bedeutet, die Sicherheit der gesamten Asset-Bridge hängt von der Korrektheit des Nachweisüberprüfungspfades in HandlerV1 ab. Wenn eine gefälschte Nachricht die Überprüfung besteht, behandeln nachgelagerte Module angreifergesteuerte Payloads als authentische Cross-Chain-Anweisungen.

Schwachstellenanalyse

Das Kernproblem liegt im MMR-Nachweisüberprüfungspfad im Vertrag HandlerV1 (0x6c84ed...6d64). Die Entry-Funktion handlePostRequests() baut zuerst MmrLeaf(leaf.kIndex, leaf.index, commitment) basierend auf den vom Angreifer gelieferten Eingaben auf. Dann wird MerkleMountainRange.VerifyProof() aufgerufen, um die Nachweisvalidierung 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 Bereich liegt (d.h. leaf.index < leafCount). Durch die Wahl von leafCount = 1 und leaf_index = 1 bewirkt der Angreifer, dass CalculateRoot() das Falten des gefälschten Request-Commitments in die berechnete Wurzel überspringt und die Spitzenwurzel direkt zurückgibt. Dies bricht die Nachrichten-zu-Nachweis-Bindung und lässt willkürliche Payloads als gültig gegen einen historischen overlayRoot passieren.

Angriffs-Analyse

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

• Schritt 1: Der 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 ungültigen leaf_index nicht ablehnte, wurde das gefälschte Request-Commitment bei der Wurzelberechnung weggelassen, aber der Nachweis stimmte trotzdem mit einem historischen overlayRoot überein.

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

• Schritt 4: Der Hilfsvertrag prägte 1.000.000.000e18 DOT-Tokens.

• Schritt 5: Der Hilfsvertrag tauschte die neu geprägten DOT-Tokens über Odos Router V3 gegen 108,2 ETH.

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

Fazit

Dieser Vorfall wurde durch eine unsachgemäße Nachweisvalidierung in der MMR-Validierungslogik von Hyperbridge verursacht. Da leaf_index < leafCount nicht erzwungen wurde, konnte der Angreifer eine Nachricht fälschen, deren Commitment nie tatsächlich in die berechnete Wurzel aufgenommen wurde, aber dennoch die Überprüfung gegen eine historische Zustandsbasis bestand. Abhilfemaßnahmen sollten strenge Bereichsprüfungen wie leaf_index < leafCount vor der Nachweisvalidierung erzwingen.

Referenzen

[1] BlockSec, "Hyperbridge Attack Analysis," 13. April 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

Am 13. April 2026 wurde Dango, ein Perpetual Futures DEX, der als Cosmos AppChain aufgebaut ist, wegen eines fehlenden Vorzeichen-Checks für rund 1,5 Mio. USD ausgenutzt. Die Funktion replenish_insurance_fund() verwendete is_non_zero() anstelle von is_positive(), um den Eingabebetrag zu validieren, wodurch der Angreifer einen negativen UsdValue angeben und den Versicherungsfonds in seine Margin-Position abziehen konnte.

Hintergrund

Dango ist ein Perpetual Futures DEX, der als Cosmos AppChain aufgebaut ist. Nutzer zahlen USDC als Sicherheit auf den Perps-Vertrag ein und eröffnen gehebelte Long- oder Short-Positionen auf Vermögenswerte wie BTC, ETH und SOL über ein On-Chain-Central-Limit-Order-Book (CLOB). Der Sicherheitenbetrag jedes Benutzers wird als Margin-Konto innerhalb des Perps-Vertrags geführt.

Um Liquiditätsanbieter (LPs) vor Verlusten durch schlechte Schulden zu schützen, unterhält das Protokoll einen Versicherungsfonds: eine Reserve von USDC, die im Perps-Vertrag gehalten wird und jede Unterdeckung abdeckt, wenn die Sicherheit einer liquidierten Position nicht ausreicht, um ihre Schulden vollständig zu begleichen. Ohne ihn würden solche Unterdeckungen direkt auf die LPs sozialisiert. Jeder Benutzer könnte Margin von seinem Perp-Konto in den Versicherungsfonds einzahlen.

Schwachstellenanalyse

Die Grundursache liegt in der Funktion replenish_insurance_fund() des Vertrags 0x90bc84...bea4f, die es versäumt, negative Eingabebeträge abzulehnen. Die Funktion hat zwei Schutzmechanismen, aber keiner davon stoppt einen negativen amount:

1. ensure!(amount.is_non_zero()) prüft, ob der Betrag nicht Null ist, aber nicht, ob er positiv ist.
2. ensure!(user_state.margin >= amount) prüft, ob der Benutzer über ausreichende Margin verfügt, aber jede positive Margin erfüllt >= negative_number.

Nachdem beide Schutzmechanismen bestanden wurden, 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 die Subtraktion die Margin des Benutzers, und die Addition reduziert den Versicherungsfonds, wodurch der beabsichtigte Geldfluss umgekehrt wird.

Angriffs-Analyse

Transaktionen:

Phase 1:

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

• Schritt 1: Der Angreifer eröffnete eine Margin-Position durch Einzahlung 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 unsachgemäßen Validierung wurde der negative amount akzeptiert, wodurch Vermögenswerte aus dem Versicherungsfonds in die Margin-Position des Angreifers abgezogen wurden.

• Schritt 3: Der Angreifer zog alle Vermögenswerte aus der Margin-Position ab und erhielt 1.500.000 USDC.

Phase 2:

In Tx 2-8 rief der Angreifer transfer_remote() auf, um gestohlene Vermögenswerte nach Ethereum zu brücken. Infolgedessen wurden 410.000 USDC nach Ethereum gebrückt.

Fazit

Der Kern dieses Angriffs ist ein vorzeichenbehafteter Integer-Typ, der in einem vorzeichenlosen Kontext ohne Vorzeichen-Schutz verwendet wurde. Der UsdValue-Typ ist per Design vorzeichenbehaftet (Perps PnL kann negativ sein), aber der Spendenpfad für den Versicherungsfonds ist nur für positive Beiträge sinnvoll. Die Verwendung von is_non_zero() anstelle von is_positive() hinterließ eine Ein-Wort-Lücke, die es jedem Aufrufer ermöglichte, die Richtung des Geldflusses umzukehren und USDC aus dem Versicherungsfonds in die eigene Margin abzuziehen. Der Angreifer führte den gesamten Angriff in einer einzigen Transaktion durch (1 Mio. USD einzahlen, 1,5 Mio. USD abheben, 1.500.001 USD abheben) und brückte dann die Gelder langsam ab. Die Brückungsratenbegrenzung war der einzige Mechanismus, der den Schaden begrenzte: Ohne sie wären die gesamten ~1,5 Mio. USD unwiederbringlich nach Ethereum gebrückt worden.

Rhea Finance

Am 16. April 2026 wurde Burrowland, ein Lending- und Margin-Trading-Protokoll auf NEAR unter Rhea Finance, wegen eines Geschäftslogikfehlers in seinem Margin-Trading-Modul für rund 18,4 Mio. USD ausgenutzt. Beim Eröffnen einer gehebelten Position verlässt sich das Protokoll auf verify_token_out(), um den erwarteten Swap-Output zu validieren, bevor die Position akzeptiert wird. Diese Funktion akkumulierte jedoch token_out-Beträge aus zwischengeschalteten Swap-Schritten falsch, wenn das Token mit dem endgültigen Ausgabe-Token übereinstimmte, und berücksichtigte nicht, dass diese zwischengeschalteten Beträ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 Ausgabe-Betrag aufblähte und Solvenzprüfungen bestand, wodurch rund 18,4 Mio. USD aus dem Protokoll abgezogen wurden.

Hintergrund

Burrowland ist ein Open-Source-Lending- und Margin-Trading-Protokoll auf NEAR. Neben der Standard-Einzahlungs- und Kreditfunktion unterstützt es Margin-Trading und führt drei Schlüsselvariablen zur Darstellung einer gehebelten Position eines Benutzers ein: token_c (Sicherheit), token_d (Schulden-Asset) und token_p (Position-Asset).

Für eine Long-Position zahlt der Benutzer token_c als Sicherheit ein und leiht sich token_d mit einem gewählten Hebel (z.B. 5x). Das geliehene token_d wird dann über einen DEX in token_p, das Asset, an dem der Benutzer interessiert ist, getauscht. Unter normalen Bedingungen ist der Wert des erhaltenen token_p ungefähr gleich dem Wert des ausgegebenen token_d. Das Protokoll hält token_p im Namen des Benutzers, während die geliehene token_d als Schulden verbucht wird.

Für eine Short-Position zahlt der Benutzer ähnlich token_c ein und leiht sich token_d (das Asset, das er shorten möchte) mit Hebel. Das geliehene token_d wird in ein anderes Asset (token_p) getauscht, was effektiv eine Short-Exposition gegenüber token_d bedeutet. Auch hier wird erwartet, dass der Swap unter normalen Marktbedingungen den Wert erhält.

Während des Lebenszyklus der Position bleibt token_p im Protokoll verwahrt, und der Benutzer kann es nicht direkt abheben. Die Position muss geschlossen werden, um Gewinne oder Verluste zu realisieren, zu welchem Zeitpunkt token_p zurück in token_d getauscht wird, um die Schulden zu begleichen.

Das Eröffnen einer Margin-Position wird von internal_margin_open_position() gehandhabt, das die Positions parameter einrichtet und die Ausleihe an den DEX weiterleitet.

Bevor das Protokoll eine neue Position akzeptiert, wertet es vier Schutzmaßnahmen nacheinander aus: is_min_amount_out_reasonable() gleicht den vom Benutzer deklarierten min_token_p_amount mit dem vom Pyth-Oracle abgeleiteten Swap-Output ab, um den Slippage zu begrenzen, is_open_position_liquidatable() prüft, ob der erwartete Positions- und Sicherheitwert die Liquidationslinie überschreitet, is_open_position_forcecloseable() prüft, ob das Konto auf dem Papier nicht bereits 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 Position-Assets, da der Swap noch nicht ausgeführt wurde und kein realisierter Betrag zur Verfügung steht. Die Korrektheit jedes Gates hängt daher davon ab, dass min_token_p_amount an das gebunden ist, was der DEX tatsächlich liefern wird. Diese Bindung wird genau von verify_token_out() durchgesetzt, implementiert über RefV1TokenReceiverMessage::get_token_out(), die den Swap-Nachricht, die der Benutzer übermittelt, überprüfen soll.

Schwachstellenanalyse

Der Fehler liegt in verify_token_out(). Die Funktion wählt den token_out des letzten Swap-Schritts als endgültigen Ausgabe-Token aus, summiert dann die deklarierten min_amount_out jedes Swap-Schritts, der dasselbe Token erzeugt, in der Annahme, dass jede solche Erzeugung zur endgültigen Ausgabe beiträgt. Dies ist korrekt für einen echten Multi-Path (Split-Route)-Swap, 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 seine Ausgabe im folgenden B->A-Schritt verbraucht wird und Burrowland nie erreicht. Der summierte min_amount_out, den verify_token_out() genehmigt, stellt nicht mehr dar, 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 Bodenwahrheit behandelt. Jedes Solvenz-Tor, das eine unsichere Eröffnung stoppen sollte, rechnet gegen eine fabrizierte Zahl, so dass die Position akzeptiert wird und das Protokoll die geliehene token_d mit der angehängten zirkulären Swap-Nachricht an Ref-Finance dispatcht.

Angriffs-Analyse

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

Phase 1: Einsatz von Fake-Token und Fake-Pools

Der Angreifer setzte drei gefälschte Token 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 einer Margin-Position

• Schritt 1: Unter Verwendung der Margin-Trading-Funktion von Burrowland eröffnete der Angreifer eine gehebelte Position mit einem legitim wertvollen Asset als token_c und einem realen Reserve-Asset als token_d und fügte eine Swap-Nachricht bei, deren Aktionsliste ein Rundreise-Pfad A->B->A->B ist, der ausschließlich über die vom Angreifer kontrollierten Pools aus Phase 1 geleitet wird.

• Schritt 2: Da verify_token_out() min_amount_out über jeden Schritt summiert, dessen token_out mit dem endgültigen Token ü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 alle Gesundheitsprüfungen zur Eröffnungszeit in internal_margin_open_position(), so dass die Position akzeptiert wurde und das Protokoll token_d an Ref-Finance dispatchte.

• Schritt 4: Der zirkuläre Swap gab nur einen winzigen Betrag token_p zurück; on_open_trade_return() verbuchte ihn ohne erneute Prüfung, wodurch die Position von der Eröffnung an insolvent war.

• Schritt 5: Die geliehene token_d wurde in den vom Angreifer kontrollierten Pools entlang des Pfades abgerechnet; der Angreifer entnahm sie über remove_liquidity().

• Schritt 6: Da die Ausleihe gehebelt ist, ist die abgehobene token_d mehr wert als die hinterlegte token_c. Die Differenz ist pro Zyklus Nettogewinn, und die uneinbringliche Schuld wird in protocol_debts zwangsgeschlossen. Der Angreifer wiederholte die Konstruktion, bis rund 18,4 Mio. USD abgezogen waren.

Fazit

Dieser Vorfall wurde durch einen Geschäftslogikfehler im Burrowland Margin-Open-Pfad verursacht. Die Funktion RefV1TokenReceiverMessage::get_token_out() aggregierte fälschlicherweise zwischengeschaltete Ausgaben, wenn diese mit dem endgültigen Token übereinstimmten, in der Annahme, dass diese Beträge als endgültige Ausgabe verbleiben würden. Zirkuläre Swap-Pfade brechen diese Annahme jedoch, da diese Token wiederverwendet und innerhalb des Pfades verbraucht werden können. Infolgedessen kann der berechnete min_token_p_amount künstlich aufgebläht werden, wodurch alle nachfolgenden Solvenzprüfungen auf einem falschen Wert beruhen und Positionen gegen einen fabrizierte Gesundheitszustand eröffnet werden können, ohne den tatsächlich erhaltenen Betrag zu validieren.

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

• Deklarierte min_amount_out als unbestätigte Eingabe behandeln und entweder nur min_amount_out des letzten Hops nehmen oder Swap-Pfade, die ein zuvor erzeugtes token_out wieder verbrauchen (keine Zyklen durch das Ziel), explizit ablehnen.

• Deklarierten Slippage sowohl mit einem unteren als auch mit einem oberen Umschlag gegen den vom Oracle abgeleiteten Swap-Output begrenzen, so dass ein Angreifer den deklarierten Wert nicht einseitig aufblähen kann, um Solvenzprädikate zu umgehen.

Über BlockSec

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

BlockSec hat mehrere Blockchain-Sicherheitsarbeiten auf angesehenen Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Kryptowährungen im Wert von Milliarden gesichert.

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

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

• 🔗 BlockSec Auditing Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance