Wöchentliche Web3-Sicherheitsvorfälle | 23. Feb. – 1. März 2026

Im vergangenen Zeitraum (23.02.2026 - 01.03.2026) hat BlockSec sieben Angriffsereignisse erkannt und analysiert, mit geschätzten Gesamtschäden von ca. 13 Mio. USD. Die folgende Tabelle fasst diese Ereignisse zusammen, detaillierte Analysen für jeden Fall finden Sie in den folgenden Unterabschnitten.

1. 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 USD aus dem LAXO-USDT-Paar führte. Die Grundursache war ein fehlerhafter Burn-Mechanismus, der beim direkten Transfer von LAXO an das PancakeSwap-Paar ausgelöst 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-swap()-Funktion des Paares auf, die Paar-Token verbrannte und sync() aufrief, was den Preis aufblähte. Der Angreifer tauschte dann zurück zu USDT für Profit.

Hintergrund

Der LAXO-Token implementiert einen Burn-Mechanismus. Wenn der Empfänger eines Transfers die USDT-LAXO PancakeSwap-Paaradresse ist, behandelt der Token dies als Verkauf: Er verbrennt eine entsprechende Menge von Tokens 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 Grundursache des Vorfalls war ein fehlerhafter Burn-Mechanismus im LAXO-Token. Insbesondere löst der direkte Transfer von LAXO an das Paar den Burn aus, wodurch LAXO aus dem Paar entfernt und sein Preis aufgebläht wird. Als Ergebnis kann ein Angreifer dies ausnutzen, um Gewinne durch Preismanipulationsangriffe zu erzielen.

Angriffsanalyse

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

1. Der Angreifer tätigte einen Flashloan über 350.000e18 USDT von PancakeSwap V3.

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

3. Der Angreifer transferierte alle 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 von LAXO gegen ~487.500e18 USDT basierend auf dem manipulierten Preis.

5. Der Angreifer beglich den Flashloan und behielt die restlichen USDT als Gewinn.

Schlussfolgerung

Die Grundursache dieses Vorfalls liegt im fehlerhaften Burn-Mechanismus von LAXO, der es Angreifern ermöglicht, USDT aus dem Pool durch Preismanipulationsangriffe abzuziehen. Infolgedessen entstanden dem Vorfall Gesamtschäden von etwa 137,3 Tsd. USD. Um solche Probleme zu mildern, muss das Projekt umfassende Tests seines Burn-Mechanismus durchführen, um potenzielle Preismanipulationsangriffe zu vermeiden.

2. YieldBloxDAO-Vorfall

Kurze Zusammenfassung

Am 22. Februar 2026 wurde ein von YieldBlox DAO betriebener Kreditpool auf Stellar's Blend V2 ausgenutzt, was zu Verlusten von über 10 Millionen USD führte [1]. Der Vorfall wurde durch eine Fehlkonfiguration des Pool-Betreibers (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 ermöglichen Benutzern das Leihen und Verleihen einer Reihe unterstützter Assets. Insbesondere erlaubt der betroffene Pool dem Benutzer, XLM und USDC gegen USTRY als Sicherheit zu leihen. Darüber hinaus gibt der Pool-Ersteller bei der Erstellung den Reflector-Orakel [2] als Orakel-Anbieter an. Der Preis von USTRY, der vom Reflector-Orakel bereitgestellt wird, aktualisiert sich alle fünf Minuten basierend auf dem USTRY/USDC-Markt auf dem Stellar DEX (d. h. SDEX) [3].

Schwachstellenanalyse

Die Grundursache war die Preismanipulation auf dem illiquiden USTRY/USDC-Markt des SDEX, was zu einer fehlerhaften Aktualisierung des USTRY-Preises im Reflector-Orakel führte. Insbesondere war es dem Angreifer aufgrund der extrem geringen Liquidität im USTRY/USDC-Markt möglich, normale Orders zu verbrauchen und anormale Orders zu platzieren, um den USTRY-Preis um das Hundertfache aufzublähen. Dieser aufgeblähte USTRY-Preis wurde dann an das Reflector-Orakel weitergegeben, was es dem Angreifer ermöglichte, alle Assets (d. h. XLM und USDC) aus dem betroffenen Pool zu leihen, indem er überbewerteten USTRY als Sicherheit hinterlegte.

Angriffsanalyse

1. (Tx 1, 2) Der Angreifer manipulierte den USTRY-Preis auf dem SDEX und trieb ihn von 1,06 USD auf etwa 107 USD. Da der USTRY/USDC-Markt auf dem SDEX extrem illiquide war, verbrauchte der Angreifer alle normalen Orders und platzierte dann anormale Orders, was den Marktpreis stark nach oben trieb.

2. (Tx 3) Das Reflector-Orakel zog den manipulierten Preis vom SDEX und aktualisierte entsprechend seinen Preis-Feed.

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) Zuletzt brückte der Angreifer die abgezogenen Assets auf mehrere Ketten, darunter Base, BSC und Ethereum.

Die folgenden Tabellen fassen wichtige 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 Besicherungsbewertung hängt von einem Preis ab, der anfällig für Manipulation ist. Dieser Vorfall erinnert daran, dass die Preisabhängigkeiten für Kreditprotokolle sorgfältig ausgewählt und überwacht werden müssen.

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

3. STO-Vorfall

Kurze Zusammenfassung

Am 23. Februar 2026 wurde ein STO-WBNB-Pool auf PancakeSwap in der BNB Smart Chain ausgeraubt, was zu Verlusten von etwa 16.100 USD führte. Die Grundursache war ein fehlerhafter Burn-Mechanismus im STO-Token. Insbesondere wurde beim Verkauf von STO-Tokens im Pool der Burn-Mechanismus ausgelöst, wodurch STO-Tokens aus dem Pool verbrannt und der Preis des Tokens aufgebläht wurde. Als Ergebnis nutzte der Angreifer diese Schwachstelle aus, um WBNB-Tokens 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 (sellEnabled == true) des STO-Tokens aktiviert ist und pendingBurnFromSell > 0. Wenn ein Benutzer STO-Tokens verkauft, verbrennt der Mechanismus STO-Tokens aus dem Pool. Insbesondere werden 94 % der im vorherigen Transaktionsschritt verkauften STO-Tokens während des Brennvorgangs verbrannt.

Schwachstellenanalyse

Die Grundursache des Vorfalls ist der fehlerhafte Burn-Mechanismus im STO-Token. Insbesondere entfernt der Burn-Mechanismus beim Verkauf von STO-Tokens durch den Benutzer eine bestimmte Menge von STO-Tokens aus dem Pool und ruft gleichzeitig die sync()-Funktion des Paarvertrags auf, um die Reserven zu aktualisieren. Dieser Burn-Mechanismus bläht den Preis des STO-Tokens im Pool auf. Als Ergebnis können Angreifer von diesem Mechanismus profitieren, indem sie einen Preismanipulationsangriff durchführen.

Angriffsanalyse

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

1. Der Angreifer lieh sich 360.894e18 WBNB über den Flashloan.

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, was den Burn-Mechanismus auslöste, um die Reserven des Paares zu manipulieren (d. h. den Preis des STO-Tokens erhöhte), während gleichzeitig die Menge der in der nächsten Transaktion zu verbrennenden STO-Tokens auf 173.391e18 gesetzt wurde.

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

6. Der Angreifer wiederholte die Schritte 4 und 5, um das WBNB des Pools abzuziehen.

7. Der Angreifer beglich den Flashloan und realisierte einen Gewinn von 26e18 WBNB.

Schlussfolgerung

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

4. 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 USD führte. Die Grundursache war eine fehlerhafte Geschäftslogik im Staking-Vertrag des HedgePay-Protokolls. Insbesondere erlaubte die Funktion forceExit() des anfälligen Staking-Vertrags (d. h. 0xBe189fe9f84cA531CD979630E1f14757b88dD80d) Benutzern, ihre gestakten Assets abzuziehen, ohne ihre gestakten Salden zu aktualisieren. Als Ergebnis konnte der Angreifer die Funktion forceExit() wiederholt aufrufen, um die HPAY-Tokens des Vertrags abzuziehen.

Hintergrund

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

Schwachstellenanalyse

Die Grundursache des Vorfalls ist fehlerhafte Geschäftslogik in der Funktion forceExit(). Insbesondere wird beim Staken von HPAY-Tokens über die Funktion stake() der gestakte Betrag des Benutzers (d. h. _balances[msg.sender]) entsprechend aktualisiert. Wenn Benutzer jedoch ihre gestakten HPAY-Tokens über die Funktion forceExit() abziehen, versäumt es der Vertrag, _balances[msg.sender] zu aktualisieren. Als Ergebnis kann der Angreifer die HPAY-Tokens 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 Flashloan. Im Flashloan-Callback:

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

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

2. Der Angreifer beglich den Flashloan und tauschte 57.389.615e18 HPAY gegen 26e18 WBNB (d. h. realisierte einen Gewinn von 26e18 WBNB).

Schlussfolgerung

Die Grundursache dieses Vorfalls war, dass die Funktion forceExit() den _balances[msg.sender] des Benutzers nicht aktualisierte, was es dem Angreifer ermöglichte, die HPAY-Tokens 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 aufrechterhalten werden.

5. Ploutos-Vorfall

Kurze Zusammenfassung

Am 26. Februar 2026 erlitt ein Pool des Ploutos-Protokolls auf Ethereum Verluste von etwa 390.000 USD aufgrund einer Orakel-Fehlkonfiguration. Insbesondere war das Orakel fälschlicherweise so konfiguriert, dass es einen BTC/USD Chainlink-Preis-Feed für USDC verwendete. Als Ergebnis 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 bereitgestellt ist. Der Vorfall wurde durch eine falsche Orakelkonfiguration im Kreditpool (0xD060...F945D2) verursacht.

In Block 24538896 wurde das Preis-Orakel für USDC falsch konfiguriert, sodass es auf den BTC/USD Chainlink-Feed anstatt auf einen USDC/USD-Feed verwies. Im folgenden Block (24538897) entdeckte der Angreifer die Fehlkonfiguration und führte den Exploit aus. Als Ergebnis 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 die Orakelquelle von USDC in Tx 0xcfedf6...bd193ab6 falsch auf den Chainlink BTC/USDC-Preis-Feed gesetzt haben.

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

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

Schlussfolgerung

Die Grundursache des Vorfalls war eine Orakel-Fehlkonfiguration, die zu Verlusten von etwa 390.000 USD 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

6. FOOMCASH-Vorfall

Kurze Zusammenfassung

Am 26. Februar 2026 wurde das FOOMCASH-Protokoll aufgrund einer anfälligen Groth16-Beweisprüfung [1] ausgenutzt, was zu Gesamtschäden von über 2,26 Mio. USD führte.

Hintergrund

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

Schwachstellenanalyse

Die Grundursache 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_{2}G\_\{2\}$), was es dem Angreifer ermöglichte, gültige Beweise mit beliebigen Eingaben zu fälschen. Als Ergebnis umging der Angreifer die Groth16-Beweisprüfung 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 Beweis und bösartige Eingaben zu konstruieren. In der Fallback-Logik des bösartigen Vertrags:

1. Er konstruierte einen gültigen Beweis.

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

a. Bei der Ausführung der Funktion collect() wurde die Beweisprüfung (d. h. WithdrawG16Verifier.verifyProof()) umgangen und die Assets (d. h. FOOM-Tokens) wurden an den Angreifer übertragen.

3. Er wiederholte die Schritte 1-2 30 Mal und zog insgesamt 19.695.576.757.802e18 FOOM-Tokens ab.

Schlussfolgerung

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

Referenzen

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

7. Unbekanntes Ereignis

Kurze Zusammenfassung

Am 27. Februar 2026 wurde ein unbekannter Vertrag auf der BNB Smart Chain ausgenutzt [1], was zu Verlusten von etwa 180.000 USD führte. Die Grundursache dieses Vorfalls war eine unsachgemäße Eingabevalidierung. Insbesondere führte die Funktion _verifySignatures() des betroffenen Vertrags keine Prüfung auf leere Listen durch, wodurch der Angreifer die Signaturprüfung umgehen konnte, ohne Signaturen und Unterzeichner bereitzustellen. Als Ergebnis nutzte der Angreifer diese Schwachstelle aus, um alle USDT-Tokens im betroffenen Vertrag abzuziehen.

Schwachstellenanalyse

Die Grundursache dieses Vorfalls ist eine unsachgemäße Validierung im Signaturprüfungsablauf. Insbesondere prüft die Funktion _verifySignatures() nur, ob allSigners.length == signatures.length, und verlangt nicht, dass eines der Arrays nicht leer ist. Als Ergebnis kann der Angreifer, wenn beide Arrays leer sind, die Signaturprü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 der Ausführung:

a. Der bösartige Vertrag rief die Funktion poolWithdraw() mit leeren Eingaben allSigners und signatures auf und umging damit die beabsichtigte Signaturprüfungslogik.

b. Nachdem die Signaturprüfungslogik umgangen wurde, überwies der betroffene Vertrag USDT an den Angreifer.

Schlussfolgerung

Die Grundursache dieses Vorfalls war eine unsachgemäße Eingabevalidierung, die zu Verlusten von etwa 180.000 USD führte. Der Vorfall unterstreicht die Bedeutung grundlegender Grenzprüfungen wie Nicht-Leer-Prüfungen für Eingaben.

Referenzen

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

Über BlockSec

BlockSec ist ein Anbieter von umfassenden Blockchain-Sicherheits- und Krypto-Compliance-Lösungen. Wir entwickeln Produkte und Dienstleistungen, die Kunden bei der Durchführung von Code-Audits (einschließlich Smart Contracts, Blockchain und Wallets), der Echtzeit-Abwehr von Angriffen, der Analyse von Vorfällen, der Rückverfolgung illegaler Gelder und der Erfüllung von AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg unterstützen.

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 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