Wöchentlicher Web3-Sicherheitsvorfall-Rundown | 9. – 15. Feb 2026

Im Laufe der letzten Woche (9. bis 15. Februar 2026) hat BlockSec drei Angriffsereignisse mit geschätzten Gesamtschäden von rund 657.000 US-Dollar erkannt und analysiert. Die folgende Tabelle fasst diese Vorfälle zusammen, und detaillierte Analysen für jeden Fall werden in den folgenden Unterabschnitten bereitgestellt.

1. Unbekannter Vorfall

Kurze Zusammenfassung

Am 10. Februar 2026 wurde der Smart Contract 0x560d39 auf der BNB Smart Chain ausgenutzt, was zu einem geschätzten Schaden von ~10.000 US-Dollar führte. Die Grundursache war eine fehlerhafte Geschäftslogik in der Funktion 0xb1a87f2c(), die den Prozess der Liquiditätszuführung anfällig für einen Sandwich-Angriff machte.

Hintergrund

Im Smart Contract 0x560d39 überträgt die Funktion 0xb1a87f2c() basierend auf dem Eingabeparameter einen entsprechenden Betrag von USDT vom Benutzer. Die empfangenen USDT werden verarbeitet, und 85 % des Gesamtbetrags werden für nachfolgende Liquiditätsoperationen verwendet.

Von diesem 85 %-Anteil wird die Hälfte über einen PancakeSwap-Pool in AFX getauscht, und der erworbene AFX wird an den Smart Contract 0x671ce4 übertragen. Die Funktion zieht dann AFX aus 0x671ce4 ab.

Anschließend werden über den PancakeSwap V2 Router die verbleibende Hälfte der 85 % USDT und der aus 0x671ce4 abgezogene AFX verwendet, um Liquidität für das USDT-AFX-Handelspaar zu schaffen. Alle verbleibenden USDT oder AFX werden dem Benutzer zurückerstattet.

Nach Abschluss der Liquiditätszuführung für USDT-AFX zieht die Funktion zusätzliche AFX von der Adresse 0x146933 ab. Der aus 0x146933 abgezogene Betrag wird so eingestellt, dass er dem Betrag von AFX entspricht, der zuvor aus 0x671ce4 abgezogen wurde. Anschließend berechnet die Funktion den erforderlichen AHT-Betrag basierend auf dem aktuellen Preisverhältnis im PancakeSwap V2 AFX-AHT-Pool und verwendet den aus 0x146933 abgezogenen AFX zusammen mit dem berechneten AHT, um Liquidität für das AFX-AHT-Handelspaar zu schaffen.

Schwachstellenanalyse

Der anfällige Smart Contract ist 0x560d39. Der Smart Contract 0x146933 dient als Finanzierungsquelle für den AFX, der für die AFX-AHT-Liquiditätszuführung verwendet wird und letztendlich den Verlust trägt.

Die Grundursache liegt in der fehlerhaften Geschäftslogik der Funktion 0xb1a87f2c() in 0x560d39. Beim Abrufen des durch Tausch von USDT über den Smart Contract 0x671ce4 erhaltenen AFX prüft die Funktion nicht die Saldoänderung von AFX in 0x671ce4 vor und nach dem Tausch. Stattdessen zieht sie den gesamten von 0x671ce4 gehaltenen AFX ab.

Dies ermöglicht es einem Angreifer, im Voraus einen großen Betrag an AFX an 0x671ce4 zu spenden und dann 0xb1a87f2c() mit nur einem kleinen Betrag an USDT aufzurufen. Da der aus 0x146933 abgezogene AFX-Betrag so eingestellt ist, dass er dem aus 0x671ce4 abgezogenen AFX entspricht, zwingt die Inflationierung des Abzugs aus 0x671ce4 0x146933 dazu, einen überhöhten Betrag an AFX in die AFX-AHT-Liquiditätszuführung einzubringen.

Der Angreifer kann seine Spende durch Rückerstattungen von verbleibenden USDT und AFX aus 0x560d39 zurückerhalten, während 0x146933 die Kosten für die übermäßige Liquiditätsbereitstellung trägt.

Der Angreifer profitiert dann, indem er die AFX-AHT-Liquiditätszuführung sandwichartig einschließt, indem er mit einem AFX-zu-AHT-Tausch vorausgreift und mit einem AHT-zu-AFX-Tausch um die Transaktion des Opfers herum nachläuft.

Angriffsanalyse

Die wichtigsten Schritte der Angriffstransaktion werden wie folgt zusammengefasst:

• Schritt 1: Der Angreifer hat über PancakeSwap V2 1.130.500e18 AFX-Token per Flashloan aufgenommen.

• Schritt 2: Der Angreifer hat 511.965e18 AFX an den Smart Contract 0x671ce4 übertragen.

  

• Schritt 3: Der Angreifer verwendete die verbleibenden AFX, um im AFX-AHT-Pool auf PancakeSwap V2 52.316e18 AHT zu tauschen. Da AHT ein Token mit Gebühren beim Transfer ist, erhielt der Angreifer letztendlich nur 26.158e18 AHT.

  

• Schritt 4: Der Angreifer rief den Smart Contract 0x560d39 auf und führte die Funktion 0xb1a87f2c() mit dem Parameter 100 aus. Da die Funktion den gesamten AFX von 0x671ce4 (einschließlich der vom Angreifer gespendeten Token) abzoch, versuchte sie, übermäßig große Mengen an Liquidität sowohl für die USDT-AFX- als auch für die AFX-AHT-Paare bereitzustellen. Alle verbleibenden USDT und AFX, die nicht gepaart werden konnten, wurden dem Angreifer zurückerstattet, wodurch er den größten Teil seiner Kosten zurückgewinnen konnte.

• Schritt 5: Der Angreifer tauschte 26.158e18 AHT gegen 1.129.417e18 AFX.

  

• Schritt 6: Der Angreifer zahlte den Flashloan zurück und tauschte die verbleibenden AFX gegen USDT, wodurch er rund 10.000 US-Dollar Gewinn erzielte.

Schlussfolgerung

Dieser Vorfall wurde durch den Smart Contract 0x560d39 verursacht, der beim Abrufen des durch Tausch von USDT erhaltenen AFX direkt den gesamten AFX aus dem Smart Contract 0x671ce4 abzieht, ohne die Änderung des AFX-Saldos von 0x671ce4 vor und nach dem Tausch zu überprüfen.

2. OCA-Vorfall

Kurze Zusammenfassung

Am 14. Februar 2026 erlitt ein unbekanntes Protokoll auf der BNB Smart Chain eine Ausnutzung, die zu einem Schaden von ~422.000 US-Dollar führte. Die Grundursache war eine fehlerhafte Geschäftslogik: Nach Abschluss eines Tauschs ruft das Protokoll eine Wiederaufbereitungsfunktion im OCA-Token-Vertrag auf, um Token vom DEX abzurufen und sie an den Aufrufer und andere bestimmte Adressen zurückzugeben. Dieser einseitige Abzug von OCA-Token reduziert künstlich die OCA-Reserven des Pools, bläht dessen On-Chain-Preis auf und ermöglicht es einem Angreifer, wiederholt USDC aus dem Pool abzuziehen.

Hintergrund

Der Protokollvertrag (0xe0d5ec) stellt eine Funktion sellOCA() (Selektor 0x9c1dad28) bereit, die einen vom Benutzer festgelegten OCA-Betrag gegen USDC an einem DEX verkauft. OCA beinhaltet einen deflationären „Wiederaufbereitungsmechanismus“: Nach dem Tausch zieht der Vertrag den gleichen OCA-Betrag, der gerade in den Pool verkauft wurde, zurück und verteilt ihn an den Aufrufer und andere bestimmte Adressen. Da der OCA nach Auszahlung des USDC aus dem Pool entfernt wird, sinken die OCA-Reserven des Pools, während seine USDC-Reserven niedriger bleiben, was den On-Chain-Preis von OCA künstlich in die Höhe treibt.

Schwachstellenanalyse

Die Kernschwachstelle besteht darin, dass die Nach-Tausch-Rückforderung in sellOCA() einen wiederholbaren Preismanipulationsmechanismus schafft. Jede Ausführung hat folgende Nettoauswirkung auf den DEX-Pool: Der Pool verliert USDC während des Tauschs und verliert auch OCA, wenn der deflationäre Mechanismus Token aus dem Pool zurückfordert, während der Aufrufer die USDC-Erlöse erhält und OCA durch die Umverteilung zurückerhält. Da die OCA-Reserven des Pools ohne entsprechenden USDC-Zufluss zur Bilanzierung des Handels reduziert werden, bläht jeder Zyklus den OCA/USDC-Preis am DEX künstlich auf. Ein Angreifer kann diesen Prozess wiederholen, indem er OCA kauft, sellOCA() aufruft, um die Rückforderung auszulösen, und dann den zurückgeforderten OCA zum aufgeblähten Preis verkauft, wodurch die USDC-Liquidität zunehmend aus dem Pool abgezogen wird.

Angriffsanalyse

Die wichtigsten Schritte der Angriffstransaktion werden wie folgt zusammengefasst:

• Schritt 1: 8.704.860e18 USDC wurden per Flashloan aufgenommen.

• Schritt 2: 8.704.860e18 USDC wurden gegen 940.991e18 OCA auf PancakeSwap getauscht.

  

• Schritt 3: sellOCA() wurde mit allen 940.991e18 OCA aufgerufen. Die Funktion tauschte die OCA gegen USDC am DEX, dann zog der deflationäre Wiederaufbereitungsmechanismus die verkauften OCA aus dem Pool zurück und verteilte sie erneut – wodurch OCA an den Aufrufer zurückgegeben wurde. Infolgedessen erhielt der Angreifer USDC-Erlöse aus dem Tausch und erhielt gleichzeitig seine OCA-Token zurück. Die OCA-Reserven des Pools fielen stark ab, was den OCA-Preis aufblähte.

  

• Schritt 4: Die zurückgeforderten 940.991e18 OCA wurden zum nun aufgeblähten Preis zurück in USDC auf PancakeSwap getauscht, und die Schritte 2–4 wurden wiederholt, um den Pool schrittweise zu leeren.

• Schritt 5: In der letzten Iteration tauschte der Angreifer nur 9.999e18 OCA gegen 433.238e18 USDC (was den massiv aufgeblähten OCA-Preis widerspiegelt), zahlte dann den Flashloan zurück, um den Exploit abzuschließen.

  

Schlussfolgerung

Die grundlegende Ursache dieses Exploits war ein Logikfehler im sellOCA-Fluss des Protokolls: Nach dem Tausch von vom Benutzer bereitgestelltem OCA gegen USDC zog der Vertrag im Wesentlichen den gesamten eingegebenen OCA-Betrag über den „Wiederherstellungsmechanismus“ des OCA-Tokens vom DEX zurück und verteilte ihn an den Aufrufer und andere bestimmte Adressen. Diese Nach-Tausch-Rückforderung reduzierte künstlich den im Liquiditätspool verbleibenden OCA-Saldo, was zu einem starken Anstieg des On-Chain-Preises von OCA führte. Durch wiederholtes Zyklieren von „OCA kaufen → sellOCA aufrufen, um die Rückforderung auszulösen → OCA zum aufgeblähten Preis zurückverkaufen“ konnte der Angreifer fast die gesamte USDC-Liquidität gegen relativ wenig OCA extrahieren.

3. SOF-Vorfall

Kurze Zusammenfassung

Am 14. Februar 2026 wurde der SOF-Token auf der BNB Smart Chain ausgenutzt, was zu einem Schaden von ~225.000 US-Dollar führte. Die Grundursache war eine fehlerhafte Geschäftslogik in der Funktion _update(): Bei einem Verkaufsvorgang überwies der Vertrag Token direkt vom Uniswap V2-Paar an eine Burn-Adresse und rief sofort sync() auf. Diese Manipulation der Pool-Reserven blähte den Token-Preis innerhalb derselben Transaktion künstlich auf. Der Angreifer konstruierte eine Tauschtransaktion, die diese fehlerhafte Verkaufslogik auslöste, wodurch das Liquiditätspaar gezwungen wurde, seine eigenen Token zu verbrennen und die Reserven zu aktualisieren, wodurch die USDT des Pools zu einem künstlich aufgeblähten Preis abgezogen wurden.

Hintergrund

SOF ist ein BEP-20-Token, der auf der BNB Smart Chain eingesetzt wird und über benutzerdefinierte deflationäre Mechanismen und automatisiertes Gebührenmanagement verfügt. Der Token interagiert mit einem Uniswap V2-kompatiblen Liquiditätspaar (insbesondere PancakeSwap mit USDT), um den Handel zu erleichtern.

Für gebührenbefreite Benutzer sind Kauf- und Verkaufsoperationen kostenlos. Für alle anderen Benutzer sind Kaufoperationen eingeschränkt und werden rückgängig gemacht.

Bei Verkaufsoperationen überträgt der Vertrag 90 % des Verkaufsvolumens vom Paar an eine _destroyAddress (Burn-Adresse) direkt und ruft sync() auf, um die Reserven zu aktualisieren und den reduzierten Saldo sofort widerzuspiegeln.

Schwachstellenanalyse

Die Grundursache ist eine fehlerhafte Geschäftslogik in der Funktion _update() des 0x1f3863 Vertrags. Während eines Verkaufs (wenn to das Uniswap-Paar ist) führt der Vertrag Zeile 467 aus:

 ///  SOF.sol:462-469
462|          } else if (_isPairs[to]) {
463|              //sell
464|
465|              isSell = true;
466|              taxAmount = takeFee(from, amount);
467|              super._update(_uniswapV2Pair, _destroyAddress, amount - taxAmount);
468|              IUniswapV2Pair(_uniswapV2Pair).sync();
469|          }

Diese Logik überträgt Token direkt von der Uniswap-Paaradresse an die Burn-Adresse (_destroyAddress), wodurch die Token-Reserven des Liquiditätspools geleert werden. Der anschließende Aufruf von IUniswapV2Pair(_uniswapV2Pair).sync() aktualisiert sofort die Reserven, was zu einem Preisanstieg des Tokens führt und es dem Angreifer ermöglicht, die USDT des Pools abzuziehen.

Angriffsanalyse

Die wichtigsten Schritte der Angriffstransaktion werden wie folgt zusammengefasst:

• Schritt 1: Der Angreifer hat für Schritt 2 315.520.309e18 USDT per Flashloan aufgenommen und 875e18 SOF an die Adresse 0xc4DB5B übertragen, um Schritt 3 vorzubereiten.

• Schritt 2: 313.567.718e18 USDT wurden gegen 991.223e18 SOF über swapTokensForExactTokens() getauscht. Die to-Adresse war eine gebührenbefreite Adresse, was die Prüfung isExcludedFromFees[to] im SOF-Vertrag erfüllte und somit die Prüfung _isPairs[from] übersprang (andernfalls wäre der Kauf rückgängig gemacht worden). Dies umging auch die Prüfung _antiFlashloanGuard() – der Vertrag erfasste diesen Kauf nicht, was es Schritt 3 ermöglichte, fortzufahren, ohne blockiert zu werden. Entscheidend ist, dass dieser massive Kauf so konzipiert wurde, dass das Paar nur noch 787e18 SOF (neben 313.816.344e18 USDT) besaß. Dies bereitete Schritt 3 vor: Die 90%ige Verbrennung in der Verkaufslogik würde fast den gesamten verbleibenden SOF-Saldo des Paares vernichten.

• Schritt 3: Von der Adresse 0xc4DB5B wurden 875e18 SOF gegen USDT über swapExactTokensForTokensSupportingFeeOnTransferTokens() getauscht. Der PancakeSwap Router V2 führt zuerst SOF.transferFrom() aus und verarbeitet dann den Tausch. Während SOF.transferFrom() überträgt die Verkaufslogik in _update() 90 % von 875e18 (d. h. 787e18) vom Paar an _destroyAddress – was, wie in Schritt 2 konzipiert, fast der gesamte SOF-Saldo des Paares war. Nach dieser Verbrennung und dem sync() enthielt das Paar 313.816.344e18 USDT und nur noch 10e9 SOF. Da der SOF-Preis nun astronomisch aufgebläht war, ergab der anschließende Tausch eine massive USDT-Auszahlung.

• Schritt 4: Der Angreifer zahlte den Flashloan zurück und behielt den Gewinn von rund 225.000 US-Dollar.

Schlussfolgerung

Der SOF-Vorfall verdeutlicht das Risiko der Manipulation von AMM-Pool-Reserven innerhalb der Token-Transferlogik. Der Verkaufsablauf entfernte Token aus dem Saldo des Uniswap-Paares und rief sofort sync() auf. Als swapExactTokensForTokensSupportingFeeOnTransferTokens() ausgeführt wurde, änderten die Überweisungen an das Paar die Reserven, bevor der Tausch abgeschlossen war, was die Preisgestaltung verzerrte und eine Extraktion ermöglichte.

Die Funktion _antiFlashloanGuard() bot ebenfalls keinen wirksamen Schutz. Sie beschränkt nur Käufe und Verkäufe für dieselbe Benutzeradresse, und der Angreifer umging sie, indem er den Kauf an einen gebührenbefreiten Empfänger leitete.

Um ähnliche Probleme zu mildern, sollten Sie Transfer-Hooks oder _update()-Logiken vermeiden, die Token von einer Paaradresse verschieben oder sync() aufrufen. Wenn ein Anti-Flashloan-Schutz erforderlich ist, erzwingen Sie eine transaktionsweite Regel, indem Sie tx.origin zusammen mit relevanten Adressen verfolgen, damit Angreifer Käufe und Verkäufe nicht in einer Transaktion über verschiedene Empfänger aufteilen können.

Über BlockSec

BlockSec ist ein Anbieter von Blockchain-Sicherheit und Krypto-Compliance im Full-Stack-Bereich. 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 renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hackerangriffe 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