In der vergangenen Woche (23.03.2026 - 29.03.2026) hat BlockSec acht Angriffsvorfälle 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 sind in den folgenden Unterabschnitten aufgeführt.

Unbekannter Vorfall 1

Kurze Zusammenfassung

Am 23. März 2026 wurde ein nicht verifizierter Smart Contract auf Ethereum aufgrund eines Integer-Überlaufs in seiner Verteilungslogik um etwa 97.000 $ ausgenutzt. Die Funktion 0x317de4f6() summierte vom Benutzer kontrollierte Token-Beträge ohne Überlaufschutz, was es dem Angreifer ermöglichte, durch Bezahlung von nur 1 wei USDT über die claim()-Funktion einen Wrap-around auszulösen und den gesamten USDT-Saldo des Smart Contracts abzuziehen.

Schwachstellenanalyse

Die Hauptursache war ein Integer-Überlauf in der Funktion 0x317de4f6() des Smart Contracts 0xF0a105...568C97. Die Funktion akzeptiert ein Array von Datensätzen (jeweils mit einem Konto und einem Betrag) und summiert alle Beträge zu totalAmount, indem sie das Array durchläuft. Da der Summierung Überprüfung fehlte, konnte ein Angreifer manipulierte Datensätze liefern, deren Beträge uint256 überlaufen ließen, wodurch totalAmount willkürlich klein wurde, während die einzelnen Zuteilungen groß blieben.

Angriffsanalyse

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

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

  

• Schritt 2: Der Angreifer fragte den USDT-Saldo des Ziel-Smart-Contracts ab und rief dann 0x317de4f6() mit einem manipulierten Array auf. Ein Betrag wurde nahe der Obergrenze von uint256 gesetzt, und der andere wurde auf den USDT-Saldo des Ziel-Smart-Contracts gesetzt. Ihre Summe überlief auf 1, wodurch der Angreifer nur 1 wei USDT bezahlen musste, während eine Zuteilung in Höhe des gesamten USDT-Saldos des Ziels aufgezeichnet wurde.

  

• Schritt 3: Der Angreifer rief claim() auf, um 97.812e6 USDT vom Ziel-Smart-Contract abzuheben.

  

• 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 war.

Schlussfolgerung

Dieser Vorfall verdeutlicht die Risiken der Verwendung von unüberprüfter Arithmetik in Solidity-Versionen vor 0.8.0. Alle kritischen Finanzberechnungen sollten explizit Überlauf-sichere Arithmetik verwenden (z. B. SafeMath oder Solidity >=0.8.x), um Wrap-around-Probleme zu vermeiden.

Unbekannter Vorfall 2

Kurze Zusammenfassung

Am 23. März 2026 wurde ein nicht verifizierter Smart Contract auf Ethereum aufgrund einer Reentrancy-Schwachstelle um etwa 11.000 $ ausgenutzt. Die Funktion 0xbe16634e() aktualisierte die Liquiditätsbuchhaltung vor der Abwicklung und rief einen externen Callback ohne Reentrancy-Schutz auf. Indem der Angreifer die Funktion wiederholt aufrief, bevor der vorherige Aufruf abgewickelt wurde, blähte er seine aufgezeichnete Liquidität auf und zog später mehr USDC und WETH ab, als er tatsächlich eingezahlt hatte.

Schwachstellenanalyse

Die Hauptursache ist ein Reentrancy-Problem in der Funktion 0xbe16634e() des Smart Contracts 0x39Ed37...9C6b08. Diese Funktion aktualisiert liquiditätsbezogene Zustände, einschließlich Benutzerliquidität und Tick-Reserven, vor der Abwicklung und ruft über msg.sender.call() einen externen Callback ohne Reentrancy-Guard auf. Da die Saldoüberprüfung auf Basis einzelner Aufrufe erfolgt, kann der Angreifer die Funktion rekursiv wieder aufrufen und die interne Liquiditätsbuchhaltung aufblähen, während eine einzige 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 lieh sich 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 Ziel-Smart-Contract die Funktion 0x7c65be42() des Angreifers auf, die 0xbe16634e() wieder aufrief, bevor der vorherige Aufruf abgewickelt wurde.

  

• Schritt 3: Durch wiederholtes Ausführen dieses Reentrancy-Flusses erhöhte der Angreifer kontinuierlich seine aufgezeichnete Liquidität. Im tiefsten Aufruf überwies der Angreifer die erforderlichen Token einmal, was ausreichte, um die verschachtelten Saldoüberprüfungen zu erfüllen.

  

• Schritt 4: Nachdem er die aufgezeichnete Liquidität aufgebläht hatte, prüfte der Angreifer den Poolzustand und zahlte zusätzliche Gelder in den Pool ein, damit dieser genügend USDC und WETH enthielt, um die anstehende Auszahlung zu decken.

  

• Schritt 5: Der Angreifer rief 0xbe16634e() erneut 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, die Liquiditätsbuchhaltung vor der Abwicklung zu aktualisieren, 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.

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, um etwa 512.000 $ ausgenutzt. Das Protokoll verwendet CYRP NFT-Positionen, um einen proportionalen Anteil seiner PancakeSwap V3-Liquidität darzustellen, aber die Umwandlung von Benutzeranteil in zugrunde liegende Liquidität liest slot0(), was innerhalb derselben Transaktion manipulierbar ist. Durch 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 hinweg darstellen. Benutzer können ihre Einlage plus Prämien ü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 gesamte Liquidität der Protokollposition 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 Smart Contract löst keinen festen Eigentumsanteil direkt ein. Stattdessen schätzt er zuerst den aktuellen USDT-Äquivalentwert der Position anhand des Live-Pool-Preises und wandelt dann den angeforderten USDT-Betrag in einen proportionalen Liquiditätsbetrag um.

Dies ist unsicher, da slot0() innerhalb derselben Transaktion manipulierbar ist. Durch vorübergehendes Verschieben des Poolpreises kann ein Angreifer availableUSDT verzerren, was die berechnete liquidityToUse direkt beeinflusst.

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 ca. 1.798 ETH.

• Schritt 2: Der Angreifer führte einen großen Swap von ETH zu USDT im Zielpool durch, in dem das Protokoll Liquidität verwaltete, und verschob dabei absichtlich den Poolpreis und den aktuellen Tick. Parallel dazu überwies der Angreifer die CYRP NFT-Position #15505 über safeTransferFrom() an den Angriffs-Smart-Contract.

• 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. Es rief dann 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 überwies den verbleibenden Gewinn (ca. 512.000 $) an EOA 0xf96EB1...3b63b.

Schlussfolgerung

Die Abhilfemaßnahmen sollten den Spotpreis slot0() durch einen manipulationsresistenten Preis (TWAP über ein ausreichendes Beobachtungsfenster oder einen externen Orakel wie Chainlink) ersetzen, bevor die Liquidität in abhebbares USDT umgewandelt wird.

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 um etwa 679.000 $ ausgenutzt. Der Angreifer setzte zwei bösartige Smart Contracts ein, um die Kauf-/Verkaufslimits von BCE zu umgehen, und löste Token-Burns gegen die Liquiditätspool-Reserven aus, wodurch der Preis des Pools manipuliert und seine USDT abgezogen wurden.

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 aus der PancakeSwap-Paaradresse anstatt aus dem eigenen Saldo des Benutzers zu verbrennen. Bei Verkaufsoperationen sammelt der Smart Contract 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 Code-Pfad ausgeführt, der Token aus dem Paar verbrennt und sync() aufruft.

Da der Angreifer das Handelsvolumen kontrolliert und Poolreserven manipulieren kann, kann er scheduledDestruction auf einen beliebigen Wert setzen und einen Burn auslösen, der das BCE-Reserven 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 Smart Contract (MC1) auf, um über mehrere Flash-Loans und einen Kreditpool 123,5 Mio. USDT zu leihen.

• Schritt 2: Der Angreifer setzte einen zweiten bösartigen Smart Contract (MC2) ein und überwies 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 überwies 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, wodurch die Variable scheduledDestruction basierend auf den Poolreserven und dem Tauschbetrag auf ~174K gesetzt wurde. 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, wodurch die BCE-Reserve weiter auf ~174K verzerrt wurde.

• Schritt 7: Der Angreifer überwies 3,484 Mio. BCE und die verbleibenden USDT von MC2 an MC1. Da scheduledDestruction größer als 0 war (d. h. ~174K), löste die Übertragung von BCE Burns aus, die die BCE-Reserve auf ~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 ca. 679.000 $.

Schlussfolgerung

Dieser Vorfall wurde durch einen grundlegenden Fehler in der ökonomischen Logik des Tokens verursacht, bei dem eine vom Benutzer beeinflusste Zustandsvariable verwendet wurde, um den Saldo des Liquiditätspools anstelle des eigenen Saldos des Benutzers zu ändern. Der Smart Contract ging implizit davon aus, dass die durch Handelsaktivitäten abgeleitete Zerstörung die Kosten des Benutzers widerspiegeln würde, aber in der Praxis ermöglichte er es Angreifern, einen aufgeschobenen Burn zu konstruieren, der gegen LP-Reserven abgerechnet wurde. Infolgedessen konnten Angreifer die Pooltiefe und -preisgestaltung mit begrenzter Kapitalexposition manipulieren und Wert von den Liquiditätsanbietern extrahieren.

Unbekannter Vorfall 3

Kurze Zusammenfassung

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

Hintergrund

Dies ist ein Staking-Smart-Contract mit mehreren Stake- und Withdrawal-Modi. Der Standardpfad stake() und withdraw() ist der vollständige Staking-Modus, der einen Korb aus Pangolin, Bzzt und Bzzone zusammen mit Logik zur Prämienbuchhaltung handhabt. Der Pfad stake3() und withdraw3() verwendet denselben Drei-Token-Korb und dasselbe Einzahlungs-/Abhebeverhältnis, überspringt jedoch den zusätzlichen Prämienbuchhaltungsfluss. 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 anderen beiden Modi verwendet.

Schwachstellenanalyse

Die Hauptursache war eine inkonsistente Buchhaltung im Smart Contract 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, aber withdraw3(amount) lieferte amount von Pangolin, 10 * amount von Bzzt und 10 * amount von Bzzone zurück. Das bedeutet, dass das Staken von 20e18 Pangolin und 20e18 Bzzt über stake2() ein _exit-Guthaben erzeugte, das später für den Rückzug von 20e18 Pangolin, 200e18 Bzzt und 200e18 Bzzone über withdraw3() verwendet werden konnte. Durch Wiederholung dieser Diskrepanz extrahierte der Angreifer kontinuierlich überschüssige Token aus dem Smart Contract.

Angriffsanalyse

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

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

  

• Schritt 2: Der Angreifer rief stake2() mit der Eingabe 20e18 auf, wodurch 20e18 Pangolin und 20e18 Bzzt in den Staking-Smart-Contract eingezahlt und das gemeinsame _exit-Guthaben des Angreifers um 20e18 erhöht wurde.

  

• Schritt 3: Der Angreifer rief dann withdraw3() mit der Eingabe 20e18 auf. Da withdraw3() nur das gemeinsame _exit-Guthaben prüfte, zahlte der Smart Contract 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-Smart-Contract zurückgeschickt 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, wickelte die Gelder zu BNB aus und überwies ca. 2,007e18 BNB zurück an die Angreifer-EOA, womit der Exploit abgeschlossen war.

  

Schlussfolgerung

Um ähnliche Exploits zu verhindern, sollten Staking-Smart-Contracts die Buchhaltung für jeden Modus isolieren und sicherstellen, dass jeder Withdrawal-Pfad die genaue Zusammensetzung und das Verhältnis der Vermögenswerte seines entsprechenden Einzahlungspfades widerspiegelt.

MYX Vorfall

Kurze Zusammenfassung

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

Hintergrund

Der sMYX-Smart-Contract (0x404328...d27F66) folgt einem Dividendenverteilungs-Token-Modell. Benutzer zahlen MYX-Token über eine Kauf-Funktion ein und erhalten sMYX-Anteile, die ihren Stake repräsentieren. Dividenden werden über einen globalen Akkumulator (Gewinn pro Anteil) verfolgt, der in stor_11 gespeichert ist. Die abrufbaren Dividenden jedes Benutzers werden als Differenz zwischen ihrem proportionalen Anteil am akkumulierten Gewinn und ihrer aufgezeichneten Auszahlungsbasis berechnet. Dieses Modell ähnelt konzeptionell früheren Reflexions-Token, bei denen eingehende Werte unter den bestehenden Haltern umverteilt werden.

Schwachstellenanalyse

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

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

Angriffsanalyse

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

• Schritt 1: Der Angreifer baute Kapital durch einen Flash-Swap auf und wandelte es in MYX um, zahlte dann in den sMYX-Smart-Contract ein, um eine dominante Anteilsposition innerhalb des Dividenden-Systems zu erlangen und so die Kontrolle über die meisten zukünftigen Prämienausschüttungen sicherzustellen.

• Schritt 2: Der Angreifer teilte seine Position auf zwei kontrollierte Smart Contracts auf und initiierte eine koordinierte Schleife, die zwischen Dividendenrealisierung und Zustandsmanipulation wechselte, was wiederholte Durchläufe des anfälligen Buchhaltungspfades ermöglichte.

• Schritt 3: Durch wiederholte Übertragungen zwischen kontrollierten Konten blähte der Angreifer künstlich die Gewinn-pro-Anteil-Variable des Protokolls auf, während er gleichzeitig das aufgezeichnete Gesamtangebot reduzierte, nicht gedeckte Dividenden schuf und ihre Ausschüttungsrate erhöhte.

• Schritt 4: Durch kontinuierliches Abheben nach jedem Manipulationszyklus zog der Angreifer die Mehrheit dieser fabrizierten Prämien ab und zog effektiv MYX-Reserven aus dem Protokoll ab, ohne neues Kapital einzuführen.

• Schritt 5: Der Angreifer schloss alle Positionen aus, tauschte die abgezogenen MYX zurück gegen 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 ökonomischen Designs, sondern vielmehr ein kritischer Fehler in der Implementierung der Dividendenbuchhaltung. Um solche Schwachstellen zu mindern, dürfen Transferoperationen das Gesamtangebot nicht beeinflussen oder Dividendenverteilungen auslösen, und Gewinn-pro-Anteil-Aktualisierungen dürfen nur dann erfolgen, wenn reale Vermögenswerte eingebracht werden.

Unbekannter Vorfall 4

Kurze Zusammenfassung

Am 26. März 2026 wurde ein TUR-Staking-Smart-Contract mit Empfehlungsprovisionen auf der BNB Chain um etwa 133.500 $ ausgenutzt. Der Stake-Smart-Contract berechnete den Einzahlungswert mithilfe von Live-AMM-Spotpreisen, die innerhalb einer einzelnen Transaktion manipulierbar sind. Der Angreifer nutzte einen Flash-Loan, um den TUR-Preis aufzublähen, tätigte während des aufgeblähten Zeitraums ein Staking und zog über selbst kontrollierte Empfehlungskonten übermäßige TUR-Prämien ab.

Hintergrund

Der Stake-Smart-Contract (0x03D809...415Abe) ist ein TUR-Staking-Smart-Contract mit Empfehlungsprovisionen. Benutzer binden zuerst einen Uplink über bind(), rufen dann stake() auf, der den gestakten TUR verbrennt (an 0xdead sendet) und dem Benutzer internes power gutschreibt, ein Gewicht, das bestimmt, wie viel TUR-Prämie der Benutzer später abrufen kann.

power wird nicht zu einem festen Verhältnis zugewiesen. Stattdessen wandelt getPowerAmount() die eingezahlten TUR in einen USDT-denominierten Wert um, indem zwei Live-AMM-Preise verkettet werden: TUR/NOBEL und NOBEL/USDT, beide aus den aktuellen Paarreserven ausgelesen. Der Smart-Contract gewährt auch Bonuspunkte an erste und zweite Empfehlungsgeber über _distributeRefPower().

Schwachstellenanalyse

Die Hauptursache war eine unsichere Spotpreis-Abhängigkeit im Stake-Smart-Contract. Bei jeder Einzahlung berechnet stake() uValue = getPowerAmount(amount), wandelt es in _power = _uValue * 100 um, aktualisiert die Buchhaltung des Stakers und ruft dann _distributeRefPower() auf, um zusätzliche Punkte an Upstream-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 den aktuellen Paarreserven über getReserves(), sodass die Staking-Bewertung vollständig von Spotpreisen innerhalb derselben Transaktion abhängt und nicht von einem manipulationsresistenten Orakel oder TWAP.

Dies ermöglicht es einem Angreifer, die On-Chain-Bewertung von TUR vorübergehend aufzublähen, während des manipulierten Zeitraums zu staken und überhöhte uValue und power zu erhalten. Die Empfehlungslogik verstärkt den Schaden: _distributeRefPower() vergibt 20 % der Leistung des Stakers an den ersten Empfehlungsgeber und 5 % an den 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 Empfehlungsnonzero sofort übermäßige TUR-Prämien aus dem Stake-Smart-Contract beanspruchen.

Angriffsanalyse

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

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

• Schritt 2: Der Angreifer nutzte das geliehene Kapital, um die NOBEL-USDT- und TUR-NOBEL-Pools zu manipulieren und damit die Spotbewertung von TUR vorübergehend stark nach oben zu treiben.

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

• Schritt 4: Da der Angreifer bereits selbst kontrollierte Empfehlungsnonzero eingerichtet hatte, vergab _distributeRefPower() ihnen zusätzliche Prämienpunkte, die aus dem manipulierten Stake abgeleitet wurden. Der erste und zweite Empfehlungsgeber erhielten die erwarteten Empfehlungszuweisungen von 20 % bzw. 5 %.

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

• Schritt 6: Die Transaktion zeigt auch Gebühren für die Prämieneintreibung, die vom Stake-Smart-Contract an das Fonds-Wallet 0xb302...89923 fließen, was mit der 3%igen TUR-Gebühr übereinstimmt, die claim() vor dem Versand von Prämien an die Anspruchsberechtigten erhebt.

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

Schlussfolgerung

Dieser Vorfall wurde durch ein manipulierbares Prämienbewertungsmodell im Stake-Smart-Contract verursacht, nicht durch die separate LP-Dividendenbuchhaltung des TUR-Tokens. Durch die Kopplung von Staking-Leistung und Empfehlungsprovisionen an Live-AMM-Reservenverhältnisse erlaubte der Smart-Contract einem durch Flash-Loan finanzierten Angreifer, den Spotpreis von TUR aufzublähen, übermäßige Prämienpunkte zu erzeugen und TUR aus dem Staking-Smart-Contract über selbst kontrollierte Empfehlungsnonzero abzuzweigen. Ein sichereres Design würde Spot-Reservenpreise durch ein manipulationsresistentes Orakel oder einen ausreichend langen TWAP ersetzen und sicherstellen, dass jede Erhöhung der Empfehlungsleistung mit einer konsistenten Buchhaltung der Prämienschulden einhergeht.

EST Token Vorfall

Kurze Zusammenfassung

Am 27. März 2026 wurde der BNBDeposit-Smart-Contract auf der BNB Chain aufgrund von zwei Problemen ausgenutzt: einer Spotpreis-Abhängigkeit in BNBDeposit und einem fehlerhaften 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-ähnliche Manipulation abzuzweigen.

Schwachstellenanalyse

Die Hauptursache des Vorfalls ist zweigeteilt:

1. Die Funktion onTokenReceived() im BNBDeposit-Smart-Contract (0xE71547...d29A61) berechnete den abrufbaren Betrag der Benutzer basierend auf dem Saldo des Smart-Contracts und dem Spotpreis von EST, die beide leicht manipulierbar sind.

   

2. Das 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 abzuzweigen.

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 an BNBDeposit (insgesamt 10,2e18 BNB). Jeder direkte Transfer löste die Einzahlungslogik aus. In diesem Schritt erhielt der Angreifer ~9.100e18 LP-Token (in virtueller Buchhaltung) und 2,65e18 WBNB als Bonus.

• Schritt 3: Der Angreifer tauschte 400e18 WBNB gegen ~822 Mio. EST und setzte BNBDeposit als Empfänger ein, wodurch sowohl der EST-Saldo 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 erhöhten Preis und Saldo.

• Schritt 5: Der Angreifer tauschte 245.000e18 WBNB gegen ~330 Mio. EST und setzte BNBDeposit als Empfänger ein.

• Schritt 6: Der Angreifer führte Transfer-Skimming-Aktionen ~150 Mal 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 einen Nettogewinn von 150 WBNB.

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 zuverlässige Preis-Orakel und eine solide Token-Burn-Logik vor der Bereitstellung sicherstellen.

Über BlockSec

BlockSec ist ein Anbieter von Full-Stack-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 renommierten 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 Audit-Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance