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

In der vergangenen Woche (16. Feb. – 22. Feb. 2026) hat BlockSec drei Angriffe erkannt und analysiert, die zu geschätzten Gesamtverlusten von ~6,22 Mio. $ führten. Die folgende Tabelle fasst diese Vorfälle zusammen; detaillierte Analysen zu jedem Fall finden Sie in den nachfolgenden Unterabschnitten.

1. Moonwell-Vorfall

Kurze Zusammenfassung

Am 16. Februar 2026 wurde das Moonwell-Protokoll auf Base aufgrund einer Fehlkonfiguration des Oracles angegriffen, was zu uneinbringlichen Forderungen (Bad Debt) in Höhe von etwa 1,78 Millionen Dollar führte. Das Problem trat während der Ausführung des Vorschlags MIP-X43 auf, bei dem dem Base-cbETH-Oracle fälschlicherweise ein cbETH/ETH-Wechselkurs-Feed zugewiesen wurde, anstatt des kombinierten Oracles, das den ETH/USD-Preis einbezieht. Dies führte dazu, dass das Oracle cbETH mit ca. 1,12 $ bewertete statt mit seinem tatsächlichen Marktwert von ca. 2.200 $. Liquidations-Bots ergriffen sofort 1.096,317 cbETH, während sie minimale Schulden zurückzahlten, bevor die Obergrenzen gesenkt wurden, um den Exploit zu stoppen.

Hintergrund

Moonwell ist ein über mehrere Chains hinweg agierendes Kreditprotokoll, das am 16. Februar 2026 den Vorschlag MIP-X43 ausführte. Dieser Vorschlag zielte darauf ab, Chainlink OEV-Wrapper-Verträge (Oracle Extractable Value) für alle verbleibenden Kern- und isolierten Märkte auf Base und Optimism zu aktivieren und so die Abdeckung über die in MIP-X38 aktivierten ersten drei Feeds hinaus zu erweitern. die OEV-Wrapper sind so konzipiert, dass das Protokoll während Liquidationen, die auf Oracle-Preisen basieren, Wert schöpfen kann, während gleichzeitig sichergestellt wird, dass Liquidatoren angemessen incentiviert bleiben.

Schwachstellenanalyse

Die Schwachstelle beruhte auf einem Konfigurationsfehler im Konstruktor von ChainlinkOracleConfigs.sol. Für die Base-Chain-cbETH konfigurierte der Vorschlag das Oracle als "cbETHETH_ORACLE" (einen cbETH/ETH-Wechselkurs-Feed) anstatt als das korrekte kombinierte Oracle, das diesen Kurs mit der ETH/USD-Preisgestaltung kombiniert. Als der OEV-Wrapper bereitgestellt und via setFeed() im ChainlinkOracle als Feed eingebunden wurde, begann das Protokoll, einen rohen Wechselkurs (cbETH/ETH ≈ 1,12) als USD-Preis für cbETH zu verwenden. Dies erzeugte eine massive Diskrepanz zwischen dem gemeldeten Preis (~1,12 $) und dem tatsächlichen Marktwert (~2.200 $ – 2.400 $), was zu einer Unterbewertung der cbETH-Sicherheiten um den Faktor ~2.200 führte.

Angriffsanalyse

1. Um 02:01 Uhr UTC+8 am 16. Februar 2026 wurde die Ausführung von MIP-X43 abgeschlossen, wodurch das falsch konfigurierte cbETH-Oracle auf der Base-Chain aktiviert wurde.

2. Liquidations-Bots, die das Protokoll überwachen, erkannten sofort die Preisdifferenz und führten Liquidationen für cbETH-Sicherheitspositionen aus.

3. Innerhalb weniger Minuten wurden 1.096,31 cbETH von Liquidatoren beschlagnahmt, was zu uneinbringlichen Forderungen in Höhe von ca. 1,78 Mio. $ über die betroffenen Märkte hinweg führte.

Fazit

Dieser Vorfall wurde letztendlich durch einen Konfigurationsfehler bei der Bereitstellung von Moonswells MIP-X43 verursacht, bei dem der Base-Chain-cbETH irrtümlicherweise ein cbETH/ETH-Wechselkurs-Feed anstatt des korrekten kombinierten Oracles zugewiesen wurde. Diese Fehlkonfiguration ermöglichte die schnelle Erschöpfung einer beträchtlichen Menge an cbETH-Sicherheiten.

Für Protokolle, die mehrere Oracle-Feeds verwalten, ist es entscheidend, gründliche Validierungsprozesse vor der Bereitstellung zu implementieren, um sicherzustellen, dass jeder Vermögenswert mit der vorgesehenen Preisquelle verknüpft ist. Eine strenge Ü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 angegriffen, was zu Verlusten von etwa 40,3 Tsd. $ führte. Die Grundursache war ein ungeprüfter arithmetischer Überlauf in der buy()-Funktion, der es dem Angreifer ermöglichte, extrem große Mengen an Spiel-Token zu nahezu Nullkosten zu minten und sie dann in die PearlDEX-Liquiditätspools zu dumpen.

Hintergrund

PearlDriver nutzt eine NLAMM-Bonding-Curve (Non-Linear Automated Market Maker) für das Token-Minting. Benutzer können Spielressourcen-Token über die buy()-Funktion kaufen, wobei die Kosten 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 beruht auf der Annahme, dass größere Käufe entsprechend größere Zahlungen erfordern, wodurch die Preisintegrität gewahrt bleibt und eine unverhältnismäßige Token-Ausgabe verhindert wird.

Schwachstellenanalyse

Die Grundursache war ein arithmetischer Überlauf bei der Berechnung der Stablecoin-Zahlung. Die gesamte buy()-Funktion war in einen unchecked-Block gekapselt, der den eingebauten Überlaufschutz von Solidity deaktivierte. Infolgedessen revertierte die Multiplikation zur Berechnung der Kaufkosten nicht, als das maximale Integer-Limit überschritten wurde. Stattdessen überlief der Wert und wurde auf eine viel kleinere Zahl gewickelt, was die erforderliche Zahlung drastisch reduzierte.

Folglich konnte der Angreifer fast umsonst bezahlen, während er eine enorme Menge an Token mintete, die dann sofort in DEX-Liquiditätspaare gedumpt wurden, um USDT abzuziehen.

Angriffsanalyse

In einer einzelnen Transaktion nutzte der Angreifer die anfällige buy()-Funktion für fünf Assets (IRON ORE, COAL, WOOD, SAND und CLAY) unter Verwendung des gleichen Angriffsmusters aus. Nehmen wir das erste Asset als Beispiel:

1. Der Angreifer gab beim Aufruf von buy() eine extrem große Kaufmenge an. Aufgrund der ungeprüften Arithmetik lief die Berechnung Menge * aktuellerPreis über und wurde auf einen nahezu Nullwert gewickelt, was nur 0,0053 USDT (weniger als ~0,01 $) als Zahlung erforderte. Trotz der vernachlässigbaren Kosten mintete der Vertrag eine enorme Menge an IRON ORE an den Angreifer, genauer gesagt 7,03 × 10⁵⁸ Token.

2. Der Angreifer tauschte sofort einen Teil des geminteten IRON ORE in das entsprechende PearlDEX-Liquiditätspaar und erhielt dafür 7.805,55 USDT (~7.805,56 $).

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

Fazit

Dieser Vorfall wurde durch ungeprüfte Arithmetik in der Preislogik der buy()-Funktion des NLAMM verursacht. Durch das Deaktivieren von Überlaufprüfungen erlaubte die Funktion es extremen Eingabewerten, die Zahlungsberechnung zu verzerren, wodurch die wirtschaftlichen Annahmen des Bonding-Curve-Modells verletzt wurden.

Während ungeprüfte Arithmetik in streng kontrollierten Szenarien angemessen sein kann, kann ihr Einsatz in einer Finanzlogik, die direkt Zahlungsbeträge bestimmt, ein erhebliches Risiko darstellen. Um solche Risiken zu mindern, sollten Entwickler alle arithmetischen Operationen sorgfältig überprüfen und Vorsicht walten lassen, wenn sie die Deaktivierung der eingebauten Solidity 0.8+-Überlaufprüfungen in Betracht ziehen, insbesondere in Codepfaden, die Preisgestaltung oder Übertragungen betreffen.

3. IoTex-Vorfall

Kurze Zusammenfassung

Am 21. Februar 2026 erlitt die ioTube-Brücke von IoTeX eine Sicherheitsverletzung nach der Kompromittierung des Besitzerschlüssels des Ethereum-Validators. Der Angreifer erlangte das Eigentum am Validator-Vertrag und übernahm dann die Kontrolle über die Verträge TokenSafe und MintPool, um Brückenreserven im Wert von ca. 4,4 Mio. $ abzuziehen und über 400 Mio. CIOTX-Token zu minten. Die gestohlenen Reserven wurden getauscht und teilweise zu Bitcoin gebridget. Laut Projekt wurden etwa 355 Mio. der geminteten CIOTX-Token dauerhaft gesperrt oder eingefroren.

Hintergrund

Die kompromittierte ioTube ist die Cross-Chain-Brückeninfrastruktur von IoTeX, die die IoTeX Layer 1 mit anderen Netzwerken wie Ethereum verbindet. Auf Ethereum konzentriert sich die Brückenarchitektur auf den Validator-Vertrag (den TransferValidatorWithPayload), der Cross-Chain-Abwicklungsnachrichten verifiziert und nachgelagerte Minter-Verträge verwaltet. Dazu gehören TokenSafe, das Brückenreserven enthält, und MintPool, das die Minting-Autorität für bestimmte Token wie CIOTX innehat.

Schwachstellenanalyse

Die Grundursache war die Kompromittierung des privaten Schlüssels des Eigentümers des Validator-Vertrags. Da die Brücke auf einem einzelnen EOA (Externally Owned Account) ohne Multi-Signatur- oder Time-Lock-Kontrollen basierte, gewährte der Besitz dieses Schlüssels die volle administrative Kontrolle. Unter Verwendung der upgrade()-Funktion des Vertrags übertrug der Angreifer das Eigentum an den Verträgen TokenSafe und MintPool an eine vom Angreifer kontrollierte Adresse. Dies ermöglichte die direkte Abhebung von Brückenreserven und das unbefugte Minten großer Mengen an CIOTX.

Angriffsanalyse

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

2. Nutzung des Validator-Vertrags, um das Eigentum an den Verträgen TokenSafe und MintPool zu übertragen.

3. Abzug von ca. 4,4 Mio. $ an Reserve-Assets (USDC, USDT, WBTC, WETH, BUSD usw.) aus TokenSafe und Minting von über 400 Mio. CIOTX über den MintPool.

4. Tausch der gestohlenen Reserve-Token und Bridging zu anderen Chains.

Fazit

Dieser Vorfall stellt ein klassisches Beispiel für eine Kompromittierung aufgrund eines Single-Point-of-Failure dar. Die gesamte Sicherheit der Brücke auf Ethereum-Seite beruhte auf einem einzelnen EOA mit voller administrativer Autorität und ohne Multi-Signatur-Schutz oder Time-Lock-Sicherheitsvorkehrungen. Sobald der private Schlüssel des EOA kompromittiert war, ging die Kontrolle über kritische Brückenkomponenten effektiv verloren.

Der Fall unterstreicht das Risiko zentralisierter administrativer Kontrolle und verdeutlicht, wie wichtig es ist, Upgrade- und Verwahrungsbefugnisse durch stärkere Governance-Mechanismen zu verteilen.

Ü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, Blockchain und Wallets), Angriffe in Echtzeit abzuwehren, Vorfälle zu analysieren, illicit Gelder aufzuspüren und AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg zu erfüllen.

BlockSec hat zahlreiche Blockchain-Sicherheitspapiere auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, zahlreiche Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Milliarden an Kryptowährungen abgesichert.

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

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

• 🔗 BlockSec Auditing Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance