Wöchentliche Web3-Sicherheitsvorfälle im Überblick

In der vergangenen Woche (16. Feb.–22. Feb. 2026) hat BlockSec drei Angriffsvorfälle erkannt und analysiert, mit einem geschätzten Gesamtschaden von ~$6,22 Mio.. Die folgende Tabelle fasst diese Vorfälle zusammen; detaillierte Analysen zu jedem Fall werden in den nachfolgenden Unterabschnitten bereitgestellt.

Datum	Vorfall	Art	Geschätzter Schaden
2026/02/16	Moonwell-Vorfall	Fehlkonfiguration	~$1,78 Mio.
2026/02/19	PearlDriver-Vorfall	Arithmetischer Überlauf	~$40,3K
2026/02/21	IoTex-Vorfall	Schlüssel-Kompromittierung	~$4,4 Mio.

1. Moonwell-Vorfall

Kurze Zusammenfassung

Am 16. Februar 2026 wurde das Moonwell-Protokoll auf Base aufgrund einer Oracle-Fehlkonfiguration ausgenutzt, was zu etwa 1,78 Millionen US-Dollar an Forderungsausfällen führte. Das Problem trat während der Ausführung des MIP-X43-Vorschlags auf, bei dem dem Base-cbETH-Oracle fälschlicherweise ein cbETH/ETH-Wechselkurs-Feed anstelle des zusammengesetzten Oracles zugewiesen wurde, das den ETH/USD-Preis einbezieht. Dies veranlasste das Oracle, cbETH mit ~$1,12 statt dem tatsächlichen Marktwert von ~$2.200 zu melden. Liquidations-Bots beschlagnahmten sofort 1.096,317 cbETH und beglich dabei minimale Schulden, bevor die Obergrenzen gesenkt wurden, um den Exploit zu stoppen.

Hintergrund

Moonwell ist ein Kreditprotokoll über mehrere Chains hinweg und führte am 16. Februar 2026 einen Vorschlag namens MIP-X43 aus. Dieser Vorschlag zielte darauf ab, Chainlink-OEV-Wrapper-Verträge (Oracle Extractable Value) über alle verbleibenden Kern- und isolierten Märkte auf Base und Optimism zu aktivieren und damit die Abdeckung über die ursprünglich in MIP-X38 aktivierten drei Feeds hinaus zu erweitern. Die OEV-Wrapper sind so konzipiert, dass das Protokoll Werte bei Liquidationen erfassen kann, die auf Oracle-Preisen basieren, während sichergestellt wird, dass Liquidatoren weiterhin angemessen incentiviert werden.

Schwachstellenanalyse

Die Schwachstelle resultierte aus einem Konfigurationsfehler im Konstruktor von ChainlinkOracleConfigs.sol. Für Base-Chain-cbETH konfigurierte der Vorschlag das Oracle als "cbETHETH_ORACLE" (ein cbETH/ETH-Wechselkurs-Feed) anstelle des korrekten zusammengesetzten Oracles, das diese Rate mit der ETH/USD-Preisgestaltung kombiniert. Als der OEV-Wrapper bereitgestellt und über setFeed() am ChainlinkOracle als Feed eingebunden 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 (~$1,12) und dem tatsächlichen Marktwert (~$2.200–$2.400), was zu einer ~2.200-fachen Unterbewertung des cbETH-Sicherheitswerts führte.

Angriffsanalyse

Um 2:01 Uhr UTC+8 am 16. Februar 2026 wurde die Ausführung von MIP-X43 abgeschlossen und das fehlkonfigurierte cbETH-Oracle auf der Base-Chain aktiviert.
Liquidations-Bots, die das Protokoll überwachen, erkennen sofort die Preisdiskrepanz und führen Liquidationen auf cbETH-[Sicherheitenpositionen] durch.

Innerhalb weniger Minuten werden 1.096,31 cbETH von Liquidatoren beschlagnahmt, was zu ~$1,78 Mio. an Forderungsausfällen in den betroffenen Märkten führt.

Fazit

Dieser Vorfall wurde letztendlich durch einen Konfigurationsfehler bei der Bereitstellung von Moonwells MIP-X43 verursacht, bei dem der Base-Chain-cbETH fälschlicherweise ein cbETH/ETH-Wechselkurs-Feed anstelle des korrekten zusammengesetzten Oracles zugewiesen wurde. Diese Fehlkonfiguration ermöglichte die schnelle Erschöpfung einer erheblichen Menge an cbETH-Sicherheiten.

Für Protokolle, die mehrere Oracle-Feeds verwalten, ist es entscheidend, gründliche Vorab-Validierungsverfahren zu implementieren, um sicherzustellen, dass jedes Asset mit seiner beabsichtigten Preisquelle verknüpft ist. Eine rigorose Überprüfung kann das Risiko solcher schwerwiegenden 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 einem Schaden von etwa $40,3K führte. Die Ursache 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 null Kosten zu prägen und diese dann in die PearlDEX-Liquiditätspools zu verkaufen.

Hintergrund

PearlDriver verwendet eine NLAMM-Bonding-Curve (Nichtlinearer Automatisierter Market Maker) für das Token-Minting. Nutzer können Spielressourcen-Tokens über die buy()-Funktion erwerben, wobei die Kaufkosten in Stablecoins wie folgt berechnet werden: Kosten = Menge * aktuellerPreis.

Unter normalen Bedingungen stellt diese Formel sicher, dass die erforderliche Zahlung direkt proportional zur gekauften Menge ist. Die Bonding Curve stützt sich auf die 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 in der Stablecoin-Zahlungsberechnung. Die gesamte buy()-Funktion war in einem unchecked-Block eingebettet, was Soliditys integrierten Überlaufschutz deaktivierte. Infolgedessen führte die zur Berechnung der Kaufkosten verwendete Multiplikation bei Überschreitung der maximalen Ganzzahlgrenze nicht zu einem Revert. Stattdessen überfloss der Wert und wurde auf eine viel kleinere Zahl zurückgerollt, was die erforderliche Zahlung drastisch reduzierte.

Folglich konnte der Angreifer nahezu nichts zahlen, während er eine enorme Menge an Tokens prägte, die dann sofort in DEX-Liquiditätspaare verkauft wurden, um USDT abzuschöpfen.

Angriffsanalyse

In einer einzigen Transaktion nutzte der Angreifer die anfällige buy()-Funktion für fünf Assets (EISENERZ, KOHLE, HOLZ, SAND und TON) mit demselben Angriffsmuster aus. Am Beispiel des ersten Assets:

Der Angreifer gab beim Aufruf von buy() einen extrem großen Kaufbetrag an. Aufgrund der nicht geprüften Arithmetik überfloss die Berechnung Menge * aktuellerPreis und rollte auf einen nahezu null Wert zurück, sodass nur 0,0053 USDT (weniger als ~$0,01) als Zahlung erforderlich waren. Trotz der vernachlässigbaren Kosten prägte der Vertrag eine enorme Menge an EISENERZ für den Angreifer, konkret 7,03 × 10⁵⁸ Tokens.
Der Angreifer tauschte sofort einen Teil des geprägten EISENERZs in das entsprechende PearlDEX-Liquiditätspaar um und erhielt 7.805,55 USDT (~$7.805,56).

Die gleiche Überlauf-und-Dump-Sequenz wurde gegen die anderen vier Assets durchgeführt, wobei Liquidität aus jedem Asset-USDT-Paar abgeschöpft und insgesamt über $40K Gewinn erzielt wurde.

Fazit

Dieser Vorfall wurde durch nicht geprüfte Arithmetik in der Preislogik der NLAMM-buy()-Funktion verursacht. Durch die Deaktivierung von Überlaufprüfungen ermöglichte die Funktion, dass extreme Eingabewerte die Zahlungsberechnung verzerren und die wirtschaftlichen Annahmen des Bonding-Curve-Modells verletzen.

Obwohl nicht geprüfte Arithmetik in eng kontrollierten Szenarien angemessen sein kann, kann ihre Verwendung in Finanzlogik, die direkt Zahlungsbeträge bestimmt, erhebliche Risiken einführen. Um solche Risiken zu mindern, sollten Entwickler alle arithmetischen Operationen sorgfältig prüfen und Vorsicht walten lassen, wenn sie erwägen, die integrierten Überlaufprüfungen von Solidity 0.8+ zu deaktivieren, insbesondere in Code-Pfaden, die Preisgestaltung oder Übertragungen betreffen.

3. IoTex-Vorfall

Kurze Zusammenfassung

Am 21. Februar 2026 erlitt IoTeXs ioTube-Bridge einen Sicherheitsvorfall infolge der Kompromittierung des Ethereum-Validator-Eigentümerschlüssels. Der Angreifer erlangte die Eigentümerschaft des Validator-Vertrags und übernahm dann die Kontrolle über die TokenSafe- und MintPool-Verträge, um ~$4,4 Mio. an Bridge-Reserven abzuschöpfen und über 400 Mio. CIOTX-Tokens zu prägen. Gestohlene Reserven wurden getauscht und teilweise zu Bitcoin gebrückt. Laut dem Projekt wurden etwa 355 Mio. der geprägten CIOTX-Tokens dauerhaft gesperrt oder eingefroren.

Hintergrund

Das kompromittierte ioTube ist IoTeXs Cross-Chain-Bridge-Infrastruktur, 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 Bridge-Reserven hält, und MintPool, das die Minting-Autorität für bestimmte Tokens wie CIOTX besitzt.

Schwachstellenanalyse

Die Ursache war die Kompromittierung des privaten Schlüssels des Validator-Vertragseigentümers. Da die Bridge auf einer einzigen EOA ohne Multi-Signatur- oder Timelock-Kontrollen basierte, gewährte der Besitz dieses Schlüssels volle 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 die direkte Auszahlung von Bridge-Reserven und das unbefugte Prägen großer Mengen an CIOTX.

Angriffsanalyse

Kompromittierung des Validator-Vertragseigentümerschlüssels auf Ethereum, Erlangung der administrativen Kontrolle.
Verwendung des Validator-Vertrags zur Übertragung der Eigentümerschaft der TokenSafe- und MintPool-Verträge.

Abschöpfung von ~$4,4 Mio. an Reserven (USDC, USDT, WBTC, WETH, BUSD usw.) aus TokenSafe und Prägung von über 400 Mio. CIOTX über MintPool.
Tausch der gestohlenen Reserve-Tokens und Überbrückung auf andere Chains.

Fazit

Dieser Vorfall ist ein Paradebeispiel für eine Schlüssel-Kompromittierung als Single Point of Failure. Die gesamte Ethereum-seitige Bridge-Sicherheit basierte auf einer einzigen EOA mit voller administrativer Autorität und ohne Multi-Signatur-Schutz oder Timelock-Sicherheitsmechanismen. Sobald der private Schlüssel der EOA kompromittiert wurde, war die Kontrolle über kritische Bridge-Komponenten faktisch verloren.

Der Fall verdeutlicht das Risiko zentralisierter administrativer Kontrolle und unterstreicht die Bedeutung der Verteilung von Upgrade- und Verwahrungs-Autorität 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 dabei helfen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchains und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zu verfolgen und AML/CFT-Verpflichtungen zu erfüllen – über den gesamten Lebenszyklus von Protokollen und Plattformen.

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 Milliarden von Kryptowährungen gesichert.