Wöchentlicher Web3 Sicherheitsvorfall-Rundown | 16. – 22. Feb 2026

In der vergangenen Woche (15. bis 21. Februar 2026) hat BlockSec drei Angriffsereignisse erkannt und analysiert, mit geschätzten Gesamtschäden von ca. 6,22 Mio. USD. Die folgende Tabelle fasst diese Ereignisse zusammen, und detaillierte Analysen für jeden Fall werden in den folgenden Unterabschnitten bereitgestellt.

1. Moonwell-Ereignis

Kurze Zusammenfassung

Am 15. Februar 2026 wurde das Moonwell-Protokoll auf Base aufgrund einer Fehlkonfiguration des Orakels ausgenutzt, was zu einem geschätzten Schuldenbetrag von rund 1,78 Millionen US-Dollar führte. Das Problem trat während der Ausführung des MIP-X43-Vorschlags auf, bei dem dem Base cbETH-Orakel fälschlicherweise ein cbETH/ETH-Wechselkurs-Feed anstelle des zusammengesetzten Orakels zugewiesen wurde, das den ETH/USD-Preis berücksichtigt. Dies führte dazu, dass das Orakel cbETH mit rund 1,12 USD statt seines tatsächlichen Marktwertes von rund 2.200 USD meldete. Liquidationsbots beschlagnahmten sofort 1.096,317 cbETH und zahlten minimale Schulden zurück, bevor die Limits reduziert wurden, um den Exploit zu stoppen.

Hintergrund

Moonwell ist ein Kreditprotokoll, das über mehrere Ketten hinweg agiert und am 15. Februar 2026 einen Vorschlag namens MIP-X43 ausführte. Dieser Vorschlag zielte darauf ab, Chainlink OEV (Oracle Extractable Value) Wrapper-Verträge für alle verbleibenden Kern- und isolierten Märkte auf Base und Optimism zu aktivieren und damit die Abdeckung über die in MIP-X38 aktivierten anfänglichen drei Feeds hinaus zu erweitern. Die OEV-Wrapper sind so konzipiert, dass sie es dem Protokoll ermöglichen, Wert während der Liquidationen zu erfassen, die auf Orakelpreisen beruhen, und gleichzeitig sicherzustellen, dass die Liquidatoren angemessen motiviert bleiben.

Schwachstellenanalyse

Die Schwachstelle resultierte aus einem Konfigurationsfehler im Konstruktor von ChainlinkOracleConfigs.sol. Für die cbETH auf der Base-Kette konfigurierte der Vorschlag das Orakel als "cbETHETH_ORACLE" (einen cbETH/ETH-Wechselkurs-Feed) anstelle des korrekten zusammengesetzten Orakels, das diesen Kurs mit der ETH/USD-Preisbildung kombiniert. Als der OEV-Wrapper über setFeed() im ChainlinkOracle bereitgestellt und verdrahtet wurde, begann das Protokoll, einen rohen Wechselkurs (cbETH/ETH ≈ 1,12) als USD-Preis für cbETH zu verwenden. Dies schuf eine massive Diskrepanz zwischen dem gemeldeten Preis (ca. 1,12 USD) und dem tatsächlichen Marktwert (ca. 2.200–2.400 USD), was zu einer Unterbewertung von cbETH-Sicherheiten um den Faktor 2.200 führte.

Angriffsanalyse

1. Am 15. Februar 2026 um 18:01 UTC war die Ausführung von MIP-X43 abgeschlossen, wodurch das falsch konfigurierte cbETH-Orakel auf der Base-Kette aktiviert wurde.

2. Liquidationsbots, die das Protokoll überwachen, erkannten sofort die Preisdiskrepanz und führten Liquidationen auf cbETH-Sicherheitenpositionen durch.

3. Innerhalb von Minuten wurden 1.096,31 cbETH von Liquidatoren beschlagnahmt, was zu einem Schuldenbetrag von ca. 1,78 Mio. USD in den betroffenen Märkten führte.

Schlussfolgerung

Dieses Ereignis wurde letztendlich durch einen Konfigurationsfehler bei der Bereitstellung von Moonwell MIP-X43 verursacht, bei dem der Base-Kette cbETH fälschlicherweise ein cbETH/ETH-Wechselkurs-Feed anstelle des korrekten zusammengesetzten Orakels zugewiesen wurde. Diese Fehlkonfiguration ermöglichte die schnelle Erschöpfung einer beträchtlichen Menge an cbETH-Sicherheiten.

Für Protokolle, die mehrere Orakel-Feeds verwalten, ist es unerlässlich, gründliche Validierungsverfahren vor der Bereitstellung zu implementieren, um sicherzustellen, dass jedes Asset mit seiner beabsichtigten Preisquelle verknüpft ist. Eine rigorose Überprüfung kann das Risiko solch hochwirksamer Fehlkonfigurationen erheblich reduzieren.

2. PearlDriver-Ereignis

Kurze Zusammenfassung

Am 19. Februar 2026 wurde der NLAMM-Bonding-Curve-Vertrag von PearlDriver auf BSC ausgenutzt, was zu Verlusten von rund 40,3 Tsd. USD führte. Die Hauptursache war ein nicht geprüfter arithmetischer Überlauf in der buy()-Funktion, der es dem Angreifer ermöglichte, extrem große Mengen an Spiel-Tokens zu nahezu Nullkosten zu prägen und sie dann in PearlDEX-Liquiditätspools zu verkaufen.

Hintergrund

PearlDriver verwendet eine NLAMM (Non-Linear Automated Market Maker) Bonding Curve für die Token-Prägung. Benutzer können Spielressourcen-Tokens über die buy()-Funktion erwerben, wobei die Kaufkosten in Stablecoins berechnet werden als: Kosten = Menge * aktuellerPreis.

Unter normalen Bedingungen stellt diese Formel sicher, dass die erforderliche Zahlung direkt proportional zur gekauften Menge ist. Die Bonding-Curve basiert auf der Annahme, dass größere Käufe entsprechend größere Zahlungen erfordern, was die Preisintegrität aufrechterhält und eine unverhältnismäßige Token-Ausgabe verhindert.

Schwachstellenanalyse

Die Hauptursache war ein arithmetischer Überlauf bei der Berechnung der Zahlung in Stablecoins. Die gesamte buy()-Funktion war in einen unchecked-Block eingeschlossen, der den integrierten Überlaufschutz von Solidity deaktivierte. Infolgedessen schlug die Multiplikation zur Berechnung der Kaufkosten nicht fehl, wenn die maximale Integer-Grenze überschritten wurde. Stattdessen überlief der Wert und sprang zu einer viel kleineren Zahl, wodurch die erforderliche Zahlung drastisch reduziert wurde.

Folglich konnte der Angreifer fast nichts bezahlen und prägte gleichzeitig eine riesige Menge an Tokens, die dann sofort in DEX-Liquiditätspaare verkauft wurden, um USDT abzuziehen.

Angriffsanalyse

In einer einzigen Transaktion nutzte der Angreifer die anfällige buy()-Funktion über fünf Assets (IRON ORE, COAL, WOOD, SAND und CLAY) mit demselben Angriffsmuster aus. Nehmen wir als Beispiel das erste Asset:

1. Der Angreifer gab beim Aufruf von buy() einen extrem großen Kaufbetrag an. Aufgrund der ungeprüften Arithmetik überlief die Berechnung Menge * aktuellerPreis und sprang zu einem Wert nahe Null, sodass nur 0,0053 USDT (weniger als 0,01 USD) als Zahlung erforderlich waren. Trotz der vernachlässigbaren Kosten prägte der Vertrag eine riesige Menge an IRON ORE für den Angreifer, nämlich 7,03 × 10⁵⁸ Tokens.

2. Der Angreifer tauschte sofort einen Teil des geprägten IRON ORE gegen sein entsprechendes PearlDEX-Liquiditätspaar und erhielt dafür 7.805,55 USDT (ca. 7.805,56 USD).

Die gleiche Sequenz aus Überlauf und Verkauf wurde gegen die anderen vier Assets ausgeführt, wobei die Liquidität aus jedem Asset-USDT-Paar abgezogen und insgesamt über 40.000 USD Gewinn erzielt wurde.

Schlussfolgerung

Dieses Ereignis wurde durch ungetestete Arithmetik in der Preislogik der NLAMM buy()-Funktion verursacht. Durch die Deaktivierung von Überlaufprüfungen ermöglichte die Funktion extreme Eingabewerte, die die Zahlungsberechnung verzerrten und die wirtschaftlichen Annahmen des Bonding-Curve-Modells brachen.

Während unchecked Arithmetik in eng kontrollierten Szenarien angemessen sein kann, birgt ihre Verwendung in Finanzlogik, die direkt Zahlungsbeträge bestimmt, erhebliche Risiken. Um solche Risiken zu mindern, sollten Entwickler alle arithmetischen Operationen sorgfältig prüfen und Vorsicht walten lassen, wenn sie die integrierten Überlaufprüfungen von Solidity 0.8+ deaktivieren, insbesondere in Code-Pfaden, die Preisbildung oder Überweisungen betreffen.

3. IoTex-Ereignis

Kurze Zusammenfassung

Am 21. Februar 2026 wurde die ioTube-Bridge von IoTeX nach der Kompromittierung des Ethereum-Validator-Owner-Schlüssels einem Sicherheitsangriff ausgesetzt. Der Angreifer erlangte die Kontrolle über den Validator-Vertrag und übernahm dann die Kontrolle über die TokenSafe- und MintPool-Verträge, um Brückenreserven im Wert von rund 4,4 Millionen US-Dollar abzuziehen und über 400 Millionen CIOTX-Tokens zu prägen. Gestohlene Reserven wurden getauscht und teilweise nach Bitcoin überbrückt. Laut dem Projekt sind rund 355 Millionen der geprägten CIOTX-Tokens dauerhaft gesperrt oder eingefroren.

Hintergrund

Die kompromittierte ioTube ist die Cross-Chain-Bridge-Infrastruktur von IoTeX, die die IoTeX Layer 1 mit anderen Netzwerken wie Ethereum verbindet. Auf Ethereum konzentriert sich die Bridge-Architektur auf den Validator-Vertrag (d.h. TransferValidatorWithPayload), der Cross-Chain-Settlement-Nachrichten verifiziert und nachgelagerte Minter-Verträge verwaltet. Dazu gehören TokenSafe, das die Brückenreserven hält, und MintPool, das die Prägeberechtigung für bestimmte Tokens wie CIOTX hält.

Schwachstellenanalyse

Die Hauptursache war die Kompromittierung des privaten Schlüssels des Besitzers des Validator-Vertrags. Da die Bridge auf einer einzigen EOA ohne Multisignatur- oder Timelock-Kontrollen beruhte, gewährte der Besitz dieses Schlüssels die volle administrative Kontrolle. Mithilfe der upgrade()-Funktion des Vertrags übertrug der Angreifer das Eigentum an den TokenSafe- und MintPool-Verträgen an eine vom Angreifer kontrollierte Adresse. Dies ermöglichte den direkten Abzug von Brückenreserven und die unbefugte Prägung großer Mengen an CIOTX.

Angriffsanalyse

1. Kompromittierung des Ethereum-Validator-Vertrags-Owner-Schlüssels, wodurch administrative Kontrolle erlangt wurde.

2. Verwendung des Validator-Vertrags zur Übertragung des Eigentums an den TokenSafe- und MintPool-Vertrag.

3. Abzug von Brückenreserven (USDC, USDT, WBTC, WETH, BUSD etc.) im Wert von ca. 4,4 Mio. USD aus TokenSafe und Prägung von über 400 Mio. CIOTX über MintPool.

4. Tausch der gestohlenen Reserven-Tokens und Brückung zu anderen Ketten.

Schlussfolgerung

Dieses Ereignis stellt eine klassische Kompromittierung eines einzigen zentralen Fehlerpunktes dar. Die gesamte Sicherheit der Ethereum-seitigen Bridge basierte auf einer einzelnen EOA mit voller administrativer Autorität und ohne Multisignatur-Schutz oder Timelock-Sicherungen. Sobald der private Schlüssel der EOA kompromittiert war, ging die Kontrolle über kritische Bridge-Komponenten effektiv verloren.

Der Fall unterstreicht das Risiko zentralisierter administrativer Kontrolle und betont die Bedeutung der Verteilung von Upgrade- und Custody-Autoritäten durch stärkere Governance-Mechanismen.

Über BlockSec

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

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/

• Offizielles Twitter-Konto: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance