Wöchentlicher Web3-Sicherheitsvorfall-Rundbrief | 23. – 29. März 2026

Im Laufe der letzten Woche (23.03.2026 - 29.03.2026) hat BlockSec acht Angriffsereignisse erkannt und analysiert, mit geschätzten Gesamtschäden von ca. 1,53 Mio. $. Die folgende Tabelle fasst diese Vorfälle zusammen, und detaillierte Analysen für jeden Fall werden in den folgenden Unterabschnitten bereitgestellt.

1. Unbekannter Vorfall 1

Kurze Zusammenfassung

Am 23. März 2026 wurde ein nicht verifizierter Vertrag auf Ethereum aufgrund eines Integer-Überlaufs in seiner Verteilungslogik für rund 97.000 $ ausgenutzt. Die Funktion 0x317de4f6() summierte die vom Benutzer kontrollierten Token-Beträge ohne Überlaufschutz, was es dem Angreifer ermöglichte, einen Überlauf auszulösen und den gesamten USDT-Saldo des Vertrags über die claim()-Funktion durch Zahlung von nur 1 wei USDT abzuziehen.

Schwachstellenanalyse

Die Grundursache war ein Integer-Überlauf in der Funktion 0x317de4f6() des Vertrags 0xF0a105...568C97. Die Funktion akzeptiert ein Array von Datensätzen (jeder mit einem Konto und einem Betrag) und summiert alle Beträge zu totalAmount, indem sie das Array durchläuft. Da die Anrechnung keine Überlaufprüfungen enthielt, konnte ein Angreifer manipulierte Datensätze liefern, deren Beträge uint256 überlaufen ließen, wodurch totalAmount beliebig klein wurde, während die einzelnen Zuweisungen groß blieben.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x73bd1384...630b053.

• Schritt 1: Der Angreifer entnahm 1 wei USDT von Uniswap V4 als Anfangskapital für den Angriff.

  

• Schritt 2: Der Angreifer fragte den USDT-Saldo des Opfervertrags ab und rief dann 0x317de4f6() mit einem manipulierten Array auf. Ein Betrag wurde nahe der oberen Grenze von uint256 festgelegt, und der andere wurde auf den USDT-Saldo des Opfervertrags festgelegt. Ihre Summe überlief zu 1, was es dem Angreifer ermöglichte, nur 1 wei USDT zu zahlen und gleichzeitig eine Zuweisung in Höhe des gesamten USDT-Saldos des Opfers zu registrieren.

  

• Schritt 3: Der Angreifer rief claim() auf, um 97.812e6 USDT vom Opfervertrag abzuziehen.

  

• Schritt 4: Der Angreifer zahlte die von Uniswap V4 geliehenen 1 wei USDT zurück und tauschte die verbleibenden USDT gegen WETH, womit der Exploit abgeschlossen wurde.

Schlussfolgerung

Dieser Vorfall unterstreicht die Risiken der Verwendung von unkontrollierter Arithmetik in Solidity-Versionen vor 0.8.0. Alle kritischen Finanzberechnungen sollten explizit Überlauf-sichere Arithmetik (z. B. SafeMath oder Solidity >=0.8.x) verwenden, um Überlaufprobleme zu verhindern.

2. Unbekannter Vorfall 2

Kurze Zusammenfassung

Am 23. März 2026 wurde ein nicht verifizierter Vertrag auf Ethereum aufgrund einer Reentrancy-Schwachstelle für rund 11.000 $ ausgenutzt. Die Funktion 0xbe16634e() aktualisierte die Liquiditätsbuchhaltung vor der Abrechnung und rief einen externen Callback ohne Reentrancy-Schutz auf. Durch wiederholtes erneutes Aufrufen der Funktion, bevor der vorherige Aufruf abgerechnet wurde, blähte der Angreifer seine registrierte Liquidität auf und zog später mehr USDC und WETH ab, als er tatsächlich eingezahlt hatte.

Schwachstellenanalyse

Die Grundursache ist ein Reentrancy-Problem in der Funktion 0xbe16634e() des Vertrags 0x39Ed37...9C6b08. Diese Funktion aktualisiert liquiditätsbezogene Zustände, einschließlich der Benutzernetzliquidität und der Tick-Reserven, vor der Abrechnung und ruft über msg.sender.call() einen externen Callback ohne Reentrancy-Guard auf. Da die Bilanzprüfung pro Aufruf erfolgt, kann der Angreifer die Funktion rekursiv erneut aufrufen und die interne Liquiditätsbuchhaltung aufblähen, während eine einzelne Token-Überweisung im tiefsten Aufruf ausreicht, um den verschachtelten Ausführungsfluss zu erfüllen.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x1382e898...fad993.

• Schritt 1: Der Angreifer entnahm 100e8 USDC und 10e18 WETH von Uniswap V4 als Anfangskapital für den Angriff.

  

• Schritt 2: Der Angreifer rief 0xbe16634e() auf, um Liquidität hinzuzufügen. Während der Ausführung rief der Opfervertrag die Funktion 0x7c65be42() des Angreifers auf, die 0xbe16634e() erneut aufrief, bevor der vorherige Aufruf abgerechnet wurde.

  

• Schritt 3: Durch wiederholtes Ausführen dieses reentranten Ablaufs erhöhte der Angreifer kontinuierlich seine registrierte Liquidität. Im tiefsten Aufruf tätigte der Angreifer die erforderlichen Token-Überweisungen einmal, was ausreichte, um die verschachtelten Bilanzprüfungen zu erfüllen.

  

• Schritt 4: Nach der Aufblähung der registrierten Liquidität prüfte der Angreifer den Poolzustand und zahlte zusätzliche Gelder in den Pool ein, sodass dieser genügend USDC und WETH enthielt, um die bevorstehende Auszahlung zu decken.

  

• Schritt 5: Der Angreifer rief erneut 0xbe16634e() auf, um Liquidität zu entfernen, und zog USDC und WETH aus dem Pool basierend auf der aufgeblähten Buchhaltung ab.

  

• Schritt 6: Der Angreifer zahlte Uniswap V4 zurück, tauschte die verbleibenden USDC gegen WETH und schloss den Exploit ab.

  

Schlussfolgerung

Dieser Vorfall zeigt die Gefahr der Aktualisierung der Liquiditätsbuchhaltung vor der Abrechnung, während ein ungeschützter externer Callback aufgerufen wird. Um ähnliche Exploits zu verhindern, sollten Protokolle strikt das Checks-Effects-Interactions-Muster befolgen und externe Callbacks mit Reentrancy-Guards schützen.

3. Cyrus Finance Vorfall

Kurze Zusammenfassung

Am 23. März 2026 wurde Cyrus Finance, ein Yield-Farming-Protokoll auf der BNB Chain, aufgrund einer fehlerhaften Formel zur Liquiditätsentnahme, die vom aktuellen Spotpreis des Pools abhängt, für rund 512.000 $ ausgenutzt. Das Protokoll verwendet CYRP NFT-Positionen, um einen proportionalen Anteil seiner PancakeSwap V3-Liquidität darzustellen. Die Umrechnung vom Benutzeranteil in zugrunde liegende Liquidität liest jedoch slot0(), was innerhalb derselben Transaktion manipulierbar ist. Durch die Verschiebung des Preises über einen durch Flash-Loan finanzierten Swap blähte der Angreifer den Liquiditätswert seiner NFT-Position auf und zog mehr als seinen fairen Anteil ab.

Hintergrund

Cyrus Finance ist ein Yield-Farming-Protokoll auf der BNB Chain, das Liquiditätspositionen in PancakeSwap V3-Pools verwaltet. Benutzer zahlen USDT ein, um CYRP NFT-Positionen zu erhalten, die ihren Anteil an der Liquidität des Protokolls über mehrere PancakeSwap V3-Positionen darstellen. Benutzer können ihre Einlagen plus Belohnungen über die exit()-Funktion abheben.

Schwachstellenanalyse

Die Schwachstelle liegt in der Funktion withdrawUSDTFromAny() in CyrusTreasury (0xb042Ea...0aE10b). Bei der Bearbeitung einer Auszahlung ruft die Funktion sqrtPriceX96 aus dem slot0() des PancakeSwap V3-Pools (d. h. des aktuellen Spotpreises) ab und übergibt ihn an getAmountsForLiquidity(), um abzuschätzen, wie viel amount0 / amount1 die vollständige Positionsliquidität des Protokolls derzeit darstellt.

Anschließend leitet sie availableUSDT aus dieser Spotpreis-basierten Bewertung ab und verwendet die folgende Formel, um zu bestimmen, wie viel Liquidität für die angeforderte Auszahlung entfernt werden soll:

$liquidityToUse=liquidity\cdot remaining\mathrm{/}availableUSDTliquidityToUse\; =\; liquidity\; \backslash cdot\; remaining\; /\; availableUSDT$

Mit anderen Worten, der Vertrag löst keinen festen Eigentumsanteil direkt ein. Stattdessen schätzt er zunächst den USDT-Äquivalenzwert der aktuellen Position anhand des Live-Poolpreises und rechnet dann den angeforderten USDT-Betrag in einen proportionalen Liquiditätsbetrag zurück.

Dies ist unsicher, da slot0() innerhalb derselben Transaktion manipulierbar ist. Durch die vorübergehende Verschiebung des Poolpreises kann ein Angreifer availableUSDT verzerren, was sich direkt auf die berechnete liquidityToUse auswirkt.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x85ac5d15...46d452.

• Schritt 1: Der Angreifer initiierte einen Flash-Loan aus einem PancakeSwap V3-Pool und lieh sich rund 1.798 ETH.

• Schritt 2: Der Angreifer führte einen großen ETH-zu-USDT-Swap im Zielpool durch, in dem das Protokoll Liquidität hielt, und verschob dabei absichtlich den Poolpreis und den aktuellen Tick. Gleichzeitig übertrug der Angreifer die CYRP NFT-Position Nr. 15505 vom 0x01737d...6ffa3 an den Angriffsvertrag über safeTransferFrom().

• Schritt 3: Der Angreifer rief exit(15505) auf CyrusTreasury auf. Während der Ausführung las withdrawUSDTFromAny() slot0() aus dem PancakeSwap V3-Pool und berechnete availableUSDT basierend auf dem manipulierten Spotpreis. Aufgrund des verzerrten Ticks überschätzte das Protokoll den Liquiditätswert, der dem NFT-Anteil entsprach. Anschließend rief es decreaseLiquidity() und collect() auf, wodurch überschüssige USDT über den fairen Wert der Cyrus-Position hinaus freigegeben wurden.

  

• Schritt 4: Der Angreifer stellte den Poolzustand wieder her, zahlte den Flash-Loan zurück und übertrug den verbleibenden Gewinn (ca. 512.000 $) an EOA 0xf96EB1...3b63b.

Schlussfolgerung

Die Abhilfe sollte die Spot-slot0()-Preisgestaltung durch eine manipulationsresistente Preisgestaltung (TWAP über ein ausreichendes Beobachtungsfenster oder ein externes Orakel wie Chainlink) ersetzen, bevor die Liquidität in abhebbares USDT umgerechnet wird.

4. BCE Token Vorfall

Kurze Zusammenfassung

Am 23. März 2026 wurde der PancakeSwap BCE-USDT-Pool auf der BNB Chain aufgrund eines fehlerhaften Burn-Mechanismus im BCE-Token für rund 679.000 $ ausgenutzt. Der Angreifer setzte zwei bösartige Verträge ein, um die Kauf-/Verkaufslimits von BCE zu umgehen, und löste Token-Burns gegen die Reserven des Liquiditätspools aus, wodurch der Preis des Pools manipuliert und sein USDT abgezogen wurde.

Schwachstellenanalyse

Die Schwachstelle ergibt sich aus dem fehlerhaften Burn-Mechanismus des BCE-Tokens (0xcdb189...999999). Das Kernproblem ist, dass eine vom Benutzer beeinflusste Zustandsvariable scheduledDestruction verwendet wird, um Token direkt von der PancakeSwap-Pair-Adresse statt vom Guthaben des Benutzers zu verbrennen. Bei Verkaufsoperationen sammelt der Vertrag einen Zerstörungsbetrag in scheduledDestruction basierend auf dem gehandelten Volumen und den aktuellen Poolreserven. Dieser Wert wird nicht vom Verkäufer abgezogen. Stattdessen wird er später über einen separaten Codepfad ausgeführt, der Token vom Paar verbrennt und sync() aufruft.

Da der Angreifer das Handelsvolumen kontrolliert und die Poolreserven manipulieren kann, kann er scheduledDestruction auf einen beliebigen Wert setzen und einen Burn auslösen, der die BCE-Reserve des Paares komprimiert und den Poolpreis zu seinen Gunsten verzerrt.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x85ac5d15...46d452.

• Schritt 1: Der Angreifer rief einen bösartigen Vertrag (MC1) auf, um 123,5 Mio. USDT über mehrere Flash-Loans und einen Kreditpool zu leihen.

• Schritt 2: Der Angreifer setzte einen zweiten bösartigen Vertrag (MC2) ein und übertrug alle geliehenen USDT an MC2.

• Schritt 3: Der Angreifer (über MC2) tauschte 2,222 Mio. USDT gegen 5,529 Mio. BCE im BCE-USDT-Pool.

• Schritt 4: Der Angreifer übertrug 5,529 Mio. BCE von MC2 an MC1 (über MC1.drain()); aufgrund des Burn-Mechanismus erhielt MC1 2,764 Mio. BCE.

• Schritt 5: Der Angreifer (über MC1) tauschte 2,488 Mio. BCE gegen 1,368 Mio. USDT und aktualisierte die Variable scheduledDestruction auf ca. 174.000 $ basierend auf den Poolreserven und dem Swap-Betrag. Die Variable wurde später als Burn-Betrag verwendet.

• Schritt 6: Der Angreifer (über MC2) tauschte 34,9 Mio. USDT gegen 3,484 Mio. BCE und manipulierte so die BCE-Reserve auf ca. 174.000 $.

• Schritt 7: Der Angreifer übertrug 3,484 Mio. BCE und die verbleibenden USDT von MC2 an MC1. Da scheduledDestruction größer als 0 war (d. h. ca. 174.000 $), löste die Übertragung von BCE Burns aus, die die BCE-Reserve auf ca. 10.000 komprimierten.

• Schritt 8: Der Angreifer tauschte die verbleibenden BCE zum manipulierten Preis gegen USDT.

• Schritt 9: Der Angreifer zahlte alle Kredite zurück und erzielte einen Nettogewinn von etwa 679.000 $.

Schlussfolgerung

Dieser Vorfall wurde durch einen grundlegenden Fehler in der wirtschaftlichen Logik des Tokens verursacht, bei dem eine vom Benutzer beeinflusste Zustandsvariable das Guthaben des Liquiditätspools anstelle des Guthabens des Benutzers selbst modifizierte. Der Vertrag ging implizit davon aus, dass die durch Handelsaktivitäten abgeleitete Zerstörung die Kosten des Benutzers widerspiegelt, in der Praxis ermöglichte dies Angreifern jedoch, einen aufgeschobenen Burn zu konstruieren, der gegen die LP-Reserven abgerechnet wurde. Infolgedessen konnten Angreifer die Pooltiefe und die Preisgestaltung mit begrenztem Kapitaleinsatz manipulieren und Werte von den Liquiditätsanbietern extrahieren.

5. Unbekannter Vorfall 3

Kurze Zusammenfassung

Am 25. März 2026 wurde ein nicht verifizierter Staking-Vertrag auf der BNB Chain aufgrund inkonsistenter Buchhaltung über mehrere Staking-Modi hinweg für rund 1.200 $ ausgenutzt. Der Vertrag teilte dieselbe Positionsvariable für stake2()/withdraw2() und stake3()/withdraw3(), obwohl diese Funktionen unterschiedliche Token-Körbe und -Verhältnisse handhabten. Der Angreifer hinterlegte über den leichteren stake2()-Modus und löste über den schwereren withdraw3()-Modus aus, wobei er wiederholt überschüssige Token extrahierte.

Hintergrund

Dies ist ein Staking-Vertrag mit mehreren Stake- und Withdrawal-Modi. Der Standard-Pfad stake() und withdraw() ist der vollständige Staking-Modus, der einen Korb aus Pangolin, Bzzt und Bzzone zusammen mit der Logik zur Belohnungsabrechnung handhabt. Der Pfad stake3() und withdraw3() verwendet denselben Drei-Token-Korb und dasselbe Einzahlungs-/Auszahlungsverhältnis, überspringt jedoch den zusätzlichen Belohnungsabrechnungsfluss. Im Gegensatz dazu ist der Pfad stake2() und withdraw2() ein leichterer Modus, der nur Pangolin und Bzzt handhabt und daher eine andere Token-Kombination und ein anderes Verhältnis als die beiden anderen Modi verwendet.

Schwachstellenanalyse

Die Grundursache war eine inkonsistente Buchhaltung im Vertrag 0x29d36c...774137. Obwohl stake2()/withdraw2() und stake3()/withdraw3() unterschiedliche Token-Körbe handhabten, aktualisierten sie alle dieselben Variablen _exit[msg.sender] und _totalSupply. Infolgedessen konnte eine über den leichteren stake2()-Modus erstellte Position über den schwereren withdraw3()-Modus eingelöst werden.

In der Praxis zog stake2(amount) nur amount von Pangolin und amount von Bzzt ein, aber withdraw3(amount) gab amount von Pangolin, 10 * amount von Bzzt und 10 * amount von Bzzone zurück. Das bedeutete, dass das Staking von 20e18 Pangolin und 20e18 Bzzt über stake2() ein _exit-Guthaben schuf, das später zum Abheben von 20e18 Pangolin, 200e18 Bzzt und 200e18 Bzzone über withdraw3() verwendet werden konnte. Durch Wiederholung dieses Missverhältnisses extrahierte der Angreifer kontinuierlich überschüssige Token aus dem Vertrag.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x7fcd5882...323f8d.

• Schritt 1: Der Angreifer setzte einen Vertrag unter 0x9bce07d8bbe4f19dfe465710ff9612878bfe3302 ein, finanzierte ihn mit 0,05 BNB, wickelte die Gelder in WBNB ein, tauschte sie gegen genau 20e18 Pangolin, 20e18 Bzzt und 200e18 Bzzone und genehmigte dem Staking-Vertrag die Ausgabe der erworbenen Token.

  

• Schritt 2: Der Angreifer rief stake2() mit dem Input 20e18 auf, der 20e18 Pangolin und 20e18 Bzzt in den Staking-Vertrag übertrug und das gemeinsame _exit-Guthaben des Angreifers um 20e18 erhöhte.

  

• Schritt 3: Der Angreifer rief dann withdraw3() mit dem Input 20e18 auf. Da withdraw3() nur das gemeinsame _exit-Guthaben prüfte, gab der Vertrag 20e18 Pangolin, 200e18 Bzzt und 200e18 Bzzone zurück, obwohl die Position über stake2() erstellt worden war.

  

• Schritt 4: Der Angreifer wiederholte den Zyklus stake2() -> withdraw3() viele Male innerhalb derselben Transaktion. In jeder Runde wurden die zurückgegebenen Pangolin und ein kleiner Teil der zurückgegebenen Bzzt für den nächsten stake2()-Aufruf wiederverwendet, während Bzzone an den Staking-Vertrag zurückgesendet wurde, damit spätere withdraw3()-Aufrufe weiterhin erfolgreich sein konnten. Durch diese Schleife erhöhte der Angreifer sein Bzzt-Guthaben von 20e18 auf 16.400e18.

• Schritt 5: Der Angreifer tauschte die erworbenen Token zurück in WBNB, entpackte die Gelder in BNB und überwies etwa 2.007e18 BNB zurück an die Angreifer-EOA, womit der Exploit abgeschlossen wurde.

  

Schlussfolgerung

Um ähnliche Exploits zu verhindern, sollten Staking-Verträge die Buchhaltung für jeden Modus isolieren und sicherstellen, dass jeder Withdrawal-Pfad die genaue Asset-Zusammensetzung und das Verhältnis seines entsprechenden Einzahlungspfads übereinstimmt.

6. MYX Vorfall

Kurze Zusammenfassung

Am 25. März 2026 wurde der sMYX-Vertrag des MYX Network auf Ethereum ausgenutzt, was zu einem Verlust von rund 6,67 Millionen MYX-Token aus dem Pool führte (ca. 3.600 $ Gewinn). Die Grundursache war eine fehlerhafte Interaktion zwischen der Angebotsbuchhaltung der Transferfunktion und der Dividendenverteilungslogik im sMYX-Vertrag. Durch wiederholtes Übertragen von sMYX zwischen kontrollierten Konten blähte der Angreifer die Gewinn pro Anteil-Variable auf, fabrizierte nicht gedeckte Dividenden und zog mehr MYX ab, als ursprünglich eingezahlt wurde.

Hintergrund

Der sMYX-Vertrag (0x404328...d27F66) folgt einem Dividendenverteilungs-Token-Modell. Benutzer zahlen MYX-Token über eine Kauf-Funktion ein und erhalten sMYX-Anteile, die ihren Anteil darstellen. Dividenden werden mit einem globalen Akkumulator (Gewinn pro Anteil) in stor_11 verfolgt. Die beanspruchbaren Dividenden jedes Benutzers werden als Differenz zwischen seinem proportionalen Anteil am akkumulierten Gewinn und seiner registrierten Auszahlungsbasis berechnet. Dieses Modell ähnelt konzeptionell früheren Reflektions-Tokens, bei denen eingehender Wert unter den bestehenden Haltern umverteilt wird.

Schwachstellenanalyse

Die Schwachstelle ergibt sich aus einer fehlerhaften Interaktion zwischen Angebotsbuchhaltung und Dividendenverteilungslogik. Die Transferfunktion führt fälschlicherweise neue Dividenden ein, indem sie die globale Gewinn pro Anteil-Variable basierend auf dem übertragenen Betrag dividiert durch das aktuelle Gesamtangebot erhöht. Diese Operation ist durch keinen tatsächlichen Zufluss von MYX-Token gedeckt, was bedeutet, dass Dividenden effektiv aus interner Buchhaltung und nicht aus tatsächlicher wirtschaftlicher Aktivität geschaffen werden. Gleichzeitig reduziert die Funktion das registrierte Gesamtangebot um den übertragenen Betrag aufgrund der umgekehrten Semantik des Subtraktionshelfers, obwohl keine Token tatsächlich verbrannt werden.

Folglich führt jede nachfolgende Überweisung zu einer größeren Erhöhung des Gewinn pro Anteil-Wertes, da der gleiche Übertragungsbetrag durch ein immer kleineres Gesamtangebot geteilt wird.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x843c9ea7...a55b90.

• Schritt 1: Der Angreifer pumpte Kapital über einen Flash-Swap auf und wandelte es in MYX um, zahlte dann in den sMYX-Vertrag ein, um eine dominante Anteilsposition innerhalb des Dividenden-Systems zu erlangen, und stellte sicher, dass die Kontrolle über die meisten zukünftigen Belohnungsverteilungen gewährleistet war.

• Schritt 2: Der Angreifer teilte seine Position auf zwei kontrollierte Verträge auf und initiierte eine koordinierte Schleife, die zwischen Dividendenerfüllung und Zustandsmanipulation wechselte, was eine wiederholte Durchlaufführung des anfälligen Abrechnungspfads ermöglichte.

• Schritt 3: Durch wiederholte Überweisungen zwischen kontrollierten Konten blähte der Angreifer die Gewinn pro Anteil-Variable des Protokolls künstlich auf und reduzierte gleichzeitig das registrierte Gesamtangebot, wodurch nicht gedeckte Dividenden geschaffen und ihre Verteilungsrate verstärkt wurden.

• Schritt 4: Durch kontinuierliches Abheben nach jedem Manipulationszyklus zog der Angreifer den Großteil dieser fabrizierten Belohnungen ab und zog effektiv MYX-Reserven aus dem Protokoll ab, ohne neues Kapital einzubringen.

• Schritt 5: Der Angreifer schloss alle Positionen, tauschte die abgezogenen MYX zurück in WETH, zahlte den Flash-Loan zurück und behielt den verbleibenden Saldo als Gewinn.

Schlussfolgerung

Dieser Vorfall ist nicht nur eine Folge eines Ponzi-ähnlichen Wirtschaftsdesigns, sondern vielmehr ein kritischer Fehler in der Implementierung der Dividendenbuchhaltung. Um solche Schwachstellen zu mindern, dürfen Übertragungsoperationen das Gesamtangebot nicht beeinflussen oder die Dividendenausschüttung auslösen, und die Aktualisierungen des Gewinns pro Anteil dürfen nur erfolgen, wenn reale Vermögenswerte eingebracht werden.

7. Unbekannter Vorfall 4

Kurze Zusammenfassung

Am 26. März 2026 wurde ein TUR-Staking-Vertrag mit Empfehlungsprämien auf der BNB Chain für rund 133.500 $ ausgenutzt. Der Stake-Vertrag berechnete den Einzahlungswert anhand von Live-AMM-Spotpreisen, die innerhalb einer einzigen Transaktion manipulierbar sind. Der Angreifer nutzte einen Flash-Loan, um den TUR-Preis aufzublähen, setzte während des aufgeblähten Zeitfensters ein und zog über selbst kontrollierte Empfehlungskonten übermäßig hohe TUR-Prämien ab.

Hintergrund

Der Stake-Vertrag (0x03D809...415Abe) ist ein TUR-Staking-Vertrag mit Empfehlungsprämien. Benutzer binden zuerst eine Up-Line über bind() und rufen dann stake() auf, was den gestakten TUR verbrennt (an 0xdead sendet) und dem Benutzer interne power gutschreibt, ein Gewicht, das bestimmt, wie viel TUR-Prämie der Benutzer später beanspruchen kann.

power wird nicht zu einem festen Verhältnis zugewiesen. Stattdessen rechnet getPowerAmount() die eingezahlte TUR in einen USDT-denominierten Wert um, indem es zwei Live-AMM-Preise verknüpft: TUR/NOBEL und NOBEL/USDT, beide aus aktuellen Paarreserven ausgelesen. Der Vertrag gewährt auch Bonuspunkte an Erst- und Zweit-Level-Empfehlungsgeber über _distributeRefPower().

Schwachstellenanalyse

Die Grundursache war eine unsichere Spotpreis-Abhängigkeit im Stake-Vertrag. Bei jeder Einzahlung berechnet stake() uValue = getPowerAmount(amount), wandelt ihn in _power = _uValue * 100 um, aktualisiert die Buchhaltung des Stakers und ruft dann _distributeRefPower() auf, um zusätzliche Punkte an vorgelagerte Empfehlungsgeber weiterzugeben.

Insbesondere wird uValue wie folgt berechnet:

$uValue=getPowerAmount(amount)uValue\; =\; getPowerAmount(amount)$

wobei getPowerAmount() effektiv ist:

$amount\times \text{TUR/NOBEL Spotpreis}\times \text{NOBEL/USDT Spotpreis}amount\; \backslash times\; \backslash text\{TUR/NOBEL\; Spotpreis\}\; \backslash times\; \backslash text\{NOBEL/USDT\; Spotpreis\}$

Die Implementierung liest diese Preise direkt aus aktuellen Paarreserven über getReserves(), sodass die Staking-Bewertung vollständig von Spotpreisen innerhalb derselben Transaktion statt von einem manipulationsresistenten Orakel oder TWAP abhängt.

Dies ermöglicht es einem Angreifer, die On-Chain-Bewertung von TUR vorübergehend aufzublähen, während des manipulierten Zeitfensters einzusetzen und überhöhte uValue und power zu erhalten. Die Empfehlungslogik verstärkt den Schaden: _distributeRefPower() gewährt 20 % der Macht des Stakers dem ersten Empfehlungsgeber und 5 % dem zweiten Empfehlungsgeber, aber diese zusätzlichen Zuweisungen werden nicht durch eine entsprechende Aktualisierung von rewardDebt für diese Empfehlungsgeber ausgeglichen. Infolgedessen können vom Angreifer kontrollierte Empfehlungskonten sofort übermäßige TUR-Prämien vom Stake-Vertrag beanspruchen.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x96c9ce3c...81e348.

• Schritt 1: Der Angreifer lieh sich 1.900.000e18 USDT vom Moolah-Vertrag von ListaDAO als Flash-Loan-Kapital.

• Schritt 2: Der Angreifer nutzte das geliehene Kapital, um die NOBEL-USDT- und TUR-NOBEL-Pools zu manipulieren, wodurch die Spot-Bewertung von TUR vorübergehend stark anstieg.

• Schritt 3: Während des manipulierten Zeitfensters setzte der Angreifer 7.770.707e18 TUR in den Stake-Vertrag ein. Die Transaktion löste ein StakeEvent aus, das einen massiv aufgeblähten uValue von 8.283.864e18 und die entsprechende power von 828.386.488e18 zeigte.

• Schritt 4: Da der Angreifer bereits selbst kontrollierte Empfehlungskonten eingerichtet hatte, vergab _distributeRefPower() ihnen zusätzliche Prämienpunkte, die aus dem manipulierten Einsatz stammten. Die Erst- und Zweitempfehlungsgeber erhielten die erwarteten Empfehlungszuweisungen von 20 % bzw. 5 %.

• Schritt 5: Die verstärkten Empfehlungskonten beanspruchten dann TUR-Prämien aus dem Stake-Vertrag. In derselben Transaktion überwies Stake 15.238.941e18 TUR an 0xFd11...AcEaB und 3.809.924e18 TUR an 0x9007...E550B; beide Adressen leiteten sofort die gleichen Beträge an den Angreifer weiter. Das Auszahlungsverhältnis von 4:1 entspricht der Aufteilung der Empfehlungsstärken von 20 % gegenüber 5 % im Vertrag.

• Schritt 6: Die Transaktion zeigt auch, wie Gebühren von Stake an das Fond-Wallet 0xb302...89923 flossen, was der Implementierung von claim() entspricht, die eine Gebühr von 3 % TUR erhebt, bevor sie Prämien an Anspruchsberechtigte sendet.

• Schritt 7: Nach der Entnahme der verstärkten TUR-Prämien tauschte der Angreifer die Erlöse zurück in USDT, zahlte den 1.900.000 USDT Flash-Loan zurück und übertrug 133.490e18 USDT an 0xEf67...4e5898 als Gewinn.

Schlussfolgerung

Dieser Vorfall wurde durch ein manipulierbares Prämienbewertungsmodell im Stake-Vertrag verursacht, nicht durch die separate LP-Dividendenbuchhaltung des TUR-Tokens. Indem die Staking-Macht und die Empfehlungsprämien an die Live-AMM-Reservenverhältnisse gebunden wurden, ermöglichte der Vertrag einem durch Flash-Loan finanzierten Angreifer, den Spotpreis von TUR aufzublähen, übermäßige Prämienpunkte zu generieren und TUR aus dem Staking-Vertrag über selbst kontrollierte Empfehlungskonten abzuziehen. Ein sichereres Design würde Spot-Reserve-Preise durch ein manipulationsresistentes Orakel oder einen ausreichend langen TWAP ersetzen und sicherstellen, dass jede Erhöhung der Empfehlungsprämien mit einer konsistenten Prämien-Schuldenbuchhaltung gepaart wird.

8. EST Token Vorfall

Kurze Zusammenfassung

Am 27. März 2026 wurde der BNBDeposit-Vertrag auf der BNB Chain aufgrund zweier Probleme für rund 92.300 $ ausgenutzt: eine Spotpreis-Abhängigkeit in BNBDeposit und ein fehlerhafter Burn-Mechanismus im EST-Token. Die Preisabhängigkeit ermöglichte es dem Angreifer, eine große Menge EST zu erwerben, und der fehlerhafte Burn-Mechanismus ermöglichte es dem Angreifer, den EST-WBNB-Pool durch eine Sandwich-artige Manipulation abzuziehen.

Schwachstellenanalyse

Die Grundursache des Vorfalls ist zweifach:

1. Die Funktion onTokenReceived() im BNBDeposit-Vertrag (0xE71547...d29A61) berechnete die beanspruchbaren Beträge der Benutzer basierend auf dem Guthaben des Vertrags und dem Spotpreis von EST, die beide leicht manipulierbar sind.

   

2. Der EST-Token (0xD4524B...498a91) implementierte einen fehlerhaften Burn-Mechanismus, der es einem Angreifer ermöglicht, EST im EST-WBNB-Pool zu verbrennen, indem er EST direkt an den Pool überträgt.

   

Infolgedessen nutzte der Angreifer beide Schwachstellen aus, um einen Sandwich-Angriff durchzuführen und WBNB aus dem EST-WBNB-Pool zu entziehen.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x2f1c33ea...bd1626.

• Schritt 1: Der Angreifer lieh sich 250.000e18 WBNB über Moolah und wickelte 15e18 WBNB in BNB für den Angriff aus.

• Schritt 2: Der Angreifer überwies wiederholt 0,3e18 BNB 34 Mal (insgesamt 10,2e18 BNB) an BNBDeposit. Jede direkte Überweisung löste die Einzahlungslogik aus. In diesem Schritt erhielt der Angreifer ca. 9.100e18 LP-Token (in virtueller Buchhaltung) und 2,65e18 WBNB als Bonus.

• Schritt 3: Der Angreifer tauschte 400e18 WBNB gegen ca. 822 Mio. EST und legte BNBDeposit als Empfänger fest, wodurch sowohl das EST-Guthaben von BNBDeposit als auch der EST-Preis im Pool aufgebläht wurden.

• Schritt 4: Der Angreifer überwies 1e18 EST an BNBDeposit, um den Anspruchsmechanismus auszulösen, und erhielt 20 Mio. EST basierend auf dem verstärkten Preis und Guthaben.

• Schritt 5: Der Angreifer tauschte 245.000e18 WBNB gegen ca. 330 Mio. EST und legte BNBDeposit als Empfänger fest.

• Schritt 6: Der Angreifer führte ca. 150 Mal Transfer-Skimming-Aktionen durch, um kontinuierlich EST im EST-WBNB-Pool zu verbrennen.

• Schritt 7: Der Angreifer tauschte die verbleibenden EST gegen 245.560e18 WBNB.

• Schritt 8: Der Angreifer zahlte den Flash-Loan zurück und erzielte 150 WBNB Gewinn.

Schlussfolgerung

Dieser Vorfall wurde durch zwei Probleme verursacht: eine Spotpreis-Abhängigkeit und ein fehlerhafter Burn-Mechanismus. Um ähnliche Risiken zu mindern, müssen Projekte vor der Bereitstellung zuverlässige Preis-Orakel und eine solide Token-Burn-Logik gewährleisten.

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden bei der Durchführung von Code-Audits (einschließlich Smart Contracts, Blockchain und Wallets), der Echtzeit-Abwehr von Angriffen, der Analyse von Vorfällen, der Rückverfolgung illegaler Gelder und der Erfüllung von AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg unterstützen.

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

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

• Offizieller Twitter-Account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance