Wöchentlicher Web3-Sicherheitsvorfall-Rundgang | 9. – 15. März 2026

Während der vergangenen Woche (09.03.2026 - 15.03.2026) hat BlockSec acht Angriffsvorfälle erkannt und analysiert, mit geschätzten Gesamtschäden von rund 1,66 Mio. USD. Die folgende Tabelle fasst diese Vorfälle zusammen, und detaillierte Analysen für jeden Fall werden in den folgenden Unterabschnitten bereitgestellt.

EtherFreakers Vorfall

Kurze Zusammenfassung

Am 9. März 2026 wurde EtherFreakers, ein NFT-Spiel auf Ethereum, aufgrund einer falschen doppelten Zählung ausgenutzt, was zu einem Verlust von rund 25 Tsd. USD führte. Jedes NFT im Spiel hat einen abhebungsfähigen ETH-Guthaben (genannt "Energie"). Als Spielmechanik können Spieler attack() verwenden, um ein NFT ein anderes einfangen zu lassen und die Energie des Ziels zu beanspruchen. Der Vertrag zahlt jedoch das Guthaben des Ziels aus, überträgt aber das NFT, bevor die Buchhaltung abgerechnet wird. Ein Transfer-Hook liest dann veraltete Daten vor der Auszahlung und speist einen Teil davon zurück in einen globalen Dividendenpool, wodurch der Pool ohne neue ETH-Deckung aufgebläht wird. Der Angreifer nutzte diese Fangmechanik, um den globalen Index zu pumpen und zog dann das aufgeblähte Guthaben aus einer Reihe von NFTs ab.

Hintergrund

EtherFreakers ist ein On-Chain-NFT-Spiel, bei dem jedes NFT (genannt "Freaker") einen abhebungsfähigen ETH-Guthaben namens energy hält. Das System funktioniert wie ein Dividendenpool: Wenn bestimmte Aktionen stattfinden, wird ein Bruchteil von ETH proportional an alle Freaker verteilt. Der abhebungsfähige ETH jedes Freakers wird durch einen globalen Akkumulator freakerIndex in Kombination mit einem Token-spezifischen Anteilgewicht fortune verfolgt.

Konkret lautet die Buchhaltungsformel: energyOf = basic + (freakerIndex - index) * fortune. Der freakerIndex erhöht sich, wenn _dissipateEnergyIntoPool(amount) ausgeführt wird, wobei 80 % von amount an alle Freaker und 20 % an die Ersteller verteilt werden. Direkte Einzahlungen über charge() erhöhen nur basic, ohne den freakerIndex zu beeinflussen. Daher sollten Erhöhungen des freakerIndex immer durch reale Ether gedeckt sein, die in das System gelangen. Wenn der freakerIndex ohne entsprechenden ETH-Zufluss wächst, können Freaker mehr Ether einlösen, als der Vertrag tatsächlich enthält.

Schwachstellenanalyse

Die Ursache liegt in einer falschen Ausführungsreihenfolge im EtherFreak-Vertrag (0x3A27...c0f33). Wenn ein Fang erfolgreich ist, führt die Funktion attack() die folgenden Schritte in dieser Reihenfolge aus:

1. Zeile 237: Zahlt targetCharge (die volle Energie des Ziel-NFTs) als direkte ETH-Überweisung an den Verteidiger aus. Die Energie ist nun verbraucht.
2. Zeile 240: Ruft _transfer(defender, capturer, targetId) auf, um das NFT zu verschieben. Intern ruft _transfer() den ERC-721-Hook _beforeTokenTransfer() auf, der _dissipateEnergyIntoPool() mit 0,1 % von energyOf(targetId) aufruft. Dies ist der erste Aufruf von _dissipateEnergyIntoPool(), und er liest einen veralteten Wert, da Schritt 5 noch nicht stattgefunden hat.
3. Zeile 241: Ruft _dissipateEnergyIntoPool(sourceSpent) explizit auf. Dies ist der zweite Aufruf, der Teil der normalen Spiellogik ist.
4. Zeilen 244-251: Aktualisiert die energyBalances sowohl für sourceId als auch für targetId.

Der Fehler liegt in Schritt 2: Da energyBalances[targetId] noch nicht aktualisiert wurde, sieht der Hook weiterhin den Guthabenstand vor der Auszahlung und gibt einen Teil der bereits ausgegebenen Energie in den Dividendenpool. Sowohl die direkte ETH-Auszahlung in Schritt 1 als auch die Pool-Einspeisung in Schritt 2 stammen aus derselben Energie, was den freakerIndex ohne neue ETH-Deckung aufbläht.

Der freakerIndex wächst immer dann, wenn _dissipateEnergyIntoPool() aufgerufen wird:

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x89e24d...9abd2942.

• Schritt 1: Leihen von 1.700 WETH.

• Schritt 2: Prägen von zwei neuen Freakers, Token 590 und Token 591, unter Adressen, die vom Angreifer kontrolliert werden.

• Schritt 3: Wiederholtes Aufrufen der attack(590, 591)-Funktion des Spiels und Beibehalten der Ausführungen im erfolgreichen Fangzweig.

• Schritt 4: Nach jedem Erfolg wird Token 591 zurück an den Helfer übertragen, damit dasselbe Paar wiederverwendet werden kann.

• Schritt 5: Jeder erfolgreiche Durchlauf bläht den freakerIndex über den tatsächlich vom System erhaltenen Ether hinaus auf.

• Schritt 6: Sobald der Index hoch genug ist, wird eine Charge von zuvor kontrollierten Freakers abgebucht. Die Token-IDs 496 bis 520 werden jeweils für 0.278052246002402082 Ether abgebucht.

• Schritt 7: Der abgehobene Ether wird in WETH eingewickelt, der Flash-Kredit von 1.700 WETH zurückgezahlt und etwa 7,498 WETH als Gewinn behalten.

Schlussfolgerung

Die Ursache liegt im erfolgreichen Fangablauf von attack(): EtherFreakers zahlt targetCharge aus, bevor der Energiezustand des Ziel-Tokens abgerechnet ist. _transfer() löst dann _beforeTokenTransfer() aus, das den veralteten energyOf(targetId)-Wert vor der Auszahlung liest und einen Teil davon in den Pool zerstreut. Dies erhöht den freakerIndex ohne neue Ether-Deckung, sodass dieselbe Zielenergie sowohl als Auszahlung als auch als Pool-Einspeisung gezählt wird. Dies ist ein Inflationsfehler in der Geschäftslogik, kein Reentrancy-Fehler.

Um ähnliche Risiken zukünftig zu reduzieren:

• Vermeiden Sie die Neuberechnung wirtschaftlicher Werte aus veränderlichem Zustand innerhalb von Transfer-Hooks, während dieselbe Transaktion noch abgerechnet wird.

• Wenn der Transfer-Hook eine Zustandsvariable liest, stellen Sie sicher, dass die Ausführungsreihenfolge das Ergebnis nicht beeinflusst (z. B. den Zustand vor dem Hook-Lauf abwickeln, nicht danach).

Alkemi Vorfall

Kurze Zusammenfassung

Am 10. März 2026 wurde das Alkemi-Protokoll auf Ethereum ausgenutzt, was zu einem Verlust von rund 89 Tsd. USD führte. Die Ursache sind Fehler in der Buchhaltung und der Geschäftslogik. Die fehlerhafte Liquidationslogik ermöglicht es jedem, seine eigene Position innerhalb derselben Transaktion zu liquidieren und davon zu profitieren. Zusätzlich führt ein Buchhaltungsfehler dazu, dass die Kollateralabzüge des Angreifers während der Liquidation überschrieben werden, wodurch der Angreifer Liquidationsprämien erzielen kann, ohne die beabsichtigten Kosten zu tragen.

Hintergrund

Alkemi ist ein Kreditprotokoll. Wenn die Position eines Kreditnehmers unterkollateralisiert wird, kann jeder liquidateBorrow() aufrufen, um einen Teil der Schuld zurückzuzahlen und Kollateral zu einem Rabatt zu beschlagnahmen. Um übermäßige Liquidierung zu verhindern, begrenzt das Protokoll den pro Transaktion zurückzahlbaren Betrag auf das Minimum von drei Werten:

1. Der aktuelle Schuldenstand des Kreditnehmers (currentBorrowBalance_TargetUnderwaterAsset).
2. Die maximale Rückzahlung, die das Kollateral des Kreditnehmers nach Anwendung des Liquidationsrabatts decken kann (calculateDiscountedBorrowDenominatedCollateral()).
3. Der Rückzahlungsbetrag, der erforderlich ist, um das Konto wieder an die Liquidationsgrenze zu bringen (calculateDiscountedRepayToEvenAmount()), der nur geprüft wird, wenn der Markt isSupported ist.

Schwachstellenanalyse

Die Ursache liegt in fehlerhafter Geschäftslogik und einem Buchhaltungsfehler im Alkemi-Protokoll (0x4822...a888). Da currentBorrowBalance_TargetUnderwaterAsset zwangsläufig größer als 0 ist, solange der Kreditnehmer eine ausstehende Schuld hat, und der von calculateDiscountedBorrowDenominatedCollateral() zurückgegebene Wert ebenfalls zwangsläufig größer als 0 ist, solange der Kreditnehmer Kollateral hat, verlässt sich das AlkemiEarnPublic-Protokoll effektiv auf calculateDiscountedRepayToEvenAmount(), um zu bestimmen, ob ein bestimmtes Darlehen liquidiert werden kann. In dieser Funktion sollte der zu liquidierende Schuldenbetrag anhand einer Variablen namens accountShortfall_TargetUser berechnet werden.

In der tatsächlichen Implementierung verwendet die Funktion jedoch stattdessen eine globale Variable closeFactorMantissa, um eine Obergrenze für den zurückzahlbaren Schuldenbetrag zu berechnen, und gibt diesen Wert zurück. Infolgedessen ist ein Angreifer in der Lage, seinen eigenen Kredit innerhalb derselben Transaktion aufzunehmen und sofort zu liquidieren.

Darüber hinaus zeigt die Funktion liquidateBorrow(): Wenn der Liquidator und der Kreditnehmer dieselbe Adresse sind, verweisen die Variablen supplyBalance_TargetCollateralAsset und supplyBalance_LiquidatorCollateralAsset auf denselben Speicherplatz. Die Funktion berechnet dann separat ein "reduziertes Guthaben" und ein "prämiertes Guthaben" basierend auf demselben Anfangsguthaben und schreibt sie anschließend nacheinander in denselben Speicherplatz zurück. Da das reduzierte Guthaben zuerst geschrieben und das prämiierte Guthaben danach, wird der Reduktionseffekt überschrieben und geht verloren, sodass nur das prämiierte Ergebnis übrig bleibt. Dies ermöglicht es dem Angreifer, seinen Gewinn weiter zu steigern.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xa170...6d9d.

• Schritt 1: Der Angreifer nimmt einen Flash-Kredit von 51e18 WETH von Balancer auf.

• Schritt 2: Der Angreifer wickelt 51e18 WETH in ETH um und liefert es an das Alkemi-Protokoll.

• Schritt 3: Der Angreifer leiht 39.5e18 ETH von Alkemi.

• Schritt 4: Der Angreifer liquidiert seine eigene Position mit 39.5395e18 ETH.

• Schritt 5: Der Angreifer zieht 93.5e18 ETH von Alkemi ab.

• Schritt 6: Der Angreifer zahlt den Flash-Kredit zurück und erzielt einen Gewinn von 43.4e18 ETH.

Schlussfolgerung

Die Ursache sind fehlerhafte Liquidationslogik, die es dem Angreifer ermöglicht, seine eigene Position innerhalb derselben Transaktion aufzunehmen und dann zu liquidieren, um einen Gewinn zu erzielen, während die fehlerhafte Buchhaltung die Gewinne des Angreifers weiter steigert.

Um ähnliche Risiken zukünftig zu reduzieren:

• Bei Guthabenaktualisierungen für den Kreditnehmer und den Liquidator sollte das Protokoll direkt auf Speicher variablen operieren, anstatt die Guthaben in temporäre Speicher variablen zu kopieren, um separate Berechnungen und Rückschreibungen durchzuführen.

MT Vorfall

Kurze Zusammenfassung

Am 10. März 2026 wurde MT Token, ein deflationärer Token auf der BNB Chain, ausgenutzt, was zu einem Verlust von rund 242 Tsd. USD führte. Die Ursache sind fehlerhafte Handelsbeschränkungs logik in Kombination mit inkonsistenter Behandlung von Sonderübertragungs bedingungen. Während der Deflationsphase beschränkt der Vertrag Kauf operationen, wenn die Pool reserve einen festen Schwellenwert überschreitet. Der Vertrag behandelt jedoch Überweisungen exakter Beträge (z. B. 2e17 MT) als Empfehlungs bindungs aktionen, die es dem Angreifer ermöglichen, die Kauf beschränkung zu umgehen und anfängliche Token zu erwerben. Darüber hinaus stützt sich die Beschränkungs logik auf eine unvollständige Pfaderkennung (isBuy) und deckt keine indirekten Swap-Routen wie Pair zu Router ab, während Whitelist-Prüfungen kritische Validierungen weiter umgehen. Der Angreifer sammelte MT-Token an, ohne Beschränkungen oder Gebühren auszulösen, manipulierte pendingBurnAmount durch kontrollierte Liquiditäts operationen und Trades und zwang den Pool in einen abnormalen Zustand, in dem der Token-Preis künstlich aufgebläht wurde.

Hintergrund

MT Token ist ein deflationärer Token auf der BNB Chain mit integrierten Handels beschränkungen. Während der Deflationsphase blockiert der Vertrag Kauf operationen, wenn die MT-Reserve im Pool 21.000e18 überschreitet. Sobald die Reserve unter diesen Schwellenwert fällt, endet die Deflationsphase und der Kauf wird wieder aktiviert. MT Token enthält auch einen Empfehlungs mechanismus: Eine Überweisung von genau 2e17 MT oder 1e17 MT wird als Empfehlungs bindungs aktion behandelt und nicht als normaler Handel.

Schwachstellenanalyse

Die Ursache war ein fehlerhaftes Design der Kauf beschränkung im MT-Vertrag (0x037E...b449). Unter normalen Bedingungen sollten Angreifer während der eingeschränkten Phase kein MT als Startkapital erwerben können. Der Vertrag behandelt jedoch eine Überweisung von genau 2e17 MT als Empfehlungs bindungs aktion und nicht als Kauf, was es einem Angreifer ermöglicht, 2e17 MT zu kaufen und dabei die Kauf beschränkung zu umgehen.

Darüber hinaus stützt sich die Handels beschränkung auf den isBuy-Zweig, um Käufe zu blockieren, deckt aber nicht den "Pair to Router"-Pfad ab. Da sowohl der Router als auch das Paar Whitelist-Adressen sind, werden solche Überweisungen bei der Whitelist-Prüfung umgangen und erreichen nie die Kauf beschränkungs logik, was es einem Angreifer ermöglicht, MT zu erwerben, indem er Käufe zum Router leitet und anschließend Token durch Entfernen von Liquidität zurück zu sich selbst extrahiert.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xfb57...fca6.

• Schritt 1: Der Angreifer hat ~358.681e18 WBNB per Flash-Kredit aufgenommen.

• Schritt 2: Der Angreifer hat 2e17 MT gekauft und damit die Kauf beschränkung umgangen.

• Schritt 3: Der Angreifer hat 4e12 WBNB und 2e17 MT zum Paar hinzugefügt, um Liquidität bereitzustellen. Diese Überweisung umging die Gebühren logik aus demselben Grund wie oben.

• Schritt 4: Der Angreifer hat ~10.000.000e18 MT-Token vom Paar zum Router gekauft und damit sowohl die Kauf beschränkung als auch die Gebühren logik umgangen.

• Schritt 5: Der Angreifer hat die Hälfte seiner Liquiditätsposition entfernt, alle MT-Token im Router dabei extrahiert und dann die geborgenen MT gegen WBNB verkauft. In diesem Schritt wurde pendingBurnAmount auf etwa 9.000.000e18 manipuliert.

  

• Schritt 6: Der Angreifer hat erneut ~10.000.000e18 MT-Token gekauft, wodurch die MT-Reserve des Pools auf ~6.756.516e18 gesenkt wurde, was niedriger als pendingBurnAmount war.

  

• Schritt 7: Der Angreifer hat die verbleibende Hälfte seiner Liquiditätsposition entfernt, die gekauften MT-Token abgehoben und dann distributeDailyRewards() aufgerufen, um MT aus dem Pool zu verbrennen. Dadurch wurde die MT-Reserve auf 21.000e18 reduziert.

  

• Schritt 8: Der Angreifer tauschte alle MT gegen ~1.198e18 WBNB zurück, zahlte den Flash-Kredit zurück und schloss den Gewinn ab.

Schlussfolgerung

Dieser Exploit wurde durch fehlerhafte Handels beschränkungen verursacht, die es dem Angreifer ermöglichten, das Kaufverbot zu umgehen, indem er genau BINDING_AMOUNT an MT-Token kaufte. Nach dem Erwerb von MT-Token konnte der Angreifer weiter sowohl die Gebühren logik als auch die Kauf beschränkung umgehen, indem er zuerst Liquidität bereitstellte, dann MT in den Router kaufte und schließlich Liquidität entfernte, um die Token zurückzufordern. Der Angreifer sammelte dann pendingBurnAmount durch Verkaufs operationen an und führte den Burn aus, um die Poolreserven in einen abnormalen Zustand zu versetzen, was ihm ermöglichte, MT zu einem aufgeblähten Preis zu verkaufen und davon zu profitieren.

Um ähnliche Risiken zukünftig zu reduzieren:

• Strikte Trennung zwischen Transfer-Semantik und Handels logik durchsetzen.

AAVE Liquidation Vorfall

Kurze Zusammenfassung

Am 11. März 2026 erlitt AAVE 21 Mio. USD an fehlerhaften Liquidationen auf Ethereum, was zu einem Verlust von rund 1,01 Mio. USD führte. Die Ursache war ein falscher Orakelpreis für wstETH, der dazu führte, dass ursprünglich gesunde Positionen unterkollateralisiert wurden. Infolgedessen wurden die Positionen der Benutzer liquidiert, was zu finanziellen Verlusten führte.

Hintergrund

AAVE verwendet Orakel-Adapter zur Preisgestaltung von verpackten Assets wie wstETH. Der Adapter CAPO (Capped Price Oracle) leitet den wstETH-Preis ab, indem er den Basispreis ETH/USD mit einem Umwandlungsverhältnis multipliziert (getRatio(), d. h. wie viel ETH ein wstETH wert ist). Um die Verhältnis manipulation zu verhindern, wendet CAPO eine Snapshot-basierte Wachstumsobergrenze an:

maxRatio = snapshotRatio + maxGrowthPerSecond x (currentTime - snapshotTimestamp)

und begrenzt die Ausgabe von getRatio() während der Preisgestaltung (wenn currentRatio > maxRatio, wird maxRatio verwendet). Dieser Mechanismus begrenzt effektiv die maximale Aufwärtsentwicklung des Verhältnisses und des resultierenden Preises.

Schwachstellenanalyse

Die Ursache war eine Zeit-Verhältnis-Fehlanpassung in der CAPO-Orakel-Ankerkonfiguration (0xe1D9...61Ef): Der Snapshot-Zeitstempel und das Snapshot-Verhältnis wurden gesetzt, aber das Snapshot-Verhältnis wurde unterhalb des tatsächlichen wstETH/ETH-Verhältnisses konfiguriert. Infolgedessen lag das vom Adapter berechnete maxRatio unter dem Live-Verhältnis und begrenzte getRatio() nach unten, wodurch der wstETH/USD-Orakelpreis systematisch unterbewertet wurde. Diese gedrückte Kollateralbewertung reduzierte den Gesundheitsfaktor von Positionen, die wstETH als Kollateral verwenden, was dazu führte, dass eigentlich gesunde Konten fälschlicherweise als ungesund eingestuft und liquidiert wurden.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x9064...8a9c.

• Schritt 1: Der Liquidator hat per Flash-Kredit ~6304e18 WETH aufgenommen und den Kreditnehmer liquidiert.

• Schritt 2: Der Liquidator hat den Flash-Kredit zurückgezahlt und damit die Liquidation abgeschlossen.

Schlussfolgerung

Diese Liquidation wurde durch eine falsche Orakelpreis-Konfiguration verursacht, die Kreditnehmer, die eigentlich gesund bleiben sollten, fälschlicherweise in einen ungesunden Zustand versetzte und somit die Liquidation ihrer Positionen auslöste.

Um ähnliche Risiken zukünftig zu reduzieren:

• Stellen Sie sicher, dass kritische Parameter vor jeder Aktualisierung auf Korrektheit geprüft werden.

• Fügen Sie Validierungsprüfungen in die Implementierung ein, um falsche Parameter abzulehnen und zu verhindern, dass falsche Konfigurationen erfolgreich angewendet werden.

Planet Finance Vorfall

Kurze Zusammenfassung

Am 11. März 2026 wurde Planet Finance auf der BNB Chain ausgenutzt, was zu einem geschätzten Verlust von rund 10 Tsd. USD führte. Die Ursache war, dass das Protokoll die Erhöhung des gespeicherten Kreditbetrags eines Kreditnehmers fälschlicherweise als aufgelaufene Zinsen behandelte, was es einem Angreifer ermöglichte, wiederholt Kredite aufzunehmen und die Rabattabrechnung auszulösen, um seine verbuchten Schulden zu unterschätzen.

Hintergrund

Planet Finance ist ein Kreditprotokoll, das es Kreditnehmern ermöglicht, mit einem Zinsrabatt zurückzuzahlen. Der Rabatt ist gestaffelt und wird durch das Verhältnis zwischen dem gestakten GAMMA eines Benutzers und seinem gestakten Wert in anderen Assets bestimmt: Je höher dieses Verhältnis, desto höher der Rückzahlungsrabatt. Der Rabattplan umfasst drei Stufen, die von 0 % (Minimum) bis 50 % (Maximum) reichen.

Schwachstellenanalyse

Die Ursache war, dass bei der Abrechnung eines Kreditnehmer-Rabattes in changeUserBorrowDiscount(), das Protokoll (0x4c9E...F467) fälschlicherweise die Erhöhung des gespeicherten Kreditbetrags des Kreditnehmers als neu aufgelaufene Zinsen behandelte. Infolgedessen wurde der Rabatt, der nur für aufgelaufene Zinsen gelten sollte, fälschlicherweise auf das neu aufgenommene Kapital angewendet, wodurch die verbuchte Schuld des Kreditnehmers fehlerhaft reduziert wurde. Ein Angreifer konnte die Schleife borrow dann changeUserBorrowDiscount wiederholt durchführen, um übermäßige Rabatte anzuhäufen, was dazu führte, dass die On-Chain-verbuchte Verbindlichkeit durchweg niedriger war als der tatsächliche Kreditbetrag, und schließlich von der Diskrepanz profitierte.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x5f45...5ec9.

• Schritt 1: Der Angreifer hat einen Flash-Kredit von 200.000e18 USDT aufgenommen.

• Schritt 2: Der Angreifer verwendete 5.000e18 USDT, um WBNB zu kaufen, und verwendete dann das erworbene WBNB, um ~8.726.524e18 GAMMA zu kaufen.

• Schritt 3: Der Angreifer hat zuerst das gesamte erworbene GAMMA im gGAMMA-Markt gestaket und dann den verbleibenden USDT als Kollateral bereitgestellt, was seinen Rückzahlungsrabatt auf 5 % erhöhte und die anschließende Kreditaufnahme ermöglichte.

• Schritt 4: Der Angreifer hat wiederholt borrow und dann updateUserDiscount aufgerufen, um seine verbuchte Schuld kontinuierlich zu reduzieren.

  

• Schritt 5: Der Angreifer hat schließlich die Schuld zurückgezahlt, das Kollateral eingelöst und den Gewinn realisiert.

Schlussfolgerung

Dieser Vorfall wurde durch die fehlerhafte Rabattabrechnungs logik von Planet Finance in changeUserBorrowDiscount() verursacht, die fälschlicherweise die Erhöhung des gespeicherten Kreditbetrags eines Kreditnehmers als neu aufgelaufene Zinsen behandelt und den Zinsrabatt auf diese Differenz anwendet. Ein Angreifer kann wiederholt borrow gefolgt von updateUserDiscount aufrufen, um seine verbuchte Schuld zu unterschätzen und letztendlich weniger als die tatsächliche Verbindlichkeit zurückzuzahlen, um Gewinn zu erzielen.

Um ähnliche Risiken zukünftig zu reduzieren:

• Unterscheiden Sie Zinsen und neue Kredite im Kreditprotokoll.

AM Vorfall

Kurze Zusammenfassung

Am 12. März 2026 wurde AM Token, ein deflationärer Token auf der BNB Chain, mit einem geschätzten Verlust von rund 131 Tsd. USD ausgenutzt. AM Token implementiert einen deflationären Mechanismus, bei dem jeder Verkauf eine zusätzliche Verbrennung aus dem Liquiditätspool auslöst und Token dauerhaft entfernt, um die Gesamtmenge zu reduzieren. Die Verbrennung wird jedoch nicht sofort ausgeführt – stattdessen wird der volle Verkaufsbetrag als toBurnAmount aufgezeichnet und die tatsächliche Verbrennung wird auf den nächsten Verkauf verschoben. Diese Verzögerung schafft ein Fenster zwischen Aufzeichnung und Ausführung, in dem ein Angreifer AM zurückkaufen kann, um den AM-Pool des Pools auf toBurnAmount zu reduzieren. Wenn der nächste Verkauf die verzögerte Verbrennung auslöst, wird der gesamte AM-Pool ausgelöscht, was den Preis auf ein extremes Niveau treibt und es dem Angreifer ermöglicht, AM gewinnbringend zu verkaufen.

Hintergrund

AM Token ist ein deflationärer Token auf der BNB Chain. Bei jedem Verkauf zeichnet der Vertrag den im Tausch involvierten AM-Betrag als toBurnAmount auf und verbrennt diesen aufgezeichneten Betrag aus dem Liquiditätspool während des nächsten Verkaufs. Im Wesentlichen lösen Verkäufe eine verzögerte Verbrennung aus, die die AM-Reserve des Pools reduziert. Darüber hinaus tauscht das Protokoll vor der Ausführung der Verbrennung den angesammelten totalTokenFee in USDT und verteilt ihn gemäß seiner Gebührenallokations logik.

Schwachstellenanalyse

Die Ursache war, dass die Verkaufs logik des Tokens (0x27f9...213f) den gesamten getauschten AM-Betrag als toBurnAmount sammelt und die Verbrennung erst beim nächsten Verkauf ausführt, indem er Token aus dem AM/USDT-Paar entfernt und pair.sync() aufruft, um die Reserven zu aktualisieren. Dieses Design ermöglicht es einem Angreifer, die AM-Reserven des Pools zu manipulieren, den On-Chain-Preis zu verzerren und durch Arbitrage zu profitieren.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xd0d1...f859.

• Schritt 1: Der Angreifer hat per Flash-Kredit ~27.265.119e18 USDC und ~361.710e18 WBNB aufgenommen und diese dann gegen ~100.423.811e18 USDT getauscht.

• Schritt 2: Der Angreifer tauschte ~5.062e18 AM-Token gegen USDT, was den aufgezeichneten toBurnAmount des Vertrags auf ~4.303e18 manipulierte.

  

• Schritt 3: Der Angreifer tauschte USDT gegen AM Token, wodurch die AM-Reserve des Pools auf ~4.303e18 gesenkt wurde.

  

• Schritt 4: Der Angreifer übertrug 6 wei AM an den Pool, was die Burn-Logik des Sell-Pfades auslöste. Infolgedessen verbrannte der Vertrag den gesamten AM-Saldo aus dem Pool, wodurch die AM-Reserve auf 0 gesenkt wurde. Hinweis: Das Protokoll versucht zunächst, die angesammelten Gebühren vor der Verbrennung in USDT umzutauschen. Dieser Gebührenumwandlungspfad löst ebenfalls die Burn-Logik des Sell-Pfades aus. Nachdem die Verbrennung ausgeführt wurde und die AM-Reserve 0 erreicht hat, schlägt der Gebühren-Swap fehl. Da er in einer try/catch-Struktur eingepackt ist, führt der Fehler nicht zum Rückgängigmachen der Transaktion. Stattdessen wird die Ausführung fortgesetzt und der Gebührenakkumulator auf 0 zurückgesetzt.

  

• Schritt 5: Der Angreifer rief pool.sync() auf und übertrug die verbleibenden USDT und 1 wei AM in den Pool. Da beide Token gleichzeitig übertragen wurden, behandelte der Vertrag dies als addLiquidity, sodass toBurnAmount nicht gesammelt wurde. Die AM-Reserve wurde auf 7 aktualisiert.

  

  

• Schritt 6: Der Angreifer tauschte die verbleibenden AM-Token gegen USDT. Bei diesem Tausch löste die Übertragung von AM in das Paar die Burn-Logik des Sell-Pfades aus und reduzierte die AM-Reserve auf 1. Darüber hinaus wurde, da totalFeeAmount in Schritt 4 auf 0 zurückgesetzt worden war, die Gebühren-zu-USDT-Konvertierung nicht mehr ausgeführt, was es dem Angreifer ermöglichte, AM zu einem künstlich aufgeblähten Preis zu verkaufen.

  

• Schritt 7: Der Angreifer zahlte den Flash-Kredit zurück und realisierte den verbleibenden Gewinn.

Schlussfolgerung

Dieser Vorfall wurde durch den fehlerhaften Burn-Mechanismus von AM Token verursacht, der die im Tausch involvierten AM-Beträge jedes Verkaufs als toBurnAmount sammelt und diesen Betrag dann beim nächsten Verkauf aus dem AM/USDT-Paar verbrennt und pool.sync() aufruft. Dies ermöglicht es einem Angreifer, die AM-Reserven des Paares auf ein extremes Niveau zu manipulieren und AM zu einem künstlich aufgeblähten Preis zu verkaufen, um USDT abzuziehen.

Um ähnliche Risiken zukünftig zu reduzieren:

• Begrenzen Sie den maximalen Burn-Betrag pro Transaktion und begrenzen Sie die Häufigkeit, mit der Burn ausgelöst werden kann, um zu verhindern, dass Angreifer einen großen Teil der Token-Reserven des Pools in kurzer Zeit aufbrauchen.

DBXen Vorfall

Kurze Zusammenfassung

Am 12. März 2026 wurde DBXen, ein Burn-to-Earn-Protokoll auf Ethereum und BNB Chain, mit einem Gesamtverlust von rund 149 Tsd. USD ausgenutzt. Die Ursache war eine Inkonsistenz zwischen _msgSender() und msg.sender. Wenn burnBatch() über den forwarder aufgerufen wird, wird der verbrannte XEN-Betrag unter _msgSender() (vom Angreifer kontrolliert) aufgezeichnet, die Zyklusaufzeichnungen werden jedoch für msg.sender (den forwarder) aktualisiert. Diese Trennung ermöglicht es dem Angreifer, Prämien und Gebühren gegen veraltete Zyklusaufzeichnungen zu beanspruchen, was zu abnormal großen Auszahlungen führt.

Hintergrund

DBXen ist ein Burn-to-Earn-Protokoll: Benutzer verbrennen XEN-Token im Austausch gegen DXN-Prämien und einen Anteil an angesammelten Protokollgebühren. Der Schlüsselmechanismus funktioniert in Zyklen. Wenn ein Benutzer burnBatch() aufruft, geschehen zwei Dinge: (1) Der verbrannte XEN-Betrag wird unter der Adresse des Aufrufers (identifiziert durch _msgSender()) aufgezeichnet, und (2) der XEN-Vertrag ruft über onTokenBurned() zurück in DBXen, um die Zyklusaufzeichnungen des Aufrufers (Burn-Zyklus und lastFeeUpdateCycle) auf den aktuellen Zyklus zu aktualisieren.

Prämien und Gebühren werden über updateStats() abgerechnet. Die Prämie ist proportional zum Anteil des Benutzers am insgesamt verbrannten XEN in seinem Burn-Zyklus. Die Gebühr basiert auf den kumulierten Protokollgebühren, die seit dem letzten aufgezeichneten Zyklus des Benutzers angefallen sind. Beide Berechnungen hängen davon ab, dass die Zyklusaufzeichnungen des Benutzers aktuell sind.

Schwachstellenanalyse

Die Ursache ist eine fehlerhafte Geschäftslogik im DBXen-Protokoll (0xf5c8...2abd). Die Funktion _msgSender() prüft, ob msg.sender der forwarder ist. Wenn ja, gibt sie die letzten 20 Bytes von calldata zurück, und dieser zurückgegebene Wert kann im forwarder-Kontext beliebig gesteuert werden. burnBatch() verbrennt jedoch direkt den XEN, der von msg.sender gehalten wird. Infolgedessen kann ein Angreifer burnBatch() über den forwarder aufrufen, wodurch das Protokoll den von forwarder gehaltenen XEN verbrennt und die Burn-Zyklus-Aufzeichnungen und die Gebühren-Update-Zyklus-Aufzeichnungen des forwarder auf den aktuellen Zyklus aktualisiert. Gleichzeitig zeichnet das Protokoll jedoch den verbrannten XEN-Betrag unter der Adresse auf, die _msgSender() entspricht.

Danach ruft der Angreifer claimFees() auf, was updateStats() aufruft. Da die Zyklusaufzeichnungen der _msgSender()-Adresse nie aktualisiert wurden (sowohl der Burn-Zyklus als auch lastFeeUpdateCycle bleiben bei 0), berechnet updateStats() Prämien im aktuellen Zyklus und berechnet Gebühren, die seit Zyklus 0 angefallen sind – über die gesamte Gebührenhistorie des Protokolls. Der Angreifer profitiert dann, indem er claimFees() und claimRewards() aufruft.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x914a5a...b808bc37.

• Schritt 1: Der Angreifer rief zuerst die Funktion registerDomainSeparator() des Forwarder-Vertrags auf, die nachfolgende Aufrufe von Forwarder.execute() ermöglichte.

• Schritt 2: Der Angreifer tauschte 0.14e18 ETH gegen 13.900.000.000e18 XEN in einem Uniswap V2 Pool.

• Schritt 3: Der Angreifer übertrug 13.900.000.000e18 XEN an den Forwarder-Vertrag.

• Schritt 4: Der Angreifer verwendete Forwarder.execute(), um DBXen zu genehmigen, die 13.900.000.000e18 XEN des Forwarder auszugeben.

• Schritt 5: Der Angreifer verwendete Forwarder.execute(), um DBXen.burnBatch() aufzurufen und verbrannte 13.900.000.000e18 XEN. Der Burn-Betrag wurde unter der Adresse 0x425D3eC2DCeBE2c04bA1687504D43AFC6be7328d aufgezeichnet, während während der Burn-Ausführung XEN über onTokenBurned() zurück in DBXen rief und die relevanten Zyklusaufzeichnungen des Forwarder aktualisierte.

  

• Schritt 6: Der Angreifer verwendete Forwarder.execute(), um DBXen.claimFees() aufzurufen und erhielt 65.36e18 ETH.

• Schritt 7: Der Angreifer verwendete Forwarder.execute(), um DBXen.claimRewards() aufzurufen und prägte 2.305,4e18 DXN.

Schlussfolgerung

Die Ursache dieses Vorfalls war, dass das DBXen-Protokoll _msgSender() und msg.sender inkonsistent verwendete. Da diese beiden Werte unterschiedlich sein konnten, wurde die interne Buchhaltung des Protokolls inkonsistent, was es dem Angreifer ermöglichte, die Diskrepanz gewinnbringend auszunutzen.

Um ähnliche Risiken zukünftig zu reduzieren:

• Verwenden Sie _msgSender() konsistent in allen Logikpfaden, oder stellen Sie sicher, dass msg.sender-abhängige Operationen und _msgSender()-abhängige Buchhaltungen immer dieselbe Adresse referenzieren.

Goose Finance Vorfall

Kurze Zusammenfassung

Am 15. März 2026 wurde Goose Finance, ein Yield-Farming-Protokoll auf der BNB Chain, für etwa 8 Tsd. USD ausgenutzt. Die Ursache war ein Fehler in der Aktienpreisordnung in StrategyGooseEgg: deposit() prägt Aktien, bevor die geernteten Erträge in die Buchhaltung verrechnet werden, sodass der Nenner für die Aktienbewertung die Erträge ausschließt und niedriger ist als der tatsächliche Wert. Das bedeutet, dass Einleger mehr Aktien erhalten, als sie sollten. Wenn withdraw() aufgerufen wird, löst dies eine Ertragsernte aus, die die gesamten Vermögenswerte erhöht, wodurch jede Aktie mehr wert wird. Durch das Schleifen von Einzahlung und Auszahlung in einer einzigen Transaktion prägte der Angreifer wiederholt überbewertete Aktien und löste sie zum korrigierten (höheren) Wert ein, wobei die Differenz als Gewinn abgehoben wurde.

Hintergrund

Goose Finance ist ein Yield-Farming-Protokoll auf der BNB Chain, bei dem Benutzergelder von einer Kasse in eine Strategie fließen, die Assets im MasterChef staket, um EGG-Prämien zu verdienen.

Die für diesen Vorfall relevanten Komponenten sind:

• VaultChef (0x3f64...): Verfolgt Benutzerpositionen und leitet Kapital an StrategyGooseEgg weiter.

• StrategyGooseEgg (0x0980...): Verwaltet die buchhalterische Erfassung auf Strategieebene mit sharesTotal und wantLockedTotal.

• MasterChef (0xe70e...): Empfängt gestakte Assets und zahlt EGG-Prämien.

• WrappedEgg (0xb815...): Wickelt EGG 1:1 in WEGG zum Staken ein.

Betrieblich werden Einzahlungen von VaultChef an StrategyGooseEgg geleitet und dann in MasterChef gestaket. Auszahlungen werden von VaultChef initiiert und von der Strategie ausgeführt.

Eine wichtige buchhalterische Erwartung ist, dass die Aktienbewertung die gesamten Strategie-Assets zum Zeitpunkt der Bewertung widerspiegeln sollte (gestaket plus im Umlauf befindliche Erträge, die bereits von der Strategie gehalten werden). In StrategyGooseEgg prägt deposit() jedoch Aktien, bevor _farm() im Umlauf befindliche Erträge in wantLockedTotal verrechnet. Dies ist die Grundlage für die nachfolgend analysierte Schwachstelle.

Schwachstellenanalyse

Die Ursache ist eine buchhalterische De-Synchronisation in StrategyGooseEgg (0x0980...b26b) zwischen der Ertragsernte und der Aktienbewertung.

In StrategyGooseEgg verwendet die Aktienbewertung wantLockedTotal als Nenner: shares = deposit * sharesTotal / wantLockedTotal. Damit dies fair ist, muss wantLockedTotal alle Assets widerspiegeln, die die Strategie tatsächlich hält, einschließlich aller im Umlauf befindlichen EGG-Erträge, die sich im Vertrag befinden. deposit() prägt jedoch Aktien, bevor _farm() im Umlauf befindliche Erträge in wantLockedTotal verrechnet. Das bedeutet, der Nenner schließt nicht erfasste Erträge aus und ist niedriger als die tatsächlichen Gesamtvermögenswerte, was dazu führt, dass der Einleger mehr Aktien erhält, als er sollte.

Darüber hinaus ruft withdraw() MasterChef.withdraw() auf, was den gestakten Principal plus ausstehende EGG-Erträge an die Strategie zurückgibt. Die Buchhaltung der Strategie zieht nur den angeforderten _wantAmt von wantLockedTotal ab, sodass die geernteten Erträge im Guthaben der Strategie verbleiben, ohne in wantLockedTotal reflektiert zu werden. Dies vergrößert die Lücke zwischen den tatsächlich gehaltenen Vermögenswerten und dem aufgezeichneten wantLockedTotal, wodurch jede nachfolgende deposit()-Aktienbewertung noch ungenauer wird.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x86efdf...ce316223.

• Schritt 1: Der Angreifer hat per Flash-Leihe EGG aus zwei Pancake-Paaren geliehen.

• Schritt 2: Erste Einzahlung in VaultChef/StrategyGooseEgg (10.170.000e18 EGG).

• Schritt 3: Erste Auszahlung (12.593.884e18 EGG) erntet Erträge von MasterChef; 359.561e18 EGG werden an StrategyGooseEgg übertragen und bleiben als im Umlauf befindlicher/nicht erfasster Wert (R > 0).

• Schritt 4: Zweite Einzahlung nutzt das abgehobene Kapital wieder (12.593.884e18 EGG). Aktien werden vor der Verrechnung des im Umlauf befindlichen Wertes bewertet, daher ist dies der Schritt der Überprägung.

• Schritt 5: Zweite Auszahlung (12.826.027e18 EGG) realisiert den Gewinn aus den überprägten Aktien (d. h. 232.143 EGG über dem Einzahlungseingang aus Schritt 4).

• Schritt 6: Der Angreifer zahlt die Flash-Swaps zurück und behält die Netto-Differenz.

Schlussfolgerung

Der Exploit stammt aus einem Fehler in der Aktienpreisordnung in StrategyGooseEgg: deposit() prägt Aktien, bevor _farm() wantLockedTotal aktualisiert, während withdraw() Erträge von MasterChef ernten kann, die vorübergehend im Umlauf sind und nicht erfasst werden. Dies ermöglicht es Einzahlungen, gegen einen veralteten Nenner zu prägen und später gegen aktualisierte Vermögenswerte abzuheben.

Um ähnliche Risiken zukünftig zu reduzieren:

• Verrechnen Sie Erträge und aktualisieren Sie die Buchhaltung vor allen Aktienpräge- und Aktienverbrennungsberechnungen.

• Bewerten Sie Aktien anhand von totalAssets (gestaket + im Umlauf) zum exakten Zeitpunkt der Berechnung.

• Fügen Sie Invariante-Tests für shares_minted <= D * S / (A + R) unter Bedingungen mit nicht-null Erträgen hinzu.

Über BlockSec

BlockSec ist ein Anbieter von Full-Stack-Blockchain-Sicherheit und Krypto-Compliance. 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, rechtswidrige Gelder zu verfolgen und AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen zu erfüllen.

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

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

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

• 🔗 BlockSec Audit Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance