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

Im Laufe der letzten Woche (23.02.2026 - 01.03.2026) hat BlockSec sieben Angriffe erkannt und analysiert, die zu geschätzten Gesamtverlusten von ca. 13 Mio. $ führten. Die folgende Tabelle fasst diese Vorfälle zusammen; detaillierte Analysen zu jedem Fall finden sich in den nachfolgenden Unterabschnitten.

1. LAXO-Vorfall

Kurze Zusammenfassung

Am 22. Februar 2026 wurde der ERC20-Token LAXO auf der BNB Smart Chain angegriffen, was zu Verlusten von etwa 137.320 $ beim LAXO-USDT-Paar führte. Die Ursache war ein fehlerhafter Burn-Mechanismus, der aktiviert wurde, wenn LAXO direkt an das PancakeSwap-Paar transferiert wurde. Da der Router auf einer Whitelist stand und die Burn-Logik in transfer() nicht auslöst, umging der Angreifer diese: Er sandte LAXO an das Paar und rief dann die Low-Level-Funktion swap() des Paares auf, welche Paar-Token verbrannte und sync() aufrief, was den Preis in die Höhe trieb. Der Angreifer tauschte dann mit Gewinn in USDT zurück.

Hintergrund

Der LAXO-Token implementiert einen Burn-Mechanismus. Wenn der Empfänger eines Transfers die Adresse des USDT-LAXO PancakeSwap-Paares 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.

Sicherheitsanalyse

Die Ursache des Vorfalls war ein fehlerhafter Burn-Mechanismus im LAXO-Token. Insbesondere führt das direkte Übertragen von LAXO an das Paar zum Burn, wodurch LAXO aus dem Paar entfernt und dessen Preis künstlich erhöht wird. Folglich konnte ein Angreifer dies für Preismanipulationsangriffe ausnutzen.

Angriffsanalyse

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

1. Der Angreifer nahm einen Flashloan über 350.000e18 USDT von PancakeSwap V3 auf.

2. Der Angreifer tauschte USDT über den PancakeSwap-Router in LAXO um. 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 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 ansteigen ließ.

4. Der Angreifer tauschte den burnAmount an LAXO basierend auf dem manipulierten Preis gegen ca. 487.500e18 USDT.

5. Der Angreifer zahlte den Flashloan zurück und behielt die verbleibenden USDT als Gewinn.

Fazit

Die Wurzel dieses Vorfalls liegt im fehlerhaften Burn-Mechanismus von LAXO, der es Angreifern ermöglicht, USDT mittels Preismanipulation aus dem Pool zu ziehen. Der Vorfall verursachte Gesamtverluste von ca. 137,3 Tsd. $. Um solche Probleme zu vermeiden, muss das Projekt umfassende Tests des Burn-Mechanismus durchführen, um potenzielle Preismanipulationsangriffe zu verhindern.

2. YieldBloxDAO-Vorfall

Kurze Zusammenfassung

Am 22. Februar 2026 wurde ein von YieldBlox DAO betriebener Lending-Pool auf Stellas Blend V2 angegriffen, 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.

Der Angreifer manipulierte den USTRY/USDC-Markt auf der SDEX. Der konfigurierte Reflector-Orakelpfad des Pools akzeptierte den manipulierten Preis, was 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 Lending-Pools zu erstellen. Diese Pools erleichtern das Ausleihen und Verleihen von unterstützten Assets. Der betroffene Pool ermöglichte es Benutzern, XLM und USDC unter Verwendung von USTRY als Sicherheit zu leihen. Zudem gibt der Pool-Ersteller das Reflector-Orakel [2] als Orakel-Anbieter an. Der von diesem Orakel bereitgestellte Preis für USTRY aktualisiert sich alle fünf Minuten basierend auf dem USTRY/USDC-Markt auf der Stellar DEX (SDEX) [3].

Sicherheitsanalyse

Die Ursache war die Preismanipulation im illiquiden USTRY/USDC-Markt der SDEX, die zu einer verwundbaren Preisaktualisierung von USTRY auf dem Reflector-Orakel führte. Aufgrund der extrem geringen Liquidität im USTRY/USDC-Markt konnte der Angreifer normale Orders aufkaufen und abnormale Orders platzieren, um den USTRY-Preis um das 100-fache zu steigern. Dieser überhöhte Preis wurde an das Reflector-Orakel weitergegeben, wodurch der Angreifer durch Hinterlegung von überbewertetem USTRY alle Assets des Pools (XLM und USDC) leihen konnte.

Angriffsanalyse

1. (Tx 1, 2) Der Angreifer manipulierte den USTRY-Preis auf der SDEX und trieb ihn von 1,06 $ auf ca. 107 $. Da der Markt extrem illiquide war, kaufte der Angreifer alle normalen Orders auf und platzierte dann abnormale Orders, die den Marktpreis sprunghaft in die Höhe trieben.

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

3. (Tx 4, 5) Der Angreifer lieh 1.000.196e7 USDC durch Hinterlegung von 12.881e7 USTRY.

4. (Tx 6, 7) Der Angreifer lieh 6.124.927.810e7 XLM durch Hinterlegung von 14.987.610e7 USTRY.

5. (Txs 8, 9, 10) Abschließend bridgte der Angreifer die abgezogenen Assets auf mehrere Ketten, darunter Base, BSC und Ethereum.

Die nachfolgende Tabelle fasst die wichtigsten Exploit-Transaktionen zusammen.

Fazit

Obwohl der YieldBloxDAO-Vorfall zu erheblichen Verlusten führte, ist das zugrunde liegende Problem simpel: Die Bewertung der Sicherheiten hängt von einem Preis ab, der anfällig für Manipulationen ist. Dieser Vorfall erinnert daran, dass Preisquellen 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 Markt auf SDEX

3. STO-Vorfall

Kurze Zusammenfassung

Am 23. Februar 2026 wurde ein STO-WBNB-Pool auf PancakeSwap in der BNB Smart Chain leergeräumt, was zu Verlusten von etwa 16.100 $ führte. Die Ursache war ein fehlerhafter Burn-Mechanismus im STO-Token. Wenn Benutzer STO-Token im Pool verkauften, wurde der Burn-Mechanismus ausgelöst, der STO-Token aus dem Pool verbrannte und den Preis des Tokens in die Höhe trieb. Der Angreifer nutzte dies aus, um WBNB-Token aus dem Pool zu ziehen.

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 aktiviert ist (sellEnabled == true) und pendingBurnFromSell > 0 gilt.

Sicherheitsanalyse

Die Ursache ist der fehlerhafte Burn-Mechanismus, der bei jedem Verkauf STO aus dem Pool entfernt und mittels sync() die Reserven aktualisiert, was den Preis manipuliert und Preismanipulationsangriffe ermöglicht.

Angriffsanalyse

Der Angriff basiert auf der Transaktion 0x8ba17bea....

1. Der Angreifer lieh 360.894e18 WBNB per Flashloan.
2. Aktivierung der Kauf-/Verkaufsfunktionalität durch initializeLiquidity().
3. Tausch von WBNB in STO.
4. Aufruf von transfer(), um den Burn-Mechanismus auszulösen und den Preis zu manipulieren, während gleichzeitig eine Menge von 173.391e18 zur Verbrennung in der nächsten Transaktion markiert wurde.
5. Tausch von STO zu WBNB basierend auf dem manipulierten Preis.
6. Wiederholung der Schritte, um den Pool zu leeren.

Fazit

Die Wurzel des Problems ist der fehlerhafte Burn-Mechanismus. Das Projekt muss umfassende Tests und angemessene Zugriffskontrollen implementieren, um zukünftige Preismanipulationen zu verhindern.

4. HedgePay-Vorfall

Kurze Zusammenfassung

Am 25. Februar 2026 wurde das HedgePay-Protokoll auf der BNB Smart Chain angegriffen, was zu ca. 15.700 $ Verlust führte. Die Ursache war eine fehlerhafte Geschäftslogik im Staking-Contract. Die Funktion forceExit() erlaubte das Abheben von Assets, ohne das Guthaben des Benutzers (_balances) zu aktualisieren.

Sicherheitsanalyse

Wenn Benutzer HPAY über stake() staken, wird der Saldo aktualisiert. Nach dem Abheben über forceExit() fehlte dieses Update, wodurch wiederholte Auszahlungen möglich waren.

Angriffsanalyse

Die Analyse basiert auf der Transaktion 0x5f2ea6cb....

1. Flashloan von HPAY.
2. Mehrfacher Aufruf von forceExit() während eines einzigen Staking-Durchgangs, um den Contract zu leeren.
3. Rückzahlung des Flashloans und Profit-Mitnahme.

Fazit

Da der Status (_balances) nicht korrekt gepflegt wurde, konnte der Angreifer den Contract leeren. Projekte sollten state-orientierte Tests durchführen, um Zustandsinvarianten sicherzustellen.

5. Ploutos-Vorfall

Kurze Zusammenfassung

Am 26. Februar 2026 erlitt ein Pool des Ploutos-Protokolls auf Ethereum ca. 390.000 $ Verlust durch eine Orakel-Fehlkonfiguration. Der Preisfeed für USDC war fälschlicherweise auf den Chainlink BTC/USD-Feed eingestellt.

Sicherheitsanalyse

In Block 24538896 wurde die Konfiguration geändert. Ein Angreifer erkannte dies sofort im nächsten Block und lieh für ca. 8,88 USDC Sicherheiten etwa 187 ETH.

Fazit

Empfindliche Konfigurationsoperationen wie Orakel-Einstellungen sollten immer über Multisig-Wallets oder Timelocks geschützt werden.

6. FOOMCASH-Vorfall

Kurze Zusammenfassung

Am 26. Februar 2026 wurde das FOOMCASH-Protokoll aufgrund einer verwundbaren Groth16-Proof-Verifizierung [1] mit über 2,26 Mio. $ Schaden angegriffen.

Sicherheitsanalyse

Die Variablen Gamma ($\gamma \backslash gamma$) und Delta ($\delta \backslash delta$) im WithdrawG16Verifier hatten denselben Wert. Dies erlaubte es dem Angreifer, gültige Proofs für beliebige Eingaben zu fälschen.

Angriffsanalyse

Der Angreifer konstruierte in einem bösartigen Contract einen gültigen Proof und rief collect() mit gefälschten Eingaben (_recipient, _rewardbits) auf, um die Validierung zu umgehen und FOOM-Token abzuziehen.

Fazit

Komplexe kryptografische Setups müssen vor dem Deployment gründlich geprüft und auditiert werden.

7. Unbekannter Vorfall

Kurze Zusammenfassung

Am 27. Februar 2026 wurde ein unbekannter Contract auf der BNB Smart Chain mit ca. 180.000 $ Schaden angegriffen [1]. Die Ursache war eine mangelhafte Eingabevalidierung in der Signaturprüfung, die keine Prüfung auf leere Listen vorsah.

Sicherheitsanalyse

Die Funktion _verifySignatures() prüfte lediglich allSigners.length == signatures.length. Wenn beide Längen 0 waren, wurde die Prüfung als "erfolgreich" gewertet.

Fazit

Dieser Vorfall unterstreicht die Notwendigkeit grundlegender Grenzprüfungen (Boundary Checks), wie etwa die Prüfung auf leere Eingabearrays.

Über BlockSec

BlockSec ist ein Full-Stack-Blockchain-Sicherheitsanbieter. Wir erstellen Produkte und Dienstleistungen, die Kunden bei der Durchführung von Code-Audits, der Echtzeit-Abwehr von Angriffen, der Analyse von Vorfällen, der Verfolgung illegaler Gelder und der Einhaltung von AML/CFT-Verpflichtungen unterstützen.

BlockSec hat zahlreiche Sicherheitsstudien veröffentlicht, mehrere Zero-Day-Angriffe gemeldet und hilft dabei, Milliarden an Kryptowerten weltweit abzusichern.

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

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

• 🔗 BlockSec Audit-Service: Anfrage senden

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance