Wöchentliche Web3-Sicherheitsvorfälle | 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 rund 3,25 Mio. USD. Die nachstehende Tabelle fasst diese Vorfälle zusammen, und detaillierte Analysen für jeden Fall werden in den folgenden Unterabschnitten bereitgestellt.

*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.000 USD führte. Die Grundursache war eine fehlerhafte Token-Konstruktion: Der Vertrag bindet einen zeitlich akkumulierenden deflationären Mechanismus ein, der Token direkt aus den Reserven des AMM-Paares abzieht, wenn sie übertragen werden. Der Vertragseigentümer verkürzte vor dem Angriff das Auslöseintervall auf einen unzumäßig kleinen Wert, was dazu führte, dass Hunderte von Burn-Runden angesammelt und in einem einzigen Aufruf ausgeführt wurden. Der Angreifer nutzte einen Flash-Loan aus, um diesen Mechanismus auszulösen, die Reserven des Paares kollabieren zu lassen und den Token-Preis aufzublähen, und tauschte dann zum verzerrten Kurs für Profit zurück.

Hintergrund

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

Schwachstellenanalyse

Die Grundursache ist eine Designschwäche im BUBU2-Token-Vertrag (0x3fF3...ee52). Der Vertrag bindet einen periodischen deflationären Mechanismus in seinen _update()-Hook ein: Wenn ausgelöst, berechnet \_triggerDailyBurnAndMint() die Anzahl der seit der letzten Ausführung vergangenen 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(), um die Reserven zu aktualisieren. 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äßigen 6 Stunden auf 120 Sekunden komprimiert wurde. Da lastTriggerTime 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 einzige Übertragung eine massive Menge an BUBU2 aus dem Paar zog, seine Reserven kollabieren ließ und den Token-Preis um ungefähr 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), verkürzte dann das Auslöseintervall 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 sie 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, wodurch nach Ausführung von sync() nur noch 6.493.352e18 BUBU2 im Reserve blieben, was den BUBU2-Preis um etwa das 200-fache aufblähte.

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

Schlussfolgerung

Die Ausnutzung von BUBU2 resultierte aus einer kritischen Designschwäche im Token-Vertrag. Der Eigentümer konfigurierte ein unzumäßig kleines TRIGGER_INTERVAL, das es der vergangenen Zeit ermöglichte, sich zu Hunderten von Runden zu summieren und die Reserven des Handelspaares in einem einzigen Aufruf zu entleeren, was zu einem starken 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.

• Beschränken oder begrenzen 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.000 USD führte. Die Grundursache war eine fehlerhafte Geschäftslogik im Payment Manager-Vertrag: Der Job-Status wurde als Speicher-Kopie anstatt als Speicher-Referenz geladen, sodass die Verfolgung der kumulativen Auszahlungen niemals on-chain gespeichert wurde. Dies ermöglichte es dem Angreifer, einen Job zu erstellen, die automatische Auszahlung während des Phasenübergangs auszulösen und dann dieselben hinterlegten 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 folgen einem 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 verwahrten Gelder über die Funktion releasePayment() an den Anbieter frei. Um doppelte Beanspruchung 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 Grundursache liegt in der Funktion releasePayment() des PaymentManager-Vertrags (0x56c3...0684), in der der Job-Status als Speicher-Kopie statt als Speicher-Referenz geladen wird. Obwohl das Protokoll kumulative Auszahlungen über amountClaimed verfolgt, um doppelte Beanspruchung zu verhindern, arbeitet 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 entleeren, 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 anschließenden Angriff.

• Schritt 2: Innerhalb des Callbacks rief der Angreifer die Funktion createJob() auf dem ACPRouter auf und setzte dabei einen neuen Anbieter-Vertrag (0x1ee502dd...) zur Entgegennahme der Gelder ein.

• Schritt 3: Der Angreifer rief wiederholt die Funktion createMemo() auf und nutzte die exec()-Funktion des eigenen Anbieter-Vertrags, 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 Anbieter-Vertrag freigab. Zu diesem Zeitpunkt hätte amountClaimed aktualisiert werden müssen, aber sein Wert im Speicher blieb 0.

• Schritt 4: Der Angreifer rief die Funktion claimBudget() auf und beanspruchte erfolgreich die hinterlegten 97.000e6 USDC zum zweiten Mal als Gewinn.

Schlussfolgerung

Dieser Vorfall wurde durch einen Fehler bei der Speicherung von Zustandsdaten verursacht, der es ermöglichte, hinterlegte Gelder innerhalb desselben Job-Lebenszyklus zweimal zu beanspruchen.

Um ähnliche Risiken in Zukunft zu reduzieren:

• Stellen Sie sicher, dass kritische Zustandsvariablen (z.B. amountClaimed) mit Speicher-Referenzen aktualisiert werden.

• Beschränken Sie sensible Auszahlungsfunktionen oder erzwingen Sie eine strenge Zustandsvalidierung 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.000 USD führte. Die Grundursache ist Preismanipulation. Genauer gesagt 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 immer noch liquidiert werden, auch wenn der Preis des Collaterals steigt. Daher kann ein Angreifer donate() verwenden, um den sDOLA-Preis in die Höhe zu treiben, die Positionsgesundheit der Benutzer unter Null zu treiben und dann diese Benutzer 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 platziert LLAMMA die Sicherheiten der Benutzer in Preisbändern innerhalb des AMM. Wenn sich der Oracle-Preis $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ bewegt, wird die Sicherheit durch arbitragegetriebene Swaps über die Bänder hinweg progressiv zwischen dem Sicherheitstoken und crvUSD umgewandelt (weiche Liquidation), wodurch Positionen schrittweise risikominimiert werden, anstatt abrupte Liquidationen auszulösen.

Wenn die weiche Liquidation eine Position nicht schnell genug risikominimieren kann, greift die harte 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 nicht einfach die Sicherheit zum Marktwert bewertet. Stattdessen simuliert sie eine Hin- und Rückumwandlung der Benutzerposition, um ihren wieder einbringbaren Wert zu bewerten. Diese Hin- und Rückumwandlung verwendet zwei verschiedene Preisanker: einen, der sich aus dem aktuellen $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ ergibt (bewegt sich mit dem Live-Orakel), und einen anderen, der sich aus den Bandgrenzen des Benutzers ergibt (festgelegt, 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-Tresor-Token, dessen Anteilspreis durch das Verhältnis von Gesamtvermögen zu Gesamtzahl der Anteile bestimmt wird. Da jeder donate() aufrufen kann, um Vermögenswerte dem Tresor hinzuzufügen, kann der Anteilspreis innerhalb einer einzelnen Transaktion aufgebläht werden. Dies ist das manipulable Orakel, von dem die Gesundheitsfunktion von LLAMMA abhängt.

Wie im Hintergrund beschrieben, berechnet get_x_down() die Gesundheit durch Simulation einer Hin- und Rückumwandlung über zwei Preisanker: einen, der sich aus $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ ergibt (dynamisch, bewegt sich mit dem Live-Orakel), und einen, der sich aus den Bandgrenzen des Benutzers ergibt (statisch, festgelegt 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 also der Orakelpreis aufgebläht ist, steigt der dynamische Anker, aber der statische Anker bleibt gleich. Tatsächlich wandelt die Simulation crvUSD zum aufgeblähten Orakelpreis in Sicherheit um und wandelt ihn zum ursprünglichen Bandpreis zurück, sodass der bewertete wieder einbringbare Wert schrumpft, wenn die Lücke zwischen den beiden Ankern breiter wird. Dies führt dazu, dass die Gesundheit unter Null fällt, obwohl der Preis der Sicherheit gestiegen ist.

Angriffsanalyse

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

• Schritt 1: LLAMMA-Zustand manipulieren (große Swaps), um active_band zu verschieben und viele Benutzer in die 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: Gesundheitsneuberechnung auslösen über users_to_liquidate() -> _health() -> get_x_down().

• Schritt 4: Da get_x_down() den wieder einbringbaren Wert über zwei divergierende Preisanker (den dynamischen Anker, jetzt aufgebläht, versus den statischen Anker, unverändert) berechnet, führt die Hin- und Rückumwandlung zu einem Abschlag auf den effektiven Wert, und viele Positionen fallen unter die Gesundheit Null.

• Schritt 5: Stapelweise harte 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 in großem Umfang verwendet. Der zweite Kredit wurde verwendet, um crvUSD zu erhalten, um die Schuld der ersten Position zurückzuzahlen und Kapital zu recyceln. Diese beiden Kredite sind hauptsächlich Finanzierungs-/Abwicklungsbeine und nicht die Kern-Exploit-Schritte selbst.

Schlussfolgerung

Der Vorfall ist ein Angriff zur Manipulation des Collateralpreises. Der Angreifer manipulierte den sDOLA-Preis innerhalb einer Transaktion und trieb aufgrund des pfadbasierten Gesundheitsmechanismus von LLAMMA Benutzer in Liquidationsbedingungen. Eine wesentliche Folge ist, dass Positionen auch dann liquidierbar werden können, wenn der Collateralpreis steigt. Empfohlene Härtungsrichtungen:

• Verwenden Sie verzögerte oder TWAP-Collateralpreise 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.000 USD 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 Überprüfung umgingen, ein zuvor genehmigtes Opfer als Zahler nachahmten und die Swap-Ausgabe 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 einzigen Einstiegspunkt zu nutzen.

Schwachstellenanalyse

Die Grundursache 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 und sicherzustellen, dass der in data kodierte Zahler mit msg.sender übereinstimmt. Das Protokoll geht davon aus, dass der Byte-Offset immer 0x40 ist, was den Zahler an Byte-Position 164 (0xa4) platziert.

Die ABI-Kodierung garantiert jedoch dieses Layout nicht: Dynamische Parameter speichern nur einen Offset im Kopf, und dieser Offset kann rechtmäßig auf jede ausgerichtete Position in 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 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 die Swap-Ausgabe 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 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äßiger, aber gültiger Calldata, gab sich als genehmigtes Opfer als Zahler aus und leitete die Swap-Ausgabe 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 kanonischer ABI-Dekodierung anstelle manueller positionsbezogener Annahmen.

• Stellen Sie sicher, dass der tatsächliche Zahler, Empfänger und Token-Fluss konsistent mit dem beabsichtigten Aufrufer und dem 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 rund 2,7 Millionen US-Dollar führte. Die Grundursache war eine fehlerhafte Geschäftslogik: Bei der Verarbeitung einer vollständigen ERC-3525 SFT-Einzahlung wurde die Minting-Logik zweimal innerhalb eines einzigen Aufrufs 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 seinen BRO-Token-Saldo 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 mint()-Funktion 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 das vollständige Token in den Wrapper-Vertrag und mintet BRO basierend auf dem Gesamtwert des SFT. Benutzer können später die burn()-Funktion aufrufen, um BRO wieder in seine entsprechende ERC-3525 SFT-Position einzulösen und den gewrappten ERC-20-Wert zurück in eine SFT-Position umzuwandeln.

Schwachstellenanalyse

Die Grundursache liegt darin, dass der BitcoinReserveOffering-Vertrag (0x15f7...cfcf) die Minting-Logik bei der Verarbeitung einer vollständigen ERC-3525 SFT-Einzahlung in der mint()-Funktion zweimal ausführt. 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. Nachdem der Callback zurückgekehrt ist, setzt mint() die Ausführung fort, berechnet den Wert erneut mit demselben amount_ und führt eine zweite _mint(msg.sender, value)-Operation durch. Dieses doppelte Minting-Verhalten ermöglicht es einem Angreifer, seinen BRO-Saldo 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. Wickelte 135e18 BRO-Token in einen SFT-Token.

2. Rief mint() mit dem vollen SFT-Wert auf, was den onERC721Received()-Callback auslöste und 135e18 BRO-Token mintete; der äußere mint() fuhr fort und rief _mint() erneut auf, was zu einem doppelten Mint von insgesamt 270e18 BRO-Token führte.

3. Wickelte die 270e18 BRO-Token wieder in einen SFT-Token.

• Schritt 3: Nach 22 Wiederholungen von Schritt 2 akkumulierte der Angreifer ungefähr 567.758.816e18 BRO-Token, die schließlich 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, seinen BRO-Saldo durch wiederholte Burn-Mint-Zyklen exponentiell aufzublähen und die überschüssigen Token gegen SolvBTC einzulösen.

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 Verlusten von rund 127.000 USD führte. Die Grundursache war eine fehlerhafte Zugriffssteuerungslogik 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, mintete eine große Menge an Token und verkaufte sie über den Liquiditätspool, um Profit zu erzielen.

Hintergrund

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

Schwachstellenanalyse

Die Schwachstelle liegt in der Zugriffssteuerungslogik der Funktionen mintFromSpawner() und setExemptFromSpawner() im MoltEVM-Vertrag (0x225d...501f). Beide Funktionen verlassen sich auf den Modifier onlySpawnerToken, der dazu bestimmt war, Aufrufe an legitime, vom Protokoll gespawnte Moltling-Verträge zu beschränken.

Der Modifier führt jedoch nur zwei schwache Prüfungen durch: Er prüft, ob msg.sender ein Vertrag ist und ob der Aufruf 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 bereitstellen, der einfach eine initialized()-Funktion implementiert, die true zurückgibt. Nach der Bereitstellung kann der bösartige Vertrag mintFromSpawner() frei aufrufen, um beliebige Mengen an Token zu minten, 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 gemintete Token zur Gewinnmitnahme 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 fest auf true gesetzt war, 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 Sequenz setExemptFromSpawner() + mintFromSpawner() gegen mEVM zuerst, gefolgt von mehreren Moltling-Kind-Token, darunter CSPAWN, CCUTTL, LWORM und NHYDRA, wobei Token über alle Ziele hinweg im Stapel gemintet und in ihre jeweiligen Liquiditätspools verkauft wurden, um Profit zu erzielen.

Schlussfolgerung

Dieser Vorfall wurde durch unzureichende Zugriffssteuerung bei privilegierten Minting- und Konfigurationsfunktionen verursacht, die es einem Angreifer ermöglichten, sich als legitimer Spawner auszugeben und beliebige Token zur Gewinnmitnahme zu minten.

Um ähnliche Risiken in Zukunft zu reduzieren:

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

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

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

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.000 USD führte. Die Grundursache war eine fehlerhafte Geschäftslogik: Der Token-Vertrag stellt mehrere unabhängige deflationäre Mechanismen bereit, von denen jeder Token direkt aus dem Liquiditätspaar brennen kann, und keiner ist durch Zugriffssteuerung oder Abkühlzeit geschützt. Der Angreifer verknüpfte alle Burn-Pfade innerhalb einer einzigen Transaktion, ließ das LEDS-Reserve des Paares auf nahezu Null sinken, während das WBNB-Reserve intakt blieb, und führte dann umgekehrte Swaps durch, um den unausgeglichenen 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 darauf ausgelegt sind, den Vorrat schrittweise zu reduzieren und den Preis zu unterstützen: eine tägliche Burn-Funktion triggerDailyBurnAndMint(), ein verzögerter 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 wird. Der Token verfügt auch über eine deposit()-Funktion, bei der Benutzer BNB senden, um LEDS zu minten und Liquidität bereitzustellen, wobei sie LP-Belohnungen verdienen, die über einen Distributor beansprucht werden können.

Schwachstellenanalyse

Die Grundursache 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-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() auf, um die Reserven zu aktualisieren.

Während diese Mechanismen einzeln als schrittweise deflationäre Werkzeuge dienen, können sie innerhalb einer einzelnen Transaktion verknüpft werden, um ihre Effekte zu verstärken. Darüber hinaus erlaubt die öffentliche Funktion 0x17a06174(), dass jeder den gesamten akkumulierten stor_18-Saldo nach Belieben leert, ohne Zugriffssteuerung oder Ratenbegrenzung. Durch das sequentielle Stapeln dieser Burn-Pfade kann ein Angreifer das LEDS-Reserve des Paares auf nahezu Null reduzieren, während das WBNB-Reserve unberührt bleibt, was eine extreme Preisverschiebung verursacht, die durch umgekehrte Swaps ausgenutzt werden kann.

Angriffsanalyse

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

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

• Schritt 2: Mehrere deposit()-Aufrufe wurden durchgeführt, um LP-Belohnungen anzusammeln, dann wurde triggerDailyBurnAndMint() ausgelöst, was einen Teil von LEDS aus dem Paar verbrannte und Belohnungen an den Distributor sendete, wodurch das LEDS-Reserve im Pool reduziert wurde.

• Schritt 3: Die Funktion 0xde1b1942() wurde aufgerufen, um die angesammelten LEDS-Token-Belohnungen zu beanspruchen.

• Schritt 4: Die beanspruchten LEDS wurden gegen WBNB verkauft. Da das LEDS-Guthaben des Paares nach dem Verkauf den Schwellenwert überschritt, wurde der übertragene Betrag in stor_18 (anstehender Burn) akkumuliert.

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

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

• Schritt 7: Umgekehrte Swaps wurden durchgeführt, um WBNB aus dem nun stark unausgeglichenen Pool zu ziehen, alle Flash-Loans zurückzuzahlen und 104,56 WBNB (64.000 USD) 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 Verbrennen aus Paaren freigeben, ohne ordnungsgemäße Zugriffssteuerung, Ratenbegrenzung oder die Durchsetzung von Abkühlzeiten.

• Vermeiden Sie es, mehrere unabhängige Burn-Mechanismen in einer einzigen Transaktion hintereinander auszulösen.

Ü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, Blockchains und Wallets), der Echtzeit-Abwehr von Angriffen, der Analyse von Vorfällen, der Verfolgung illegaler Gelder und der Erfüllung von AML/CFT-Verpflichtungen während des gesamten Lebenszyklus von Protokollen und Plattformen unterstützen.

BlockSec hat mehrere Blockchain-Sicherheitspapiere 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 senden

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance