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

In der vergangenen Woche (23.02.2026 - 01.03.2026) hat BlockSec sieben Angriffsvorfälle entdeckt und analysiert, mit einem geschätzten Gesamtschaden von ~13 Mio. $. Die folgende Tabelle fasst diese Vorfälle zusammen, detaillierte Analysen zu jedem Fall finden sich in den nachfolgenden Unterabschnitten.

1. LAXO-Vorfall

Kurzzusammenfassung

Am 22. Februar 2026 wurde der ERC20-Token LAXO auf der BNB Smart Chain ausgenutzt, was zu einem Schaden von etwa 137.320 $ aus dem LAXO-USDT-Paar führte. Die Grundursache war ein fehlerhafter Burn-Mechanismus, der aktiviert 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 diese: Er sendete LAXO an das Paar und rief anschließend die niedrig-level swap()-Funktion des Paares auf, die Paar-Token verbrannte und sync() aufrief, wodurch der Preis in die Höhe getrieben wurde. Der Angreifer tauschte dann zurück in USDT, um Gewinn zu erzielen.

Hintergrund

Der LAXO-Token implementiert einen Burn-Mechanismus. Wenn der Empfänger einer Übertragung 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 von Gebühren auszunehmen.

Schwachstellenanalyse

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

Angriffsanalyse

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

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

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

3. Der Angreifer übertrug alle gehaltenen LAXO-Token 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 an LAXO gegen ~487.500e18 USDT basierend auf dem manipulierten Preis.

5. Der Angreifer zahlte den Flashloan zurück und behielt das verbleibende USDT als Gewinn.

Fazit

Die Grundursache dieses Vorfalls liegt im fehlerhaften Burn-Mechanismus von LAXO, der es Angreifern ermöglicht, USDT aus dem Pool mittels Preismanipulationsangriffen abzuziehen. Dadurch entstand bei diesem Vorfall ein Gesamtschaden von etwa 137,3 Tsd. $. Um derartige Probleme zu vermeiden, muss das Projekt umfassende Tests seines Burn-Mechanismus durchführen, um potenzielle Preismanipulationsangriffe zu verhindern.

2. YieldBloxDAO-Vorfall

Kurzzusammenfassung

Am 22. Februar 2026 wurde ein von YieldBlox DAO betriebener Lending-Pool auf Stellars Blend V2 ausgenutzt, was zu Verlusten von über 10 Millionen $ führte [1]. Der Vorfall wurde durch eine Fehlkonfiguration des Pool-Betreibers (YieldBlox DAO) verursacht und nicht durch eine Schwachstelle in den Smart Contracts.

Konkret manipulierte der Angreifer den USTRY/USDC-Markt auf SDEX. Der konfigurierte Reflector-Oracle-Pfad des Pools akzeptierte den manipulierten Preis, der USTRY als Sicherheit überbewertete und es dem Angreifer ermöglichte, Pool-Assets, darunter USDC und XLM, abzuziehen.

Hintergrund

Auf der Stellar-Blockchain ist Blend V2 ein Liquiditätsprotokoll, das Nutzern erlaubt, isolierte Lending-Pools zu erstellen. Diese Pools ermöglichen das Verleihen und Ausleihen zwischen Nutzern für eine Reihe unterstützter Assets. Konkret erlaubt der betroffene Pool in diesem Vorfall Nutzern, XLM und USDC zu leihen, indem sie USTRY als Sicherheit hinterlegen. Zudem legt der Pool-Ersteller bei der Erstellung den Reflector-Oracle [2] als Oracle-Anbieter fest. Der von Reflector bereitgestellte Preis von USTRY wird alle fünf Minuten basierend auf dem USTRY/USDC-Markt auf dem Stellar-DEX (d. h. SDEX) [3] aktualisiert.

Schwachstellenanalyse

Die Grundursache war die Preismanipulation im illiquiden USTRY/USDC-Markt des SDEX, die zu einer anfälligen Aktualisierung des USTRY-Preises im Reflector-Oracle führte. Konkret konnte der Angreifer aufgrund der extrem geringen Liquidität im USTRY/USDC-Markt normale Orders aufbrauchen und anormale Orders platzieren, um den USTRY-Preis um das 100-Fache zu erhöhen. Dieser überhöhte USTRY-Preis wurde dann an den Reflector-Oracle weitergegeben, was dem Angreifer erlaubte, alle Assets (d. h. XLM und USDC) aus dem betroffenen Pool zu leihen, indem er überbewertetes USTRY als Sicherheit hinterlegte.

Angriffsanalyse

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

2. (Tx 3) Der Reflector-Oracle übernahm den manipulierten Preis vom SDEX und aktualisierte seinen Preisfeed 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. (Tx 8, 9, 10) Schließlich brückte der Angreifer die abgezogenen Assets auf mehrere Chains, darunter Base, BSC und Ethereum.

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

Fazit

Obwohl der YieldBloxDAO-Vorfall erhebliche Verluste verursachte, ist das zugrunde liegende Problem nicht komplex: Die Bewertung der Sicherheit hängt von einem Preis ab, der manipulationsanfällig ist. Dieser Vorfall erinnert daran, dass die Preisabhängigkeit für Lending-Protokolle 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-Markt auf dem SDEX

3. STO-Vorfall

Kurzzusammenfassung

Am 23. Februar 2026 wurde ein STO-WBNB-Pool auf PancakeSwap in der BNB Smart Chain geleert, was zu einem Schaden von etwa 16,1 Tsd. $ führte. Die Grundursache war ein fehlerhafter Burn-Mechanismus im STO-Token. Konkret wurde der Burn-Mechanismus ausgelöst, wenn Nutzer STO-Token im Pool verkauften, wodurch STO-Token aus dem Pool verbrannt und der Preis des Tokens in die Höhe getrieben wurde. Dadurch 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 Nutzer STO-Token verkauft, verbrennt der Mechanismus STO-Token aus dem Pool. Konkret werden 94 % der im vorherigen Transaktion verkauften STO-Token während des Burn-Vorgangs verbrannt.

Schwachstellenanalyse

Die Grundursache des Vorfalls ist der fehlerhafte Burn-Mechanismus im STO-Token. Konkret entfernt der Burn-Mechanismus beim Verkauf von STO-Token durch einen Nutzer eine bestimmte Menge an STO-Token aus dem Pool und ruft zudem die sync()-Funktion des Paar-Vertrags auf, um die Reserven zu aktualisieren. Dieser Burn-Mechanismus treibt den Preis des STO-Tokens im Pool in die Höhe. Dadurch könnten 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 per Flashloan 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, wodurch der Burn-Mechanismus ausgelöst wurde, um die Reserven des Paares zu manipulieren (d. h. den Preis des STO-Tokens zu erhöhen), während zugleich die Menge der in der nächsten Transaktion zu verbrennenden STO-Token auf 173.391e18 festgelegt 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 zahlte den Flashloan zurück und erzielte einen Gewinn von 26e18 WBNB.

Fazit

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

4. HedgePay-Vorfall

Kurzzusammenfassung

Am 25. Februar 2026 wurde das HedgePay-Protokoll auf der BNB Smart Chain ausgenutzt, was zu einem Schaden von etwa 15,7 Tsd. $ führte. Die Grundursache war fehlerhafte Geschäftslogik im Staking-Vertrag des HedgePay-Protokolls. Konkret erlaubte die Funktion forceExit() des anfälligen Staking-Vertrags (d. h. 0xBe189fe9f84cA531CD979630E1f14757b88dD80d) es Nutzern, ihre gestakten Assets abzuheben, ohne ihre gestakten Guthaben zu aktualisieren. Dadurch konnte der Angreifer die Funktion forceExit() wiederholt aufrufen, um die HPAY-Token des Vertrags abzuziehen.

Hintergrund

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

Schwachstellenanalyse

Die Grundursache des Vorfalls ist fehlerhafte Geschäftslogik in der Funktion forceExit(). Konkret wird, wenn Nutzer HPAY-Token über die Funktion stake() staken, deren gestakter Betrag (d. h. _balances[msg.sender]) entsprechend aktualisiert. Wenn Nutzer jedoch ihre gestakten HPAY-Token über die Funktion forceExit() abheben, versäumt es der Vertrag, _balances[msg.sender] zu aktualisieren. Dadurch 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 per Flashloan 1.247.859e18 HPAY. In der Flashloan-Callback-Funktion:

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

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

2. Der Angreifer zahlte den Flashloan zurück und tauschte 57.389.615e18 HPAY gegen 26e18 WBNB (d. h. erzielte einen Gewinn von 26e18 WBNB).

Fazit

Die Grundursache dieses Vorfalls war, dass die Funktion forceExit() das _balances[msg.sender] des Nutzers nicht aktualisierte, wodurch der Angreifer HPAY-Token im Staking-Vertrag abziehen konnte. Um derartige Probleme zu verhindern, sollte das Projekt angemessene zustandsorientierte Tests durchführen, um sicherzustellen, dass die Zustandsinvarianten in jeder Funktion korrekt eingehalten werden.

5. Ploutos-Vorfall

Kurzzusammenfassung

Am 26. Februar 2026 erlitt ein Pool des Ploutos-Protokolls auf Ethereum aufgrund einer Oracle-Fehlkonfiguration einen Schaden von etwa 390.000 $. Konkret wurde der Oracle fälschlicherweise so konfiguriert, dass er einen BTC/USD-Chainlink-Preisfeed für USDC verwendete. Dadurch nutzte der Angreifer diese Fehlkonfiguration aus, um 187 ETH zu leihen, indem er lediglich 8 USDC als Sicherheit hinterlegte.

Schwachstellenanalyse

Ploutos ist ein Fork von Aave v3.0.2, der auf mehreren Netzwerken bereitgestellt wird. Der Vorfall wurde durch eine fehlerhafte Oracle-Konfiguration im Lending-Pool (0xD060...F945D2) verursacht.

Im Block 24538896 wurde der Preis-Oracle für USDC fälschlicherweise so konfiguriert, dass er auf einen BTC/USD-Chainlink-Feed anstatt auf einen USDC/USD-Feed verweist. Im darauffolgenden Block (24538897) entdeckte der Angreifer die Fehlkonfiguration und führte den Exploit aus. Dadurch lieh sich der Angreifer als Gewinn etwa 187,3 ETH, indem er etwa 8,88 USDC als Sicherheit hinterlegte.

Angriffsanalyse

1. Der Angreifer überwachte die Oracle-Konfigurationsoperationen des Ploutos-Protokolls, die die Oracle-Quelle von USDC fälschlicherweise auf den Chainlink-BTC/USDC-Preisfeed in Tx 0xcfedf6...bd193ab6 festlegten.

2. Der Angreifer sendete sofort eine Transaktion (0xa17dc37e...705f8474), die es ihm ermöglichte, aufgrund der Oracle-Fehlkonfiguration ~187,3 ETH zu leihen, indem er lediglich ~8,8 USDC als Sicherheit hinterlegte.

3. Der Angreifer zahlte ~5,6 ETH an Builder-Bestechungen und erzielte netto einen Gewinn von ~181,7 ETH.

Fazit

Die Grundursache des Vorfalls war eine Oracle-Fehlkonfiguration, die zu einem Schaden von etwa 390.000 $ führte. Dies erinnert daran, dass sensible Operationen wie die Oracle-Konfiguration 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

Kurzzusammenfassung

Am 26. Februar 2026 wurde das FOOMCASH-Protokoll aufgrund einer anfälligen Groth16-Beweisverifikation [1] ausgenutzt, was zu Gesamtverlusten von über 2,26 Mio. $ führte.

Hintergrund

Das FOOMCASH-Protokoll ist ein Lotterie-Protokoll auf Base und Ethereum, das Groth16-Beweise für Auszahlungsverifikationen verwendet. Im Vertrag FoomLottery verifiziert die Funktion collect() den bereitgestellten Beweis (d. h. _pA, _pB und _pC), indem sie die Funktion WithdrawG16Verifier.verifyProof() aufruft. Konkret wird die Verifikation basierend auf dem vertrauenswürdigen Setup (d. h. gamma und delta) im Vertrag WithdrawG16Verifier durchgeführt. Sobald der Beweis als gültig verifiziert ist, fährt die Funktion collect() fort und überträgt Assets (d. h. FOOM-Token) basierend auf den Eingaben des Nutzers (z. B. _recipient und _rewardbits).

Schwachstellenanalyse

Die Grundursache des Vorfalls war ein anfälliges Groth16-Setup. Konkret teilten sich im Vertrag WithdrawG16Verifier die Variablen gamma ($\gamma \backslash gamma$) und delta ($\delta \backslash delta$) denselben Wert (d. h. $G\mathrm{\_}2G\backslash \_\{2\}$), wodurch der Angreifer gültige Beweise mit beliebigen Eingaben fälschen konnte. Dadurch umging der Angreifer die Groth16-Beweisverifikation im Vertrag WithdrawG16Verifier und zog mit bösartigen Eingaben alle Assets im Vertrag FoomLottery 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. Es konstruierte einen gültigen Beweis.

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

a. Beim Aufruf der Funktion collect() wurde die Beweisverifikation (d. h. WithdrawG16Verifier.verifyProof()) umgangen und die Assets (d. h. FOOM-Token) wurden an den Angreifer übertragen.

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

Fazit

Die Grundursache des Vorfalls war ein anfälliges Groth16-Verifikations-Setup, das zu einem Schaden von etwa 2,26 Mio. $ führte. Dies unterstreicht, dass komplexe kryptografische Setups vor der Bereitstellung sorgfältig überprüft und auditiert werden müssen.

Referenzen

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

7. Unbekannter Vorfall

Kurzzusammenfassung

Am 27. Februar 2026 wurde ein unbekannter Vertrag auf der BNB Smart Chain ausgenutzt [1], was zu einem Schaden von etwa 180 Tsd. $ führte. Die Grundursache dieses Vorfalls war unzureichende Eingabevalidierung. Konkret versäumte es die Funktion _verifySignatures() des betroffenen Vertrags, eine Prüfung auf leere Listen durchzuführen, wodurch der Angreifer die Signaturverifikation ohne Angabe von Signaturen und Signierenden umgehen konnte. Dadurch nutzte der Angreifer diese Schwachstelle, um alle USDT-Token im betroffenen Vertrag abzuziehen.

Schwachstellenanalyse

Die Grundursache dieses Vorfalls ist eine unzureichende Validierung im Signaturverifikationsablauf. Konkret prüft die Funktion _verifySignatures() lediglich, dass allSigners.length == signatures.length, und verlangt nicht, dass eines der beiden Arrays nicht leer ist. Dadurch kann der Angreifer, wenn beide Arrays leer sind, die Signaturverifikation 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. Beim Aufruf:

a. Der bösartige Vertrag rief die Funktion poolWithdraw() mit leeren Eingaben allSigners und signatures auf und umging dadurch die vorgesehene Signaturverifikationslogik.

b. Nach der Umgehung der Signaturverifikationslogik übertrug der betroffene Vertrag USDT an den Angreifer.

Fazit

Die Grundursache dieses Vorfalls war unzureichende Eingabevalidierung, die zu einem Schaden von etwa 180 Tsd. $ führte. Der Vorfall unterstreicht die Bedeutung grundlegender Grenzwertprüfungen wie Nicht-Leer-Prüfungen für Eingaben.

Referenzen

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

Über BlockSec

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

BlockSec hat mehrere Blockchain-Sicherheitspapers 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 Auditing Service : Anfrage senden

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance