Wöchentlicher Web3 Sicherheitsvorfall-Rückblick | 23. Feb. – 1. Mrz. 2026

Im Laufe der letzten Woche (23.02.2026 - 01.03.2026) hat BlockSec sieben Angriffsvorfälle mit geschätzten Gesamtschäden von ca. 13 Millionen US-Dollar erkannt und analysiert. Die folgende Tabelle fasst diese Vorfälle zusammen, und detaillierte Analysen für jeden Fall finden Sie in den folgenden Unterabschnitten.

LAXO-Vorfall

Kurze Zusammenfassung

Am 22. Februar 2026 wurde der ERC20-Token LAXO auf der BNB Smart Chain ausgenutzt, was zu Verlusten von etwa 137.320 US-Dollar aus dem LAXO-USDT-Paar führte. Die Hauptursache war ein fehlerhafter Burn-Mechanismus, der ausgelöst wurde, wenn LAXO direkt an das PancakeSwap-Paar übertragen wurde. Da der Router auf der Whitelist stand und die Burn-Logik in transfer() nicht auslöste, umging der Angreifer dies: Er sendete LAXO an das Paar und rief dann die Low-Level-Funktion swap() des Paares auf, die Paar-Token verbrannte und sync() aufrief, wodurch der Preis in die Höhe getrieben wurde. Der Angreifer tauschte dann zur Gewinnmitnahme zurück in USDT.

Hintergrund

Der LAXO-Token implementiert einen Burn-Mechanismus. Wenn der Empfänger einer Überweisung die USDT–LAXO PancakeSwap-Paaradresse ist, behandelt der Token dies als Verkauf: Er verbrennt eine entsprechende Menge an Token aus dem Paar und ruft dann sync() auf, um die Reserven des Paares zu aktualisieren. Zusätzlich implementiert der LAXO-Token eine Whitelist (_isExcludedFromFee), um bestimmte Adressen (z. B. Swap-Router) vom Burn-Mechanismus und Gebühren auszunehmen.

Schwachstellenanalyse

Die Hauptursache des Vorfalls war ein fehlerhafter Burn-Mechanismus im LAXO-Token. Insbesondere löst die Übertragung von LAXO direkt an das Paar den Burn aus, wodurch LAXO aus dem Paar entfernt und sein Preis in die Höhe getrieben wird. Infolgedessen kann ein Angreifer dies ausnutzen, um Gewinne durch Preismanipulationsangriffe zu erzielen.

Angriffsanalyse

Die Angriffsanalyse basiert auf der Transaktion 0xd58f3ef6...d98ac7d3.

1. Der Angreifer lieh sich 350.000e18 USDT von PancakeSwap V3.

2. Der Angreifer tauschte USDT gegen LAXO über den PancakeSwap Router. Um Handelsbeschränkungen (buyEnabled = false) und Gebührenlogik zu umgehen, erstellte der Angreifer ein BNB–LAXO V2-Paar und leitete Trades darüber.

3. Der Angreifer übertrug den gesamten gehaltenen LAXO direkt an das USDT–LAXO-Paar. Dies reduzierte die LAXO-Reserve im Pool, während die USDT-Reserve nahezu unverändert blieb, was den Preis von LAXO im USDT–LAXO-Paar dramatisch erhöhte.

4. Der Angreifer tauschte burnAmount LAXO für ~487.500e18 USDT auf Basis des manipulierten Preises.

5. Der Angreifer beglich den Flash-Loan und behielt die verbleibenden USDT als Gewinn.

Schlussfolgerung

Die Hauptursache dieses Vorfalls liegt im fehlerhaften Burn-Mechanismus von LAXO, der es Angreifern ermöglicht, USDT über Preismanipulationsangriffe aus dem Pool abzuziehen. Infolgedessen beliefen sich die Gesamtschäden des Vorfalls auf etwa 137,3 Tausend US-Dollar. Um solche Probleme zu mildern, muss das Projekt umfassende Tests seines Burn-Mechanismus durchführen, um potenzielle Preismanipulationsangriffe zu vermeiden.

YieldBloxDAO-Vorfall

Kurze Zusammenfassung

Am 22. Februar 2026 wurde ein Kreditpool, der von der YieldBlox DAO auf Stellar's Blend V2 betrieben wurde, ausgenutzt, was zu Verlusten von über 10 Millionen US-Dollar führte [1]. Der Vorfall wurde durch eine Fehlkonfiguration durch den Poolbetreiber (YieldBlox DAO) verursacht, nicht durch eine Schwachstelle in den Smart Contracts.

Insbesondere manipulierte der Angreifer den USTRY/USDC-Markt auf SDEX. Der vom Pool konfigurierte Reflector-Orakelpfad akzeptierte den manipulierten Preis, der USTRY als Sicherheit überbewertete und es dem Angreifer ermöglichte, Pool-Assets, einschließlich USDC und XLM, abzuziehen.

Hintergrund

Auf der Stellar-Blockchain ist Blend V2 ein Liquiditätsprotokoll, das es Benutzern ermöglicht, isolierte Kreditpools zu erstellen. Diese Pools erleichtern die Verleihung und Aufnahme von Krediten zwischen Benutzern für eine Reihe unterstützter Assets. Insbesondere ermöglicht der im Vorfall betroffene Pool den Benutzern, XLM und USDC gegen USTRY als Sicherheit zu leihen. Darüber hinaus gibt der Pool-Ersteller das Reflector-Orakel [2] bei der Erstellung als Orakel-Provider an. Der Preis von USTRY, der vom Reflector-Orakel bereitgestellt wird, aktualisiert sich alle fünf Minuten basierend auf dem USTRY/USDC-Markt auf der Stellar DEX (d. h. SDEX) [3].

Schwachstellenanalyse

Die Hauptursache war die Preismaipulation auf dem illiquiden USTRY/USDC-Markt von SDEX, die zu einer fehlerhaften Aktualisierung des USTRY-Preises im Reflector-Orakel führte. Insbesondere konnte der Angreifer aufgrund der extrem geringen Liquidität auf dem USTRY/USDC-Markt normale Orders verbrauchen und abnormale Orders platzieren, um den USTRY-Preis um das Hundertfache zu erhöhen. Dieser erhöhte USTRY-Preis wurde an das Reflector-Orakel weitergegeben, wodurch der Angreifer alle Assets (d. h. XLM und USDC) aus dem betroffenen Pool leihen konnte, indem er überbewerteten USTRY als Sicherheit hinterlegte.

Angriffsanalyse

1. (Tx 1, 2) Der Angreifer manipulierte den USTRY-Preis auf SDEX und trieb ihn von 1,06 US-Dollar auf etwa 107 US-Dollar. Da der USTRY/USDC-Markt auf SDEX extrem flach war, verbrauchte der Angreifer alle normalen Orders und platzierte dann abnormale Orders, wodurch der Marktpreis stark nach oben getrieben wurde.
2. (Tx 3) Das Reflector-Orakel zog den manipulierten Preis von SDEX ab und aktualisierte seinen Preis-Feed entsprechend.
3. (Tx 4, 5) Der Angreifer lieh sich 1.000.196e7 USDC, indem er 12.881e7 USTRY als Sicherheit hinterlegte.
4. (Tx 6, 7) Der Angreifer lieh sich 6.124.927.810e7 XLM, indem er 14.987.610e7 USTRY als Sicherheit hinterlegte.
5. (Txs 8, 9, 10) Schließlich brückte der Angreifer die abgezogenen Assets auf mehrere Ketten, darunter Base, BSC und Ethereum.

Die folgenden Tabellen fassen die wichtigsten Exploit-Transaktionen und die beteiligten Adressen zusammen.

Schlussfolgerung

Obwohl der YieldBloxDAO-Vorfall zu erheblichen Verlusten führte, ist das zugrunde liegende Problem nicht komplex: Die Bewertung der Sicherheiten hängt von einem Preis ab, der anfällig für Manipulationen ist. Dieser Vorfall dient als Erinnerung daran, dass die Preisabhängigkeit für Kreditprotokolle sorgfältig ausgewählt und überwacht werden muss.

Referenzen

[1] https://blocksec.com/blog/yieldblox-dao-incident-on-stellar-oracle-misconfiguration-enabled-a-10m-drain

[2] https://reflector.network/

[3] USTRY/USDC Market on the SDEX

STO-Vorfall

Kurze Zusammenfassung

Am 23. Februar 2026 wurde ein STO-WBNB-Pool auf PancakeSwap in der BNB Smart Chain geleert, was zu Verlusten von etwa 16.100 US-Dollar führte. Die Hauptursache war ein fehlerhafter Burn-Mechanismus im STO-Token. Insbesondere wurde beim Verkauf von STO-Token im Pool der Burn-Mechanismus ausgelöst, der STO-Token aus dem Pool verbrannte und den Preis des Tokens in die Höhe trieb. Infolgedessen nutzte der Angreifer diese Schwachstelle aus, um WBNB-Token aus dem Pool abzuziehen.

Hintergrund

Der STO-Token führt einen Burn-Mechanismus ein, der auf den PancakeSwap V2-Pool abzielt. Dieser Mechanismus wird nur ausgelöst, wenn die Verkaufsfunktion des STO-Tokens aktiviert ist (d. h. sellEnabled == true) und pendingBurnFromSell > 0. Wenn ein Benutzer STO-Token verkauft, verbrennt der Mechanismus STO-Token aus dem Pool. Insbesondere werden 94% der im vorherigen Handel verkauften STO-Token während des Verbrennungsprozesses verbrannt.

Schwachstellenanalyse

Die Hauptursache des Vorfalls ist der fehlerhafte Burn-Mechanismus im STO-Token. Insbesondere entfernt der Burn-Mechanismus beim Verkauf von STO-Token durch einen Benutzer eine bestimmte Menge an STO-Token aus dem Pool und ruft gleichzeitig die sync()-Funktion des Paarvertrags auf, um die Reserven zu aktualisieren. Dieser Burn-Mechanismus treibt den Preis des STO-Tokens im Pool in die Höhe. Infolgedessen konnten Angreifer von diesem Mechanismus profitieren, indem sie einen Preismanipulationsangriff durchführten.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x8ba17bea...5a54020c.

1. Der Angreifer lieh sich über den Flash-Loan 360.894e18 WBNB.

2. Der Angreifer rief die Funktion initializeLiquidity() auf, um die Kauf- und Verkaufsfunktionalität des STO-Tokens zu aktivieren.

3. Der Angreifer tauschte 360.894e18 WBNB gegen 7.848.832e18 STO.

4. Der Angreifer rief die Funktion transfer() auf und löste damit den Burn-Mechanismus aus, um die Reserven des Paares zu manipulieren (d. h. den Preis des STO-Tokens zu erhöhen), während er gleichzeitig die Menge der in der nächsten Transaktion zu verbrennenden STO-Token auf 173.391e18 festlegte.

5. Der Angreifer rief die Funktion swap() auf, um STO gegen WBNB zu tauschen. Dieser Schritt ermöglichte es dem Angreifer, Gewinne auf Basis des manipulierten Preises zu erzielen.

6. Der Angreifer wiederholte die Schritte 4 und 5, um das WBNB aus dem Pool abzuziehen.

7. Der Angreifer beglich den Flash-Loan und erzielte einen Gewinn von 26e18 WBNB.

Schlussfolgerung

Die Hauptursache dieses Vorfalls liegt im fehlerhaften Burn-Mechanismus von STO, der es Angreifern ermöglicht, WBNB aus dem Pool abzuziehen. Um solche Probleme zu vermeiden, muss das Projekt ordnungsgemäße Zugriffskontrollen innerhalb des Systems implementieren und umfassende Tests seines Burn-Mechanismus durchführen, um potenzielle Preismanipulationsangriffe zu vermeiden.

HedgePay-Vorfall

Kurze Zusammenfassung

Am 25. Februar 2026 wurde das HedgePay-Protokoll auf der BNB Smart Chain ausgenutzt, was zu Verlusten von etwa 15.700 US-Dollar führte. Die Hauptursache war eine fehlerhafte Geschäftslogik im Staking-Vertrag des HedgePay-Protokolls. Insbesondere ermöglichte die Funktion forceExit() des anfälligen Staking-Vertrags (d. h. 0xBe189fe9f84cA531CD979630E1f14757b88dD80d) Benutzern, ihre gestakten Assets abzuziehen, ohne ihre gestakten Guthaben zu aktualisieren. Infolgedessen konnte der Angreifer die Funktion forceExit() wiederholt aufrufen, um die HPAY-Token des Vertrags abzuziehen.

Hintergrund

Das HedgePay-Protokoll ist ein Staking-Protokoll, das es Benutzern ermöglicht, Belohnungen durch das Staken von HPAY-Token zu verdienen. Die Funktion forceExit() ermöglicht es Benutzern, ihre gestakten Assets abzuziehen.

Schwachstellenanalyse

Die Hauptursache des Vorfalls ist eine fehlerhafte Geschäftslogik in der Funktion forceExit(). Insbesondere, wenn Benutzer HPAY-Token über die Funktion stake() staken, wird ihr gestakter Betrag (d. h. _balances[msg.sender]) entsprechend aktualisiert. Wenn Benutzer jedoch ihre gestakten HPAY-Token über die Funktion forceExit() abziehen, versäumt es der Vertrag, _balances[msg.sender] zu aktualisieren. Infolgedessen kann der Angreifer HPAY-Token im Staking-Vertrag abziehen, indem er die Funktion forceExit() wiederholt aufruft.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x5f2ea6cb...46ed137f.

1. Der Angreifer lieh sich 1.247.859e18 HPAY über den Flash-Loan. In der Flashloan-Callback-Funktion:

   a. Der Angreifer stakte 1.197.944e18 HPAY über die Funktion stake().

   b. Der Angreifer rief wiederholt die Funktion forceExit() auf, um die HPAY-Token des Vertrags abzuziehen.

2. Der Angreifer beglich den Flash-Loan und tauschte 57.389.615e18 HPAY gegen 26e18 WBNB (d. h. erzielte einen Gewinn von 26e18 WBNB).

Schlussfolgerung

Die Hauptursache dieses Vorfalls war, dass die Funktion forceExit() den _balances[msg.sender] des Benutzers nicht aktualisierte, was es dem Angreifer ermöglichte, HPAY-Token im Staking-Vertrag abzuziehen. Um solche Probleme zu vermeiden, sollte das Projekt ordnungsgemäße zustandsorientierte Tests durchführen, um sicherzustellen, dass die Zustandsinvarianten in jeder Funktion korrekt eingehalten werden.

Ploutos-Vorfall

Kurze Zusammenfassung

Am 26. Februar 2026 erlitt ein Pool des Ploutos-Protokolls auf Ethereum Verluste von etwa 390.000 US-Dollar aufgrund einer Fehlkonfiguration des Orakels. Insbesondere war das Orakel falsch so konfiguriert, dass es einen BTC/USD Chainlink-Preis-Feed für USDC verwendete. Infolgedessen nutzte der Angreifer diese Fehlkonfiguration aus, um 187 ETH zu leihen, indem er nur 8 USDC als Sicherheit hinterlegte.

Schwachstellenanalyse

Ploutos ist ein Fork von Aave v3.0.2, der auf mehreren Netzwerken eingesetzt wird. Der Vorfall wurde durch eine falsche Orakelkonfiguration im Kreditpool (0xD060...F945D2) verursacht. Im Block 24538896 wurde das Preis-Orakel für USDC falsch so konfiguriert, dass es auf einen BTC/USD Chainlink-Feed statt auf einen USDC/USD-Feed verwies. Im folgenden Block (24538897) erkannte der Angreifer die Fehlkonfiguration und führte den Exploit durch. Infolgedessen lieh sich der Angreifer etwa 187,3 ETH als Gewinn, indem er etwa 8,88 USDC als Sicherheit hinterlegte.

Angriffsanalyse

1. Der Angreifer überwachte die Orakelkonfigurationsoperationen des Ploutos-Protokolls, die fälschlicherweise die Orakelquelle von USDC auf den Chainlink BTC/USDC Price Feed in Tx 0xcfedf6...bd193ab6 setzten.

2. Der Angreifer sandte sofort eine Transaktion (0xa17dc37e...705f8474), die es dem Angreifer ermöglichte, ~187,3 ETH durch die Hinterlegung von nur ~8,8 USDC aufgrund der Orakel-Fehlkonfiguration zu leihen.

3. Der Angreifer zahlte ~5,6 ETH an Builder-Bestechungsgelder und erzielte einen Nettogewinn von ~181,7 ETH.

Schlussfolgerung

Die Hauptursache des Vorfalls war eine Orakel-Fehlkonfiguration, die zu Verlusten von etwa 390.000 US-Dollar führte. Dies dient als Erinnerung daran, dass sensible Operationen wie die Orakelkonfiguration durch Multisig-Wallets oder Timelocks geschützt werden sollten, um potenzielle Verluste zu vermeiden.

Referenzen

[1] https://x.com/Phalcon_xyz/status/2026943448734114011

FOOMCASH-Vorfall

Kurze Zusammenfassung

Am 26. Februar 2026 wurde das FOOMCASH-Protokoll aufgrund einer anfälligen Groth16-Proof-Verifizierung [1] ausgenutzt, was zu Gesamtschäden von über 2,26 Millionen US-Dollar führte.

Hintergrund

Das FOOMCASH-Protokoll ist ein Lotterieprotokoll auf Base und Ethereum, das Groth16-Proofs für Auszahlungsüberprüfungen verwendet. Im Vertrag FoomLottery verifiziert die Funktion collect() den bereitgestellten Proof (d. h. _pA, _pB und _pC), indem sie die Funktion WithdrawG16Verifier.verifyProof() aufruft. Insbesondere erfolgt die Verifizierung basierend auf dem vertrauenswürdigen Setup (d. h. Gamma und Delta) im Vertrag WithdrawG16Verifier. Sobald der Proof als gültig verifiziert ist, fährt die Funktion collect() fort, Assets (d. h. FOOM-Token) basierend auf den Eingaben des Benutzers (z. B. _recipient und _rewardbits) zu übertragen.

Schwachstellenanalyse

Die Hauptursache des Vorfalls war ein anfälliges Groth16-Setup. Insbesondere im Vertrag WithdrawG16Verifier teilten sich die Variablen Gamma ($\gamma \backslash gamma$) und Delta ($\delta \backslash delta$) denselben Wert (d. h. $G\mathrm{\_}2G\backslash \_\{2\}$), was es dem Angreifer ermöglichte, gültige Proofs mit beliebigen Eingaben zu fälschen. Infolgedessen umging der Angreifer die Groth16-Proof-Verifizierung im Vertrag WithdrawG16Verifier und zog alle Assets im Vertrag FoomLottery mit bösartigen Eingaben ab.

Angriffsanalyse

Die Angriffsanalyse basiert auf der Transaktion 0xce204482...4e275e48.

Der Angreifer erstellte einen bösartigen Vertrag, um einen gültigen Proof und bösartige Eingaben zu konstruieren. In der Fallback-Logik des bösartigen Vertrags:

1. Es wurde ein gültiger Proof konstruiert.

2. Es rief die Funktion collect() des Vertrags FoomLottery mit einem gültigen Proof und bösartigen Eingaben (z. B. _recipient und _rewardbits) auf.

   1. Bei dem Aufruf der Funktion collect() wurde die Proof-Verifizierung (d. h. WithdrawG16Verifier.verifyProof()) umgangen und die Assets (d. h. FOOM-Token) wurden an den Angreifer übertragen.

3. Es wiederholte die Schritte 1-2 für 30 Mal und zog insgesamt 19.695.576.757.802e18 FOOM-Token ab.

Schlussfolgerung

Die Hauptursache des Vorfalls war ein anfälliges Groth16-Verifizierungssetup, das zu Verlusten von etwa 2,26 Millionen US-Dollar führte. Dies unterstreicht, dass komplexe kryptografische Setups vor der Bereitstellung gründlich überprüft und auditiert werden müssen.

Referenzen

[1] https://x.com/Phalcon_xyz/status/2026941738141778394

Unbekannter Vorfall

Kurze Zusammenfassung

Am 27. Februar 2026 wurde ein unbekannter Vertrag auf der BNB Smart Chain ausgenutzt [1], was zu Verlusten von etwa 180.000 US-Dollar führte. Die Hauptursache dieses Vorfalls war eine unzureichende Eingabevalidierung. Insbesondere versäumte es die Funktion _verifySignatures() des betroffenen Vertrags, eine Prüfung auf leere Listen durchzuführen, wodurch der Angreifer die Signaturüberprüfung umgehen konnte, ohne Signaturen und Unterzeichner anzugeben. Infolgedessen nutzte der Angreifer diese Schwachstelle aus, um alle USDT-Token im betroffenen Vertrag abzuziehen.

Schwachstellenanalyse

Die Hauptursache dieses Vorfalls ist eine unzureichende Validierung im Signaturüberprüfungsprozess. Insbesondere prüft die Funktion _verifySignatures() nur, ob allSigners.length == signatures.length, und verlangt nicht, dass eines der Arrays nicht leer ist. Wenn beide Arrays leer sind, kann der Angreifer die Signaturüberprüfung umgehen und Assets abheben.

Angriffsanalyse

Die folgende Analyse basiert auf dieser Transaktion 0x91f45260...41cfd784.

1. Der Angreifer rief die Funktion 0x2d0cb456() seiner bösartigen Verträge auf. Bei dem Aufruf:

   a. Der bösartige Vertrag rief die Funktion poolWithdraw() mit leeren Eingaben allSigners und signatures auf und umging damit die vorgesehene Signaturüberprüfungslogik. b. Nachdem die Signaturüberprüfungslogik umgangen war, übertrug der betroffene Vertrag USDT an den Angreifer.

Schlussfolgerung

Die Hauptursache dieses Vorfalls war eine unzureichende Eingabevalidierung, die zu Verlusten von etwa 180.000 US-Dollar führte. Der Vorfall unterstreicht die Bedeutung grundlegender Bereichsprüfungen wie der Prüfung auf Nicht-Leerheit für Eingaben.

Referenzen

[1] https://x.com/Phalcon_xyz/status/2027328894710505581