Wöchentliche Web3-Sicherheitsvorfall-Zusammenfassung | 2. – 8. März 2026

Während der letzten Woche (02.03.2026 - 08.03.2026) hat BlockSec sieben Angriffsereignisse erkannt und analysiert, mit geschätzten Gesamtschäden von ca. 3,25 Mio. $. Die folgende Tabelle fasst diese Ereignisse zusammen und detaillierte Analysen für jeden Fall sind in den folgenden Unterabschnitten aufgeführt.

1. BUBU2 Vorfall

Kurze Zusammenfassung

Am 1. März 2026 wurde der BUBU2-Token auf der BNB Chain ausgenutzt, was zu geschätzten Verlusten von ca. 19,7 T$ führte. Die Ursache war ein Fehler im Token-Design: Der Vertrag integriert einen zeitlich akkumulierenden deflationären Mechanismus, der Token direkt aus den Reserven des AMM-Paares während der Übertragung abzieht. Der Vertragseigentümer verkürzte vor dem Angriff das Auslöserintervall auf einen unzumässig kleinen Wert, was dazu führte, dass Hunderte von Burn-Runden in einem einzigen Aufruf angesammelt und ausgeführt wurden. Der Angreifer nutzte einen Flash-Loan, um diesen Mechanismus auszulösen, was zum Zusammenbruch der Reserven des Paares und zur Inflation des Token-Preises führte, und führte dann einen Reverse-Swap zum verzerrten Kurs für Gewinn durch.

Hintergrund

BUBU2 ist ein deflationäres ERC-20-Token-Protokoll, das auf der BNB Chain eingesetzt wird. Das Protokoll integriert eine periodische deflationäre Engine, die von burnAndMintSwitch gesteuert wird: Sobald sie vom Eigentümer über setBurnAndMintSwitch(true) aktiviert wird, löst jede nicht befreite Übertragung, die den _update()-Hook auslöst, _triggerDailyBurnAndMint() aus, der Token proportional zum BUBU2-Guthaben des Handelspaares basierend auf der Anzahl der seit dem letzten Auslöser verstrichenen TRIGGER_INTERVAL-Perioden verbrennt und die Reserven entsprechend synchronisiert.

Schwachstellenanalyse

Die Ursache ist ein Designfehler im BUBU2-Token-Vertrag (0x3fF3...ee52). Der Vertrag integriert einen periodischen deflationären Mechanismus in seinem _update()-Hook: Wenn _triggerDailyBurnAndMint() ausgelöst wird, berechnet es die Anzahl der seit der letzten Ausführung verstrichenen TRIGGER_INTERVAL-Perioden und verbrennt einen proportionalen Betrag von BUBU2 direkt aus dem Handelspaar ([0x7745...cd2f](https://bscscan.com/address/0x774547ea9d2a0cc79db3288f61e989f1b06bcd2f)), gefolgt von einem sync() zur Aktualisierung der Reserven. Entscheidend ist, dass der Eigentümer TRIGGER_INTERVAL ohne Zeitverzögerung oder Schutz vor Mindestgrenzen neu konfigurieren kann.

Vor dem Angriff rief der Eigentümer setBurnAndMintSwitch(true) und dann setTriggerInterval(120) auf, wodurch das Intervall von den standardmässigen 6 Stunden auf 120 Sekunden komprimiert wurde. Da lastTriggerTime noch mehrere Stunden in der Vergangenheit lag, berechnete der nächste Auslöser Hunderte von akkumulierten Runden, und der Burn-Betrag skalierte linear mit den Runden. Dies führte dazu, dass eine einzige Übertragung eine massive Menge BUBU2 aus dem Paar entzog, seine Reserven zusammenbrechen liess und den Token-Preis um etwa das 11-fache aufblähte.

Angriffsanalyse

Die folgende Analyse basiert auf den Transaktionen 0x1bc0...141c,0x191c...1ee4,0xd6e5...51a6.

• Schritt 1: Der Token-Eigentümer aktivierte zuerst den periodischen deflationären Mechanismus über setBurnAndMintSwitch(true) und verkürzte dann das Auslöserintervall von den standardmässigen 6 Stunden auf 120 Sekunden über setTriggerInterval(120). Der Angreifer borgte sich anschliessend 18 WBNB über einen Flash-Loan und tauschte sie gegen ca. 18.715.856 BUBU2 aus dem Pool.

  

  

• Schritt 2: Der Angreifer löste eine kleine Übertragung aus, die _triggerDailyBurnAndMint() auslöste. Der BUBU2-Guthaben des Pools fiel um ca. 1.025.988.664e18 Token und hinterliess nach Ausführung von sync() nur noch 6.493.352e18 BUBU2 in der Reserve, was den BUBU2-Preis um ca. das 200-fache aufblähte.

  

  

  

• Schritt 3: Der Angreifer verkaufte die in Schritt 1 erworbene BUBU2 zum aufgeblähten Preis zurück in den Pool und erhielt ca. 50 WBNB. Nach Rückzahlung des Flash-Loans betrug der Nettogewinn ca. 32 WBNB.

Schlussfolgerung

Die Ausnutzung von BUBU2 beruhte auf einem kritischen Designfehler im Token-Vertrag. Der Eigentümer konfigurierte ein unzumässig kleines TRIGGER_INTERVAL, das es der verstrichenen Zeit ermöglichte, sich zu Hunderten von Runden anzusammeln und die Reserven des Handelspaares in einem einzigen Aufruf zu entleeren, was zu einem heftigen Anstieg des BUBU2-Preises führte.

Um ähnliche Risiken in Zukunft zu reduzieren:

• Schützen Sie kritische Parameter wie TRIGGER_INTERVAL mit Grenzen oder Zeitverzögerungen.

• Begrenzen oder kappen Sie angesammelte Ausführungsrunden.

2. ACPRoute Vorfall

Kurze Zusammenfassung

Am 2. März 2026 wurde das ACPRoute-Protokoll auf Base ausgenutzt, was zu geschätzten Verlusten von ca. 58 T$ führte. Die Ursache war eine fehlerhafte Geschäftslogik im Payment-Manager-Vertrag: Der Job-Status wurde als Speicher-Kopie und nicht als Speicherreferenz geladen, sodass die kumulative Auszahlungsverfolgung niemals on-chain gespeichert wurde. Dies ermöglichte es dem Angreifer, einen Job zu erstellen, die automatische Auszahlung während der Phasenübergangs auszulösen und dann dieselben treuhänderisch verwalteten Gelder über eine erlaubnisfreie Claim-Funktion ein zweites Mal zu beanspruchen.

Hintergrund

ACP (Agent Commerce Protocol) ist ein modulares On-Chain-Handelsprotokoll, das für die Interaktion zwischen Kunden und Anbietern konzipiert ist. Es gliedert die Aktivität in drei Ebenen: Konten, Jobs und Memos. Jobs durchlaufen einen festen Lebenszyklus (REQUEST → NEGOTIATION → TRANSACTION → EVALUATION → COMPLETED), und Zahlungen werden während der TRANSACTION-Phase vom PaymentManager-Vertrag treuhänderisch verwaltet. Wenn ein Job COMPLETED erreicht, gibt das Protokoll die treuhänderisch verwalteten Gelder über die Funktion releasePayment() an den Anbieter frei. Um Doppelansprüche zu verhindern, verfolgt das Protokoll die kumulativen Auszahlungen pro Job anhand des Feldes amountClaimed in der Job-Struktur. Jeder Aufruf der Funktion releasePayment() soll den angeforderten Betrag mit amountClaimed vergleichen, um sicherzustellen, dass Gelder nur einmal freigegeben werden.

Schwachstellenanalyse

Die Ursache liegt in der Funktion releasePayment() des PaymentManager-Vertrags (0x56c3...0684), wo der Job-Status als Speicher-Kopie und nicht als Speicherreferenz geladen wird. Obwohl das Protokoll kumulative Auszahlungen über amountClaimed verfolgt, um Doppelansprüche zu verhindern, operiert die Inkrementierung job.amountClaimed += amount ausschliesslich auf einer transienten lokalen Kopie und wird nie in den On-Chain-Speicher zurückgeschrieben. Folglich beobachtet jede Ausführung der Funktion releasePayment() amountClaimed == 0, was es einem Angreifer ermöglicht, die Funktion claimBudget() aufzurufen und den Opfervertrag (0x307e...d6e8) ein zweites Mal zu leeren, nachdem der Phasenübergang bereits die Funktion releasePayment() automatisch ausgelöst hat.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xe94a...f9a0.

• Schritt 1: Der Angreifer borgte sich 97.000e6 USDC über einen Flash-Loan als Kapital für den nachfolgenden Angriff.

• Schritt 2: Innerhalb des Callbacks rief der Angreifer die Funktion createJob() auf dem ACPRouter auf und setzte gleichzeitig einen frischen Anbietervertrag (0x1ee502dd...) zur Entgegennahme der Gelder ein.

• Schritt 3: Der Angreifer rief wiederholt die Funktion createMemo() auf und rief die eigene exec()-Funktion des Anbietervertrags auf, um die Job-Phase voranzutreiben, bis der Phasenübergang COMPLETED ausgelöst wurde, was automatisch die Funktion releasePayment() aufrief und den vollen Betrag an den Anbietervertrag freigab. Zu diesem Zeitpunkt hätte amountClaimed aktualisiert werden sollen, aber sein Wert im Speicher blieb 0.

• Schritt 4: Der Angreifer rief die Funktion claimBudget() auf und beanspruchte erfolgreich die treuhänderisch verwalteten 97.000e6 USDC ein zweites Mal als Gewinn.

Schlussfolgerung

Dieser Vorfall wurde durch einen Fehler bei der Statuspersistenz verursacht, der es ermöglichte, treuhänderisch verwaltete Gelder zweimal im selben Job-Lebenszyklus zu beanspruchen.

Um ähnliche Risiken in Zukunft zu reduzieren:

• Stellen Sie sicher, dass kritische Zustandsvariablen (z. B. amountClaimed) mithilfe von Speicherreferenzen aktualisiert werden.

• Beschränken Sie sensible Auszahlungsfunktionen oder erzwingen Sie eine strenge Validierung des Status vor der Ausführung.

3. sDOLA Llamalend Market Vorfall

Kurze Zusammenfassung

Am 2. März 2026 wurde der sDOLA Llamalend Market auf Ethereum ausgenutzt, was zu geschätzten Verlusten von ca. 239 T$ führte. Die Ursache ist eine Preismanipulation. Insbesondere ist sDOLA ein ERC4626-Token, dessen Preis über donate() manipuliert werden kann. Llamalend ist ein AMM-basierter Kreditmarkt, und aufgrund des LLAMMA-Mechanismus können Benutzer auch dann liquidiert werden, wenn der Kollateralpreis steigt. Daher kann ein Angreifer donate() verwenden, um den sDOLA-Preis in die Höhe zu treiben, die Positionsgesundheit von Benutzern unter Null zu drücken und diese Benutzer dann zur Gewinnmitnahme zu liquidieren.

Hintergrund

LLAMMA (Lending-Liquidating AMM Algorithm) ist ein AMM-basierter Kreditmarkt, der von Curve [1] verwendet wird. Im Gegensatz zu herkömmlichen Kreditprotokollen legt LLAMMA die Benutzerkollateral in Preisbändern innerhalb des AMM ab. Wenn sich der Oracle-Preis $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ bewegt, wird das Kollateral progressiv zwischen dem Kollateral-Token und crvUSD durch Arbitrage-gesteuerte Swaps über Bänder (Soft-Liquidation) umgewandelt und positionen allmählich entschärft, anstatt abrupte Liquidationen auszulösen.

Wenn die Soft-Liquidation eine Position nicht schnell genug entschärfen kann, greift die Hard-Liquidation [2], die ausgelöst wird, wenn die Gesundheit einer Position unter Null fällt. Die Gesundheit wird über get_x_down() [3] berechnet, die das Kollateral nicht einfach zum Marktpreis bewertet. Stattdessen simuliert sie eine Hin- und Rückumwandlung der Benutzerposition, um ihren wiederherstellbaren Wert zu bewerten. Diese Hin- und Rückfahrt verwendet zwei verschiedene Preisanker: einen, der aus dem aktuellen $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ abgeleitet wird (bewegt sich mit dem Live-Oracle), und einen anderen, der aus den Bandgrenzen des Benutzers abgeleitet wird (fest, wenn die Position erstellt wurde).

Schwachstellenanalyse

Die fehlerhaften Verträge umfassen den crvUSD Controller (0xad44...fb86) und den LLAMMA AMM (0x0079...a1f7). Der Opfervertrag ist der sDOLA Llamalend Market (0x2b08...4fbe).

sDOLA ist ein ERC4626-Vault-Token, dessen Anteilspreis durch das Verhältnis von Gesamtvermögen zu Gesamteinheiten bestimmt wird. Da jeder donate() aufrufen kann, um Vermögenswerte zum Vault hinzuzufügen, kann der Anteilspreis innerhalb einer einzigen Transaktion aufgebläht werden. Dies ist das manipulierbare Orakel, auf dem die Gesundheitsfunktion von LLAMMA basiert.

Wie im Hintergrund beschrieben, berechnet get_x_down() die Gesundheit durch Simulation einer Hin- und Rückumwandlung über zwei Preisanker: einen, der aus $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ abgeleitet wird (dynamisch, bewegt sich mit dem Live-Oracle), und einen anderen, der aus den Bandgrenzen des Benutzers abgeleitet wird (statisch, fest bei der Erstellung der Position). Das Protokoll wendet beim Lesen von $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ keine Verzögerung oder Plausibilitätsprüfung an. Wenn daher der Oracle-Preis aufgebläht ist, steigt der dynamische Anker, aber der statische Anker bleibt gleich. Tatsächlich wandelt die Simulation crvUSD zum aufgeblähten Oracle-Preis in Kollateral um und wandelt es zum ursprünglichen Bandpreis zurück, sodass der bewertete wiederherstellbare Wert schrumpft, wenn die Lücke zwischen den beiden Ankern wächst. Dies führt zu einer Gesundheit unter Null, obwohl der Kollateralpreis gestiegen ist.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xb935...d8a4.

• Schritt 1: LLAMMA-Zustand manipulieren (grosse Swaps), um active_band zu verschieben und viele Benutzer in eine reine x-Position zu drängen (nur crvUSD).

  

• Schritt 2: Manipulieren Sie den sDOLA-Preis durch Spenden und verwenden Sie dann einen Swap mit Nullbetrag (swap(0)), um den manipulierten Preis in den AMM-Pool zu schreiben.

  

  

• Schritt 3: Auslösen der Neuberechnung der Gesundheit über users_to_liquidate() -> _health() -> get_x_down().

• Schritt 4: Da get_x_down() den wiederherstellbaren Wert anhand zweier divergierender Preisanker berechnet (dem nun aufgeblähten dynamischen Anker gegenüber dem unveränderten statischen Anker), führt die Hin- und Rückumwandlung zu einem Abschlag auf den effektiven Wert, und viele Positionen fallen unter Null Gesundheit.

• Schritt 5: Stapelweise Hard-Liquidation dieser Benutzer zur Gewinnmitnahme.

Zusätzlich enthält die Spur zwei create_loan()-Aufrufe. Der erste Kredit wurde hauptsächlich zur Finanzierung von crvUSD-Swap-Operationen mit hoher Stückzahl verwendet. Der zweite Kredit wurde zur Beschaffung von crvUSD zur Rückzahlung der Schulden der ersten Position und zur Wiederverwendung von Kapital verwendet. Diese beiden Kredite sind hauptsächlich Finanzierungs-/Abwicklungsbeine und stellen keine Kernschritte des Exploits dar.

Schlussfolgerung

Der Vorfall ist ein Angriff auf die Manipulation des Kollateralpreises. Der Angreifer manipulierte den sDOLA-Preis innerhalb einer Transaktion und drängte Benutzer aufgrund des Pfad-basierten Gesundheitsmechanismus von LLAMMA in Liquidationsbedingungen. Eine wichtige Konsequenz ist, dass Positionen auch dann liquidierbar werden können, wenn der Kollateralpreis steigt. Empfohlene Härtungsrichtungen:

• Verwenden Sie verzögerte oder TWAP-Kollateralpreise für die Liquidation.

Referenzen

• [1] Curve crvUSD LLAMMA Docs: [https://dev.curve.finance/crvUSD/amm/#bands](https://dev.curve.finance/crvUSD/amm/#bands)

• [2] Curve LLAMMA Liquidationserklärung: [https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation](https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation)

• [3] Curve Stablecoin Whitepaper: [https://docs.curve.finance/pdf/whitepapers/whitepaper\_curve\_stablecoin.pdf](https://docs.curve.finance/pdf/whitepapers/whitepaper_curve_stablecoin.pdf)

4. Der V4 Router von z0r0z Vorfall

Kurze Zusammenfassung

Am 3. März 2026 wurde der V4 Router von z0r0z auf Ethereum ausgenutzt, was zu geschätzten Verlusten von ca. 42 T$ führte. Der Angriff wurde durch eine fehlerhafte Autorisierungslogik in swap() verursacht, bei der sich der Router auf einen festen Calldata-Offset in Inline-Assembly verliess, um zu überprüfen, ob der Zahler mit msg.sender übereinstimmte. Da die ABI-Kodierung für dynamische Typen kein festes Layout garantiert, konnte der Angreifer nicht standardmässige, aber gültige Calldata erstellen, die die Prüfung umgingen, einen zuvor genehmigten Opfer als Zahler nachahmten und den Swap-Output an eine vom Angreifer kontrollierte Adresse umleiteten.

Hintergrund

Das Protokoll erbt vom Uniswap v4 Router und überschreibt einige seiner Methoden. Im Wesentlichen fungiert es als Swap-Router, der es Benutzern ermöglicht, direkt mit dem entsprechenden Pool zu interagieren, anstatt den Router als einheitlichen Einstiegspunkt zu verwenden.

Schwachstellenanalyse

Die Ursache ist eine fehlerhafte Geschäftslogik im V4 Router-Vertrag (0x0000...ce97). Der Opfervertrag ist 0x65a8...7675. Die Funktion swap() akzeptiert zwei Parameter: data (bytes) und deadline (uint256). Innerhalb der Funktion verwendet eine Autorisierungsprüfung einen Inline-Assembly-Block, um calldataload(164) mit caller() zu vergleichen, um sicherzustellen, dass der in data kodierte Zahler mit msg.sender übereinstimmt. Das Protokoll geht davon aus, dass der Byte-Offset immer 0x40 ist, wodurch der Zahler an Byte-Position 164 (0xa4) platziert wird.

Die ABI-Kodierung garantiert jedoch dieses Layout nicht: Dynamische Parameter speichern nur einen Offset im Kopf, und dieser Offset kann rechtmässig auf eine beliebige ausgerichtete Stelle im Calldata zeigen. Durch die Erstellung einer gültigen, aber nicht standardmässigen Kodierung, bei der der Byte-Offset auf 0xc0 verschoben wird, kann ein Angreifer beliebige Auffüllungen zwischen Kopf und tatsächlichem Schwanz einfügen. Der Angreifer platziert seine eigene Adresse an Byte-Position 164, um die Assembly-Prüfung zu bestehen, während die tatsächliche Byte-Nutzlast am verlagerten Schwanz die Adresse des Opfers als Zahler kodiert. Durch die Auswahl eines Opfers, das den Router zuvor genehmigt hat, und die Festlegung des Empfängers auf seine eigene Adresse kann der Angreifer den Swap-Output umleiten und Gelder stehlen.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xfe34...466a.

• Schritt 1: Wählen Sie einen Benutzer aus, der den Router zuvor als Ziel genehmigt hat.

• Schritt 2: Erstellen Sie das Calldata, um die Autorisierungsprüfung zu umgehen.

• Schritt 3: Geben Sie das Opfer als Zahler in den Daten an, setzen Sie die eigene Adresse des Angreifers als Token-Empfänger und stehlen Sie dann die Vermögenswerte des Opfers.

Schlussfolgerung

Dieser Vorfall wurde durch die Abhängigkeit von einem fest kodierten Calldata-Offset für die Autorisierung im Swap-Pfad verursacht. Da die ABI-Kodierung für dynamische Typen kein festes Layout garantiert, umging der Angreifer die Prüfung mit nicht standardmässigen, aber gültigen Calldata, gab sich als genehmigtes Opfer als Zahler aus und leitete den Swap-Output um.

Um ähnliche Risiken in Zukunft zu reduzieren:

• Verlassen Sie sich niemals auf fest kodierte Calldata-Offsets für dynamisch ABI-kodierte Parameter.

• Dekodieren und validieren Sie strukturierte Eingaben mithilfe der kanonischen ABI-Dekodierung anstelle von manuellen Positionsannahmen.

• Stellen Sie sicher, dass der tatsächliche Zahler, Empfänger und Token-Fluss konsistent gegen den beabsichtigten Aufrufer und den Ausführungskontext validiert werden.

5. Der BitcoinReserveOffering Vertrag Vorfall

Kurze Zusammenfassung

Am 5. März 2026 wurde der BitcoinReserveOffering-Vertrag auf Ethereum ausgenutzt, was zu einem Verlust von ca. 2,7 Millionen Dollar führte. Die Ursache war eine fehlerhafte Geschäftslogik: Bei der Verarbeitung einer vollständigen ERC-3525 SFT-Einzahlung wurde die Minting-Logik zweimal in einem einzigen Aufruf ausgeführt, einmal während eines Transfer-Callbacks und einmal im Hauptfluss. Der Angreifer nutzte dieses doppelte Minting-Verhalten durch wiederholte Burn-and-Mint-Zyklen aus, blähte sein BRO-Token-Guthaben exponentiell auf und löste dann die überschüssigen Token gegen SolvBTC ein, um den Gewinn zu realisieren.

Hintergrund

BitcoinReserveOffering ist ein Wrapper-Vertrag, der ERC-3525 SFT-Positionen in übertragbare ERC-20 BRO-Token umwandelt. Benutzer können die Funktion mint() aufrufen, um berechtigte SFTs einzuzahlen, und der Vertrag prägt eine entsprechende Menge BRO basierend auf einem konfigurierten Umtauschkurs. Wenn ein Benutzer nur einen Teil des Wertes eines SFT einzahlt, überträgt der Vertrag den angegebenen Betrag in seine intern gehaltene Position und prägt dann den entsprechenden Wert von BRO. Wenn ein Benutzer einen gesamten SFT einzahlt, überträgt der Vertrag den gesamten Token in den Wrapper-Vertrag und prägt BRO basierend auf dem Gesamtwert des SFT. Benutzer können später die Funktion burn() aufrufen, um BRO zurück in seine entsprechende ERC-3525 SFT-Position einzulösen und den gewickelten ERC-20-Wert zurück in eine SFT-Position umzuwandeln.

Schwachstellenanalyse

Die Ursache liegt darin, dass der BitcoinReserveOffering-Vertrag (0x15f7...cfcf) die Minting-Logik zweimal ausführt, wenn er eine vollständige ERC-3525 SFT-Einzahlung in der Funktion mint() verarbeitet. Insbesondere im Zweig amount_ == sftBalance ruft mint() ERC3525TransferHelper.doSafeTransferIn() auf, um die gesamte SFT sicher in den Vertrag zu übertragen, was den Callback onERC721Received() auslöst. Innerhalb dieses Callbacks berechnet der Vertrag bereits den Wert des SFT und prägt BRO an den Sender. Nachdem der Callback zurückgekehrt ist, fährt mint() mit der Ausführung fort, berechnet den Wert mit demselben amount_ neu und führt eine zweite _mint(msg.sender, value)-Operation durch. Dieses doppelte Minting-Verhalten ermöglicht es einem Angreifer, sein BRO-Guthaben durch eine Burn-Mint-Schleife wiederholt aufzublähen.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x44e6...958d.

• Schritt 1: Der Angreifer überwies 135e18 BRO-Token in den Angriffskontrakt als Startkapital.

• Schritt 2: Der Angreifer führte die folgende Schleife aus:

1. Wickeln Sie 135e18 BRO-Token in einen SFT-Token.

2. Rufen Sie mint() mit dem vollen SFT-Wert auf, was den onERC721Received()-Callback auslöst und 135e18 BRO-Token prägt; die äussere mint() fährt dann fort und ruft _mint() erneut auf, was zu einem doppelten Mint von insgesamt 270e18 BRO-Token führt.

3. Wickeln Sie die 270e18 BRO-Token zurück in einen SFT-Token.

• Schritt 3: Nach 22-facher Wiederholung von Schritt 2 sammelte der Angreifer ca. 567.758.816e18 BRO-Token an, die schliesslich gegen 38e18 SolvBTC als Gewinn eingetauscht wurden.

Schlussfolgerung

Dieser Vorfall wurde durch doppeltes Minting bei vollständigen SFT-Einzahlungen verursacht, was es dem Angreifer ermöglichte, sein BRO-Guthaben durch wiederholte Burn-Mint-Zyklen exponentiell aufzublähen und die überschüssigen Token gegen SolvBTC einzutauschen.

Um ähnliche Risiken in Zukunft zu reduzieren:

• Stellen Sie sicher, dass die Vermögensbuchhaltung nur einmal pro Einzahlungsoperation erfolgt.

• Fügen Sie Invarianzprüfungen hinzu, um zu verhindern, dass Mint-Beträge den zugrunde liegenden eingezahlten Wert überschreiten.

6. MoltEVM Vorfall

Kurze Zusammenfassung

Am 7. März 2026 wurde das MoltEVM-Protokoll auf Base ausgenutzt, was zu geschätzten Verlusten von ca. 127 T$ führte. Die Ursache war eine fehlerhafte Zugriffskontrolllogik im Token-Vertrag: Die privilegierte Minting-Funktion wurde durch einen Modifier geschützt, der nur prüfte, ob der Aufrufer ein Vertrag mit einer bestimmten Schnittstelle war, was leicht gefälscht werden konnte. Der Angreifer setzte einen bösartigen Vertrag ein, um die Prüfung zu umgehen, prägte eine grosse Menge Token und verkaufte sie dann über den Liquiditätspool mit Gewinn.

Hintergrund

MoltEVM ist ein experimentelles ERC-20-Token-Protokoll, das auf Base eingesetzt wird und ein sich selbst replizierendes Token-Modell erforscht. Das System erlaubt es einem Token, neue Kind-Token ("Moltling"-Token) zu spawnen, sobald bestimmte Reserve-Schwellenwerte erreicht sind. Wenn eine neue Moltling erstellt wird, wird eine anfängliche Token-Menge über die Funktion mintFromSpawner() verteilt, und die Liquidität wird automatisch bereitgestellt, um einen Handelsmarkt für das neue Token zu etablieren. Dieses Design ermöglicht es dem Protokoll, seine Token-Abstammung autonom zu erweitern, wobei jede Generation von Token in der Lage ist, weitere Nachkommen zu spawnen.

Schwachstellenanalyse

Die Schwachstelle liegt in der Zugriffskontrolllogik der Funktionen mintFromSpawner() und setExemptFromSpawner() im MoltEVM-Vertrag (0x225d...501f). Beide Funktionen stützen sich auf den Modifier onlySpawnerToken, der dazu gedacht war, Aufrufe auf legitime von Protokoll gespawnte Moltling-Verträge zu beschränken.

Der Modifier führt jedoch nur zwei schwache Prüfungen durch: Er überprüft, ob msg.sender ein Vertrag ist und ob das Aufrufen von initialized() auf dem Aufrufer true zurückgibt. Da diese Bedingungen von jedem beliebigen Vertrag, der dieselbe Schnittstelle implementiert, leicht erfüllt werden können, bietet die Prüfung keine sinnvolle Authentifizierung legitimer Spawner-Token.

Infolgedessen kann ein Angreifer einen minimalen Vertrag einsetzen, der einfach eine Funktion initialized() implementiert, die true zurückgibt. Nach der Bereitstellung kann der bösartige Vertrag mintFromSpawner() frei aufrufen, um beliebige Token-Mengen zu prägen, und kann auch setExemptFromSpawner() aufrufen, um vom Angreifer kontrollierte Adressen auf die Whitelist zu setzen. Dies gibt dem Angreifer effektiv die volle Kontrolle über den Minting-Pfad und ermöglicht es, neu geprägte Token zur Gewinnmitnahme in Liquiditätspools zu verkaufen.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x10b7...e03d.

• Schritt 1: Der Angreifer setzte einen minimalen Vertrag ein, der eine einzelne Funktion initialized() implementierte, die fest auf true gesetzt war und damit die Prüfung des onlySpawnerToken-Modifiers bestand.

• Schritt 2: Der Vertrag des Angreifers rief die Funktion setExemptFromSpawner() auf, die durch denselben anfälligen onlySpawnerToken-Modifier geschützt war, um die Adresse des Angreifers auf die Whitelist für Steuerbefreiungen zu setzen. Dies stellte sicher, dass nachfolgende gross angelegte Token-Verkäufe keine Verkaufsteuern oder die interne Swap-Logik auslösten und somit den Gewinn maximierten.

  

• Schritt 3: Der Angreifer wiederholte die Funktionssequenz setExemptFromSpawner() + mintFromSpawner() zuerst gegen mEVM, gefolgt von mehreren Moltling-Kind-Token einschliesslich CSPAWN, CCUTTL, LWORM und NHYDRA, prägte dabei Token in grossen Mengen über alle Ziele hinweg und verkaufte sie in ihre jeweiligen Liquiditätspools, um Gewinne zu erzielen.

  

Schlussfolgerung

Dieser Vorfall wurde durch eine unzureichende Zugriffskontrolle bei privilegierten Minting- und Konfigurationsfunktionen verursacht, die es einem Angreifer ermöglichte, sich als legitimer Spawner auszugeben und beliebige Token zur Gewinnmitnahme zu prägen.

Um ähnliche Risiken in Zukunft zu reduzieren:

• Erzwingen Sie eine strenge Zugriffskontrolle für privilegierte Minting- oder Konfigurationsfunktionen.

• Vermeiden Sie die Abhängigkeit von leicht zu fälschenden Vertragsprüfungen für die Autorisierung.

• Validieren Sie die Aufruferidentität durch explizite Whitelists oder vertrauenswürdige Vertragskataloge.

7. LEDS Vorfall

Kurze Zusammenfassung

Am 8. März 2026 wurde der LEDS-Token auf der BNB Chain ausgenutzt, was zu geschätzten Verlusten von ca. 64 T$ führte. Die Ursache war eine fehlerhafte Geschäftslogik: Der Token-Vertrag exponiert mehrere unabhängige deflationäre Mechanismen, von denen jeder Token direkt aus dem Liquiditätspaar brennen kann, und keiner ist durch Zugriffskontrolle oder Abkühlzeit geschützt. Der Angreifer verkettete alle Burn-Pfade innerhalb einer einzigen Transaktion, liess das LEDS-Reserve des Paares gegen Null laufen, während das WBNB-Reserve intakt blieb, und führte dann Reverse-Swaps durch, um den unausgewogenen Pool zur Gewinnmitnahme zu leeren.

Hintergrund

LEDS ist ein deflationärer Token auf der BNB Chain mit integrierten Fee-on-Transfer-Mechanismen. Sein _transfer() implementiert mehrere Burn-Mechanismen, die dazu bestimmt sind, das Angebot schrittweise zu reduzieren und den Preis zu unterstützen: eine tägliche Burn-Funktion triggerDailyBurnAndMint(), eine verzögerte Burn durch stor_18-Akkumulation bei Verkäufen und ein spezieller Zweig, der Token an 0xdead brennt, wenn der Swap-Empfänger auf den PancakeSwap Router gesetzt ist. Der Token verfügt auch über eine Funktion deposit(), bei der Benutzer BNB senden, um LEDS zu prägen und Liquidität bereitzustellen, und LP-Prämien verdienen, die über einen Distributor beansprucht werden können.

Schwachstellenanalyse

Die Ursache ist eine fehlerhafte Geschäftslogik im LEDS-Token-Vertrag (0xfb62...a48f). Der Opfer ist das LEDS/WBNB-Paar (0xd109...6f3f). Der Token implementiert mehrere deflationäre Mechanismen: triggerDailyBurnAndMint(), der Sell-Pfad stor_18-Akkumulation und ein to == router-Burn-Zweig in _transfer(). Jeder dieser Mechanismen entfernt unabhängig LEDS aus dem Liquiditätspaar und ruft sync() zur Aktualisierung der Reserven auf.

Während diese Mechanismen einzeln als schrittweise deflationäre Werkzeuge dienen, können sie innerhalb einer einzigen Transaktion verkettet werden, um ihre Auswirkungen zu verstärken. Darüber hinaus erlaubt die öffentliche Funktion 0x17a06174(), dass jeder das gesamte angesammelte stor_18-Guthaben nach Belieben leeren kann, ohne Zugriffskontrolle oder Ratenbegrenzung. Durch die sequentielle Stapelung dieser Burn-Pfade kann ein Angreifer die LEDS-Reserve des Paares auf fast Null reduzieren, während die WBNB-Reserve unangetastet bleibt, wodurch eine extreme Preisverwerfung entsteht, die durch Reverse-Swaps ausgenutzt werden kann.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x2608...79da.

• Schritt 1: Der Angreifer beschaffte eine grosse Menge WBNB über Flash-Loans (Moolah + Venus-Besicherungs-Darlehen + Aave + PancakeSwap V4).

• Schritt 2: Mehrere deposit()-Aufrufe durchgeführt, um LP-Prämien zu sammeln, dann triggerDailyBurnAndMint() ausgelöst, was einen Teil von LEDS aus dem Paar verbrannte und Prämien an den Distributor schickte, wodurch die LEDS-Reserve im Pool reduziert wurde.

  

• Schritt 3: Funktion 0xde1b1942() aufgerufen, um die angesammelten LEDS-Token-Prämien zu beanspruchen.

  

• Schritt 4: Die beanspruchten LEDS gegen WBNB verkauft. Da das LEDS-Guthaben des Paares nach dem Verkauf die Schwelle überschritt, wurde der übertragene Betrag in stor_18 (ausstehender Burn) angesammelt.

  

• Schritt 5: LEDS über PancakeSwap mit dem auf den Router gesetzten Empfänger gekauft. Dies löste einen speziellen Zweig in _transfer() aus, der die gekauften LEDS direkt aus dem Paar an 0xdead verbrannte und somit die LEDS-Reserve des Pools weiter reduzierte.

  

• Schritt 6: Funktion 0x17a06174() aufgerufen, die den gesamten stor_18-Betrag (in Schritt 4 angesammelt) aus dem Paar an 0xdead verbrannte und sync() aufrief, wodurch die LEDS-Reserve des Pools auf nur 2 Wei zusammenbrach.

  

• Schritt 7: Reverse-Swaps durchgeführt, um WBNB aus dem nun stark unausgewogenen Pool zu ziehen, alle Flash-Loans zurückzuzahlen und 104,56 WBNB (64.000 $) Gewinn zu erzielen.

Schlussfolgerung

Dieser Vorfall wurde durch mehrere ungeschützte deflationäre Mechanismen verursacht, die in einer einzigen Transaktion verkettet werden können, um die Reserven des Liquiditätspaares katastrophal zu erschöpfen.

Für jeden Token-Vertrag, der deflationäre oder automatische Burn-Mechanismen implementiert, sollten Entwickler:

• Niemals Funktionen zum Brennen aus einem Paar ohne angemessene Zugriffskontrolle, Ratenbegrenzung oder Durchsetzungszeiträume offenlegen.

• Vermeiden Sie, dass mehrere unabhängige Burn-Mechanismen nacheinander innerhalb einer einzigen Transaktion ausgelöst werden können.

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits (einschliesslich Smart Contracts, Blockchains 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 prestigeträchtigen Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Milliarden von Kryptowährungen gesichert.

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

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

• 🔗 BlockSec Audit Service : Anfrage stellen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance