Wöchentliches Web3-Sicherheitsvorfall-Roundup | 2. – 8. März 2026

In der vergangenen 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 nachstehende Tabelle fasst diese Ereignisse zusammen, und detaillierte Analysen für jeden Fall sind in den folgenden Unterabschnitten aufgeführt.

*Der BUBU2-Vorfall wurde im Bericht der letzten Woche übersehen und ist hier zur Vollständigkeit enthalten.

1. BUBU2 Vorfall

Kurze Zusammenfassung

Am 1. März 2026 wurde der Token BUBU2 auf der BNB Chain ausgenutzt, was zu Verlusten von rund 19,7 Tausend Dollar führte. Die Hauptursache war ein Fehler im Token-Design: Der Vertrag integriert einen zeitlich akkumulierenden deflationären Mechanismus, der Token direkt aus den Reserven des AMM-Paares bei Übertragungen abzieht. Der Contract-Besitzer verkürzte das Auslöserintervall vor dem Angriff auf einen unzumutbar 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 die Reserven des Paares kollabieren ließ und den Tokenpreis aufblähte, um dann zu einem verzerrten Kurs rückwärts zu tauschen, um Profit zu erzielen.

Hintergrund

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

Schwachstellenanalyse

Die Hauptursache ist ein Designfehler im BUBU2-Token-Vertrag (0x3fF3...ee52). Der Vertrag integriert einen periodischen deflationären Mechanismus in seinen Hook _update(): Wenn er ausgelöst wird, berechnet _triggerDailyBurnAndMint() 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 Besitzer TRIGGER_INTERVAL ohne Zeitverzögerung oder Mindestgrenzenschutz neu konfigurieren kann.

Vor dem Angriff rief der Besitzer setBurnAndMintSwitch(true) und dann setTriggerInterval(120) auf, wodurch das Intervall von den standardmäßigen 6 Stunden auf 120 Sekunden verkürzt wurde. Da lastTriggerTime immer noch mehrere Stunden in der Vergangenheit verankert war, berechnete der nächste Trigger Hunderte von angesammelten Runden, und der Burn-Betrag skalierte linear mit den Runden. Dies führte dazu, dass eine einzelne Übertragung eine massive Menge BUBU2 aus dem Paar abzog, die Reserven kollabieren ließ und den Tokenpreis um etwa das 11-fache aufblähte.

Angriffsanalyse

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

• Schritt 1: Der Token-Besitzer aktivierte zunächst den periodischen deflationären Mechanismus über setBurnAndMintSwitch(true) und verkürzte dann das Auslöserintervall von den standardmäßigen 6 Stunden auf 120 Sekunden über setTriggerInterval(120). Der Angreifer lieh sich anschließend 18 WBNB über einen Flash-Loan und tauschte diese gegen etwa 18.715.856 BUBU2 aus dem Pool.

  

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

  

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

Schlussfolgerung

Der Exploit von BUBU2 resultierte aus einem kritischen Designfehler im Token-Vertrag. Der Besitzer konfigurierte ein unzumutbar 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 leeren, was zu einem heftigen Anstieg des BUBU2-Preises führte.

Zur Reduzierung ähnlicher Risiken in der Zukunft:

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

• Begrenzen oder deckeln Sie angesammelte Ausführungsrunden.

2. ACPRoute Vorfall

Kurze Zusammenfassung

Am 2. März 2026 wurde das ACPRoute-Protokoll auf Base ausgenutzt, was zu Verlusten von rund 58 Tausend Dollar führte. Die Hauptursache war eine fehlerhafte Geschäftslogik im Zahlungsmanagervertrag: Der Job-Status wurde als Speicher kopie und nicht als Speicherreferenz geladen, sodass die kumulative Auszahlungsverfolgung nie auf der Kette gespeichert wurde. Dies ermöglichte es dem Angreifer, einen Job zu erstellen, die automatische Zahlungsfreigabe während des 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 für Interaktionen zwischen Kunden und Anbietern. Es strukturiert Aktivitäten 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 doppelte Ansprüche zu verhindern, verfolgt das Protokoll die kumulativen Auszahlungen pro Job mithilfe 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 Hauptursache liegt in der Funktion releasePayment() des PaymentManager-Vertrags (0x56c3...0684), in der der Job-Status als Speicher kopie anstelle einer Speicherreferenz geladen wird. Obwohl das Protokoll kumulative Auszahlungen über amountClaimed verfolgt, um doppelte Ansprüche zu verhindern, operiert die Inkrementierung job.amountClaimed += amount ausschließlich auf einer transienten lokalen Kopie und wird niemals 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 lieh 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, während er einen neuen Anbietervertrag (0x1ee502dd...) bereitstellte, um die Gelder zu erhalten.

• Schritt 3: Der Angreifer rief wiederholt die Funktion createMemo() auf und führte exec() des eigenen Anbietervertrags aus, um die Job-Phase voranzutreiben, bis der Phasenübergang COMPLETED ausgelöst wurde, was automatisch die Funktion releasePayment() aufrief und den vollen Saldo 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 Speicherung des Zustands verursacht, der es ermöglichte, treuhänderisch verwaltete Gelder innerhalb desselben Job-Lebenszyklus zweimal zu beanspruchen.

Zur Reduzierung ähnlicher Risiken in der Zukunft:

• 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 Zustands 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 Verlusten von rund 239 Tausend Dollar führte. Die Hauptursache 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 Preis der Sicherheiten steigt. Daher kann ein Angreifer donate() verwenden, um den sDOLA-Preis zu erhöhen, die Positionsgesundheit von Benutzern unter Null zu treiben und dann diese Benutzer profitabel zu liquidieren.

Hintergrund

LLAMMA (Lending-Liquidating AMM Algorithm) ist ein AMM-basierter Kreditmarkt, der von Curve [1] verwendet wird. Im Gegensatz zu traditionellen Kreditprotokollen platziert LLAMMA die Sicherheiten der Benutzer innerhalb des AMM in Preisbändern. Wenn sich der Oracle-Preis $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ bewegt, werden Sicherheiten fortschreitend zwischen dem Sicherheiten-Token und crvUSD durch arbitrierungsgetriebene Swaps über Bänder (Soft-Liquidation) umgewandelt, wobei Positionen allmählich entriskert werden, anstatt abrupte Liquidationen auszulösen.

Wenn die Soft-Liquidation eine Position nicht schnell genug entriskern 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 die Sicherheit nicht einfach zum Marktpreis bewertet. Stattdessen simuliert sie eine Hin- und Rückkonvertierung der Benutzerposition, um ihren wiederherstellbaren Wert zu bewerten. Diese Hin- und Rückfahrt verwendet zwei verschiedene Preisanker: einen, der sich aus dem aktuellen $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ ergibt (bewegt sich mit dem Live-Oracle), und einen, der sich aus den Bandgrenzen des Benutzers ergibt (fest, als 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-Tresortoken, dessen Anteilspreis durch das Verhältnis von Gesamtvermögen zu Gesamtanteil bestimmt wird. Da jeder donate() aufrufen kann, um Vermögenswerte zum Tresor 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ückkonvertierung über zwei Preisanker: einen, der sich aus $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ ergibt (dynamisch, bewegt sich mit dem Live-Oracle), und einen, der sich aus den Bandgrenzen des Benutzers ergibt (statisch, festgelegt bei Erstellung der Position). Das Protokoll wendet keine Verzögerung oder Integritätsprüfung beim Lesen von $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ an. Wenn der Orakelpreis aufgebläht ist, steigt der dynamische Anker, der statische Anker bleibt jedoch unverändert. Tatsächlich konvertiert die Simulation crvUSD zu Sicherheiten zum aufgeblähten Orakelpreis und konvertiert zurück zum ursprünglichen Bandpreis, sodass der bewertete wiederherstellbare Wert schrumpft, wenn sich die Lücke zwischen den beiden Ankern vergrößert. Dies treibt die Gesundheit unter Null, obwohl der Preis der Sicherheiten gestiegen ist.

Angriffsanalyse

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

• Schritt 1: Manipulieren des LLAMMA-Zustands (große Swaps), um active_band zu verschieben und viele Benutzer in eine reine x-Position zu drängen (nur crvUSD).

  

• Schritt 2: Manipulieren des sDOLA-Preises durch Spenden, dann Verwendung eines Null-Betrag-Swaps (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 über zwei divergierende Preisanker berechnet (den dynamischen Anker, jetzt aufgebläht, gegenüber dem statischen Anker, unverändert), führt die Hin- und Rückkonvertierung zu einem Abschlag auf den effektiven Wert, und viele Positionen rutschen unter Null Gesundheit.

• Schritt 5: Stapelweises hartes Liquidieren dieser Benutzer zur Gewinnerzielung.

Zusätzlich enthält die Spur zwei Aufrufe von create_loan(). Der erste Kredit wurde hauptsächlich zur Finanzierung von crvUSD-Swap-Operationen in großem Umfang verwendet. Der zweite Kredit wurde verwendet, um crvUSD zu erhalten, um die Schulden der ersten Position zurückzuzahlen und Kapital zu recyceln. Diese beiden Kredite sind größtenteils Finanzierungs-/Abrechnungsbeine und keine Kern-Exploit-Schritte.

Schlussfolgerung

Der Vorfall ist ein Angriff zur Manipulation des Kollateralpreises. Der Angreifer manipulierte den sDOLA-Preis innerhalb einer Transaktion und trieb aufgrund des pfadbasierten Gesundheitsmechanismus von LLAMMA Benutzer 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 Dokumentation: [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 Verlusten von rund 42 Tausend Dollar führte. Der Angriff wurde durch eine fehlerhafte Autorisierungslogik in swap() verursacht, bei der der Router auf einen festen Calldata-Offset in Inline-Assembly angewiesen war, 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äßige, aber gültige Calldata erstellen, die die Prüfung umgingen, einen zuvor genehmigten Geschädigten als Zahler impersonierten 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, nicht direkt mit dem entsprechenden Pool zu interagieren, sondern stattdessen den Router als einheitlichen Einstiegspunkt zu verwenden.

Schwachstellenanalyse

Die Hauptursache 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 und der Zahler sich an Byte-Position 164 (0xa4) befindet.

Die ABI-Kodierung garantiert jedoch nicht dieses Layout: Dynamische Parameter speichern nur einen Offset im Kopf, und dieser Offset kann rechtmäßig auf jede ausgerichtete Position in den Calldata verweisen. Durch die Erstellung einer gültigen, aber nicht standardmäßigen Kodierung, bei der der Byte-Offset auf 0xc0 verschoben wird, kann ein Angreifer beliebige Auffüllungen zwischen dem Kopf und dem tatsächlichen 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 Payload an der verschobenen Schwanzadresse 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 die Calldata, um die Autorisierungsprüfung zu umgehen.

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

Schlussfolgerung

Dieser Vorfall wurde durch die Abhängigkeit von einem hartcodierten 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äßigen, aber gültigen Calldata, impersonierte ein genehmigtes Opfer als Zahler und leitete den Swap-Output um.

Zur Reduzierung ähnlicher Risiken in der Zukunft:

• Verlassen Sie sich niemals auf hartcodierte Calldata-Offsets für dynamische 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 Tokenfluss konsistent gegen den beabsichtigten Aufrufer und den Ausführungskontext validiert werden.

5. Der BitcoinReserveOffering Contract Vorfall

Kurze Zusammenfassung

Am 5. März 2026 wurde der BitcoinReserveOffering-Vertrag auf Ethereum ausgenutzt, was zu einem Verlust von etwa 2,7 Millionen Dollar führte. Die Hauptursache war eine fehlerhafte Geschäftslogik: Bei der Verarbeitung einer vollständigen ERC-3525 SFT-Einzahlung wurde die Minting-Logik innerhalb eines einzigen Aufrufs zweimal 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 seine BRO-Token-Bilanz 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 mintet 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 mintet 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 mintet 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, wobei der gewrappte ERC-20-Wert wieder in eine SFT-Position umgewandelt wird.

Schwachstellenanalyse

Die Hauptursache ist, 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 den gesamten 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 mintet BRO an den Sender. Nach Rückkehr des Callbacks 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, seine BRO-Bilanz durch eine Burn-Mint-Schleife wiederholt aufzublähen.

Angriffsanalyse

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

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

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

1. Wrappe 135e18 BRO-Token in einen SFT-Token.

2. Rufe mint() mit dem vollständigen SFT-Wert auf, was den onERC721Received()-Callback auslöst und 135e18 BRO-Token mintet; der äußere mint() fährt dann fort und ruft _mint() erneut auf, was zu einem doppelten Minting von insgesamt 270e18 BRO-Token führt.

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

• Schritt 3: Nach 22-facher Wiederholung von Schritt 2 sammelte der Angreifer ungefähr 567.758.816e18 BRO-Token an, die schließlich gegen 38e18 SolvBTC als Gewinn eingetauscht wurden.

Schlussfolgerung

Dieser Vorfall wurde durch doppeltes Minting bei vollständigen SFT-Einzahlungen verursacht, wodurch der Angreifer seine BRO-Bilanz durch wiederholte Burn-Mint-Zyklen exponentiell aufblähen und die überschüssigen Token gegen SolvBTC einlösen konnte.

Zur Reduzierung ähnlicher Risiken in der Zukunft:

• 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 Verlusten von rund 127 Tausend Dollar führte. Die Hauptursache 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 stellte einen bösartigen Vertrag bereit, um die Prüfung zu umgehen, prägte eine große Menge Token und verkaufte diese dann über den Liquiditätspool mit Gewinn.

Hintergrund

MoltEVM ist ein experimentelles ERC-20-Token-Protokoll, das auf Base bereitgestellt wird und ein sich selbst replizierendes Token-Modell erforscht. Das System ermöglicht es einem Token, neue Kind-Token ("Moltling"-Token) zu erzeugen, sobald bestimmte Reserve-Schwellenwerte erreicht sind. Wenn ein neuer Moltling erstellt wird, wird ein anfänglicher Token-Vorrat über die Funktion mintFromSpawner() verteilt, und die Liquidität wird automatisch angesiedelt, 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 Token-Generation weitere Nachkommen erzeugen kann.

Schwachstellenanalyse

Die Schwachstelle liegt in der Zugriffskontrolllogik der Funktionen mintFromSpawner() und setExemptFromSpawner() im MoltEVM-Vertrag (0x225d...501f). Beide Funktionen verlassen sich auf den Modifier onlySpawnerToken, der ursprünglich dazu gedacht war, Aufrufe an legitime Moltling-Verträge zu beschränken, die vom Protokoll gespawnt wurden.

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

Infolgedessen kann ein Angreifer einen minimalen Vertrag bereitstellen, der einfach eine initialized()-Funktion implementiert, die true zurückgibt. Nach der Bereitstellung kann der bösartige Vertrag frei mintFromSpawner() aufrufen, um beliebige Mengen von Token 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 Gewinnerzielung in Liquiditätspools zu verkaufen.

Angriffsanalyse

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

• Schritt 1: Der Angreifer stellte einen minimalen Vertrag bereit, der eine einzelne initialized()-Funktion implementierte, die hartcodiert true zurückgab, was ausreichte, um die Prüfung des onlySpawnerToken-Modifiers zu bestehen.

• 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 groß angelegte Token-Verkäufe keine Verkaufssteuern oder die interne Swap-Logik auslösten, was den Gewinn maximierte.

  

• Schritt 3: Der Angreifer wiederholte die Funktionssequenz setExemptFromSpawner() + mintFromSpawner() zuerst gegen mEVM, gefolgt von mehreren Moltling-Kind-Token, darunter CSPAWN, CCUTTL, LWORM und NHYDRA, wobei Token stapelweise über alle Ziele geprägt und in ihre jeweiligen Liquiditätspools verkauft wurden, um den Gewinn zu erzielen.

  

Schlussfolgerung

Dieser Vorfall wurde durch eine unzureichende Zugriffskontrolle auf privilegierte Minting- und Konfigurationsfunktionen verursacht, die es einem Angreifer ermöglichte, einen legitimen Spawner zu impersonieren und beliebige Token zum Profit zu prägen.

Zur Reduzierung ähnlicher Risiken in der Zukunft:

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

• Vermeiden Sie die Abhängigkeit von leicht fälschbaren Vertragprüfungen für die Autorisierung.

• Validieren Sie die Identität des Aufrufers über explizite Whitelists oder vertrauenswürdige Vertragsregister.

7. LEDS Vorfall

Kurze Zusammenfassung

Am 8. März 2026 wurde der LEDS-Token auf der BNB Chain ausgenutzt, was zu Verlusten von rund 64 Tausend Dollar führte. Die Hauptursache war eine fehlerhafte Geschäftslogik: Der Token-Vertrag exponiert mehrere unabhängige deflationäre Mechanismen, von denen jeder Token direkt aus dem Liquiditätspaar verbrennen kann, und keiner ist durch Zugriffskontrolle oder Abkühlzeiten geschützt. Der Angreifer verknüpfte alle Burn-Pfade innerhalb einer einzigen Transaktion, ließ das LEDS-Reserve des Paares auf nahezu Null kollabieren, während das WBNB-Reserve intakt blieb, und führte dann Umkehrswaps durch, um den unausgeglichenen Pool zur Gewinnerzielung 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 darauf ausgelegt sind, den Vorrat schrittweise zu reduzieren und den Preis zu stützen: eine tägliche Burn-Funktion triggerDailyBurnAndMint(), ein verzögerter Burn über stor_18-Akkumulation bei Verkäufen und ein spezieller Zweig, der Token auf 0xdead verbrennt, wenn der Swap-Empfänger auf den PancakeSwap-Router gesetzt ist. Der Token verfügt außerdem über eine deposit()-Funktion, bei der Benutzer BNB senden, um LEDS zu prägen und Liquidität bereitzustellen, wodurch LP-Prämien verdient werden, die über einen Distributor beansprucht werden können.

Schwachstellenanalyse

Die Hauptursache ist eine fehlerhafte Geschäftslogik im LEDS-Token-Vertrag (0xfb62...a48f). Das Opfer ist das LEDS/WBNB-Paar (0xd109...6f3f). Der Token implementiert mehrere deflationäre Mechanismen: triggerDailyBurnAndMint(), der Sell-Path 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 graduelle Deflationstools dienen, können sie innerhalb einer einzigen Transaktion verkettet werden, um ihre Effekte zu verstärken. Darüber hinaus ermöglicht die öffentliche Funktion 0x17a06174(), dass jeder den gesamten angesammelten stor_18-Saldo nach Belieben leeren kann, ohne Zugriffskontrolle oder Ratenbegrenzung. Durch die sequenzielle Stapelung dieser Burn-Pfade kann ein Angreifer die LEDS-Reserve des Paares auf nahezu Null reduzieren, während die WBNB-Reserve unberührt bleibt, was zu einer extremen Preisverzerrung führt, die über Umkehrswaps ausgenutzt werden kann.

Angriffsanalyse

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

• Schritt 1: Der Angreifer beschaffte sich über Flash-Loans (Moolah + Venus-Besicherungsdarlehen + Aave + PancakeSwap V4) eine große Menge WBNB.

• Schritt 2: Führte mehrere deposit()-Aufrufe durch, um LP-Prämien anzusammeln, und löste dann triggerDailyBurnAndMint() aus, was einen Teil von LEDS aus dem Paar verbrannte und Prämien an den Distributor sendete, wodurch die LEDS-Reserve im Pool reduziert wurde.

  

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

  

• Schritt 4: Verkaufte die beanspruchten LEDS gegen WBNB. Da das LEDS-Guthaben des Paares nach dem Verkauf den Schwellenwert überschritten hatte, wurde der übertragene Betrag in stor_18 (ausstehendes Burn) angesammelt.

  

• Schritt 5: Kaufte LEDS über PancakeSwap mit dem Empfänger auf die Router-Adresse gesetzt. Dies löste einen speziellen Zweig in _transfer() aus, der die gekauften LEDS direkt aus dem Paar auf 0xdead verbrannte, wodurch die LEDS-Reserve des Pools weiter reduziert wurde.

  

• Schritt 6: Rief die Funktion 0x17a06174() auf, die den gesamten stor_18-Saldo (in Schritt 4 angesammelt) aus dem Paar auf 0xdead verbrannte und sync() aufrief, was die LEDS-Reserve des Pools auf nur 2 Wei zusammenbrechen ließ.

  

• Schritt 7: Führte Umkehrswaps durch, um WBNB aus dem nun stark unausgeglichenen Pool abzuzweigen, 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 innerhalb einer einzigen Transaktion verknüpft werden konnten, 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 Burn-from-Pair-Funktionen ohne angemessene Zugriffskontrolle, Ratenbegrenzung oder Durchsetzung von Abkühlzeiten anbieten.

• Vermeiden Sie die sequenzielle Auslösung mehrerer unabhängiger Burn-Mechanismen innerhalb einer einzelnen Transaktion.

Über BlockSec

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

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 Milliarden von Kryptowährungen 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