Web3-Sicherheitsvorfälle der Woche | 16. – 22. Feb 2026

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

1. Moonwell-Vorfall

Kurze Zusammenfassung

Am 16. Februar 2026 wurde das Moonwell-Protokoll auf Base aufgrund einer Fehlkonfiguration des Orakels ausgenutzt, was zu geschätzten Schulden 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 Composite-Orakels, das den ETH/USD-Preis einbezieht, zugewiesen wurde. Dies führte dazu, dass das Orakel cbETH mit rund 1,12 USD anzeigte, anstatt seines tatsächlichen Marktwerts von rund 2.200 USD. Liquidations-Bots ergriffen sofort 1.096,317 cbETH und beglichen minimale Schulden, bevor die Limits reduziert wurden, um den Angriff zu stoppen.

Hintergrund

Moonwell ist ein Lending-Protokoll über mehrere Ketten hinweg und hat am 16. Februar 2026 einen Vorschlag namens MIP-X43 umgesetzt. 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 sollen es dem Protokoll ermöglichen, Werte bei Liquidierungen zu erfassen, die auf Orakelpreisen basieren, und gleichzeitig sicherzustellen, dass Liquidatoren ordnungsgemäß Anreize erhalten.

Schwachstellenanalyse

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

Angriffsanalyse

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

2. Liquidations-Bots, die das Protokoll überwachten, erkannten sofort die Preisdiskrepanz und führten Liquidierungen von cbETH-[Sicherheitspositionen] durch.

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

Schlussfolgerung

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

Für Protokolle, die mehrere Orakel-Feeds verwalten, ist die Implementierung gründlicher Validierungsverfahren vor der Bereitstellung von entscheidender Bedeutung, um sicherzustellen, dass jeder Vermögenswert mit seiner beabsichtigten Preisquelle verknüpft ist. Eine strenge Verifizierung kann das Risiko solch hochwirksamer Fehlkonfigurationen erheblich reduzieren.

2. PearlDriver-Vorfall

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 Ursache war ein nicht überprüfter arithmetischer Überlauf in der buy()-Funktion, der es dem Angreifer ermöglichte, extrem große Mengen an Spiel-Tokens zu fast 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 stabilen Kosten für den Kauf 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 beruht auf der Annahme, dass größere Käufe entsprechend größere Zahlungen erfordern, wodurch die Preisintegrität gewahrt und eine unverhältnismäßige Token-Ausgabe verhindert wird.

Schwachstellenanalyse

Die Ursache war ein arithmetischer Überlauf bei der Berechnung der stabilen Zahlung. Die gesamte buy()-Funktion wurde in einen unchecked-Block eingeschlossen, wodurch der eingebaute Überlaufschutz von Solidity deaktiviert wurde. Infolgedessen kam es bei der Multiplikation zur Berechnung der Kaufkosten nicht zu einem Rückfall, wenn die maximale Ganzzahlgrenze überschritten wurde. Stattdessen trat ein Überlauf auf und der Wert wurde zu einer viel kleineren Zahl, was die erforderliche Zahlung drastisch reduzierte.

Infolgedessen konnte der Angreifer fast nichts bezahlen, während er eine enorme Menge an Tokens prägte, die dann sofort in DEX-Liquiditätspaare gedumpt wurden, um USDT abzuschöpfen.

Angriffsanalyse

In einer einzigen Transaktion nutzte der Angreifer die anfällige buy()-Funktion über fünf Vermögenswerte (IRON ORE, COAL, WOOD, SAND und CLAY) mit demselben Angriffsmuster aus. Nehmen wir als Beispiel den ersten Vermögenswert:

1. Der Angreifer gab beim Aufruf von buy() eine extrem große Kaufmenge an. Aufgrund unkontrollierter Arithmetik führte die Berechnung Menge * aktuellerPreis zu einem Überlauf und wurde zu einem Wert nahe Null, der nur 0,0053 USDT (weniger als ~0,01 USD) als Zahlung erforderte. Trotz der vernachlässigbaren Kosten prägte der Vertrag eine enorme Menge an IRON ORE für den Angreifer, genauer gesagt 7,03 × 10⁵⁸ Tokens.

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

Die gleiche Überlauf-und-Dump-Sequenz wurde gegen die anderen vier Vermögenswerte ausgeführt, wobei die Liquidität aus jedem Asset-USDT-Paar abgezogen und ein Gesamtgewinn von über 40.000 USD erzielt wurde.

Schlussfolgerung

Dieser Vorfall wurde durch unkontrollierte 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.

Obwohl unkontrollierte 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 Deaktivierung der integrierten Überlaufprüfungen von Solidity 0.8+ in Betracht ziehen, insbesondere in Code-Pfaden, die Preisgestaltung oder Überweisungen betreffen.

3. IoTex-Vorfall

Kurze Zusammenfassung

Am 21. Februar 2026 wurde die ioTube-Bridge von IoTeX nach der Kompromittierung des Ethereum Validator-Besitzerschlüssels einem Sicherheitsbruch 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 Mio. USD abzuziehen und über 400 Mio. CIOTX-Tokens zu prägen. Gestohlene Reserven wurden getauscht und teilweise auf Bitcoin gebbrückt. Laut dem Projekt wurden 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 IoTeX Layer 1 mit anderen Netzwerken wie Ethereum verbindet. Auf Ethereum konzentriert sich die Brückenarchitektur auf den Validator-Vertrag (d.h. TransferValidatorWithPayload), der Cross-Chain-Settlement-Nachrichten verifiziert und nachgelagerte Minter-Verträge verwaltet. Dazu gehören TokenSafe, das Brückenreserve-Vermögenswerte hält, und MintPool, das die Präge-Autorität für bestimmte Tokens wie CIOTX hält.

Schwachstellenanalyse

Die Ursache war die Kompromittierung des privaten Schlüssels des Besitzers des Validator-Vertrags. Da die Bridge auf einer einzelnen EOA ohne Multi-Signatur- oder Timelock-Kontrollen angewiesen war, gewährte der Besitz dieses Schlüssels die vollständige administrative Kontrolle. Mithilfe der upgrade()-Funktion des Vertrags übertrug der Angreifer die Eigentümerschaft der TokenSafe- und MintPool-Verträge auf eine vom Angreifer kontrollierte Adresse. Dies ermöglichte den direkten Abzug von Brückenreserve-Vermögenswerten und die unbefugte Prägung großer Mengen an CIOTX.

Angriffsanalyse

1. Kompromittierung des Besitzerschlüssels des Validator-Vertrags auf Ethereum, wodurch die administrative Kontrolle erlangt wurde.

2. Nutzung des Validator-Vertrags zur Übertragung der Eigentümerschaft der TokenSafe- und MintPool-Verträge.

3. Abzug von Reserve-Vermögenswerten (USDC, USDT, WBTC, WETH, BUSD usw.) im Wert von ca. 4,4 Mio. USD aus TokenSafe und Prägung von über 400 Mio. CIOTX über MintPool.

4. Tausch der gestohlenen Reserve-Tokens und Brückenbildung zu anderen Ketten.

Schlussfolgerung

Dieser Vorfall stellt eine klassische Schlüsselkompromittierung mit einem einzigen Fehlerpunkt dar. Die gesamte Sicherheit der Ethereum-Bridge beruhte auf einer einzigen EOA mit voller administrativer Autorität und ohne Multi-Signatur-Schutz oder Timelock-Sicherungen. Sobald der private Schlüssel der EOA kompromittiert war, ging die Kontrolle über kritische Brückenkomponenten faktisch 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 Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. 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 angesehenen 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 Audit-Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance