In der vergangenen Woche (06.04.2026 - 12.04.2026) hat BlockSec vier Angriffsereignisse erkannt und analysiert, mit geschätzten Gesamtschäden von rund 928.600 US-Dollar. Die folgende Tabelle fasst diese Ereignisse zusammen, und detaillierte Analysen für jeden Fall sind in den folgenden Unterabschnitten aufgeführt.

*Das Denaria-Ereignis wurde im Bericht der letzten Woche nicht behandelt und ist hier zur Vollständigkeit aufgeführt.

Ab dieser Woche heben wir am Anfang jedes Berichts ein Ereignis hervor. Die Auswahl basiert nicht notwendigerweise auf der Schadenshöhe – sie kann aufgrund ihres neuartigen Protokolldesign, ihrer raffinierten Angriffstechnik oder ihrer breiteren Lektionen für die Community gewählt werden.

Wöchentliche Hervorhebung

Denaria-Ereignis

Der Perpetual DEX Denaria führte neuartige Buchhaltungsmechanismen ein, die auf komplexer Codlogik basieren. Dennoch führte eine Refactoring nach dem Audit zu einer Rundungsasymmetrie, die einen subtilen Sonderfall, einen negativen Wert, erzeugen konnte, der schließlich zu einer unsicheren Konvertierung führte und eine astronomische Wertextraktion ermöglichte.

Am 5. April 2026 wurde der Perpetual DEX von Denaria auf Linea für einen geschätzten Schaden von rund 165.600 US-Dollar ausgenutzt. Die Hauptursache waren zwei kumulative Fehler in getLpLiquidityBalance(): ein Refactoring nach dem Audit zur LP-Bilanzbuchhaltung führte zu einer Rundungsasymmetrie, die einen geringfügig negativen Zwischenwert erzeugen konnte, und eine unsichere Konvertierung von int256 zu uint256 wickelte diesen negativen Wert lautlos in eine fast maximale vorzeichenlose Ganzzahl um, anstatt abzubrechen. Der Angreifer nutzte dies durch eine einseitige LP-Einlage und einen Long-Trade aus und zog dann künstlich aufgeblähten PnL aus dem Tresor ab.

Hintergrund

Denaria ist ein Perpetual DEX auf Linea, der um einen dynamischen virtuellen AMM aufgebaut ist. Er trennt Handel und Abwicklung in zwei Komponenten. Der PerpPair-Markt verwaltet Benutzerpositionen und LP-Buchhaltung, während der Vault Sicherheiten hält und realisierte PnL abwickelt.

Die LP-Besitzrechte in PerpPair werden nicht durch eine explizite Token-Bilanz dargestellt. Stattdessen wird der Zustand jedes LP aus einer internen Buchhaltungsmatrix rekonstruiert, die aus zwei Buchführungskomponenten besteht, die hier als Aktivseite und Stablecoin-Seite bezeichnet werden. Die Aktivseite verfolgt den Anteil des LP an der Preisbewegung des Pools, während die Stablecoin-Seite seinen Anteil am Stablecoin-denominierten Wert des Pools verfolgt. Zusammen bestimmen diese beiden Komponenten, wie der Wert eines LP verfolgt und abgerechnet wird.

Entscheidend ist, dass diese Komponenten nicht als statische Schnappschüsse gespeichert werden. Jedes Mal, wenn ein Handel stattfindet, aktualisiert PerpPair seinen globalen Liquiditätszustand, und die rekonstruierte Bilanz jedes LP wird aus der Differenz zwischen kumulativen globalen Werten und dem Schnappschuss des Einstiegspunkts des LP abgeleitet. Dieser Buchhaltungsmechanismus wurde in einem Refactoring nach dem Audit eingeführt, das den ursprünglichen, auf Anteilen basierenden Akkumulator durch eine direkte Bilanzverfolgung ersetzte. Der refaktorierte subtraktive Pfad führte jedoch zu einer Rundungsasymmetrie, die dazu führen konnte, dass rekonstruierte LP-Komponenten unter bestimmten Handelssequenzen geringfügig negativ wurden.

Schwachstellenanalyse

Der anfällige PerpPair-Vertrag (0xb683...36ae17) enthält zwei kumulative Fehler.

1. Rundungsasymmetrie in der refaktorierten Buchhaltung. Das Refactoring nach dem Audit, das eine direkte Bilanzverfolgung einführte, schuf eine Rundungsasymmetrie im subtraktiven Rekonstruktionspfad. Unter bestimmten Handelssequenzen konnte der globale kumulative Wert nach Rundung geringfügig kleiner werden als der Schnappschuss des Einstiegspunkts des LP, was zur Folge hatte, dass die Subtraktion ein kleines negatives Ergebnis anstelle von Null lieferte. Theoretisch sollte dieser Wert Null oder nahe Null sein; die Asymmetrie war ein Fehler, der spezifisch für diese refaktorierte Implementierung war, und keine inhärente Eigenschaft der subtraktiven Buchhaltung im Allgemeinen.

   

2. Unsichere Konvertierung von vorzeichenbehaftet zu vorzeichenlos. In getLpLiquidityBalance() wurde eine rekonstruierte LP-Bilanzkomponente ohne Validierung von int256 zu uint256 konvertiert. In Solidity führt die Konvertierung eines negativen int256 zu uint256 nicht zum Abbruch; sie wickelt den Wert modulo 2^256 um und verwandelt eine kleine negative Zahl wie -1 in eine fast maximale vorzeichenlose Ganzzahl (2^256 - 1). Da diese rekonstruierte Bilanz für die Abwicklung in calcPnL() eingespeist wurde, würde jede negative Eingabe als enorme LP-Position interpretiert, was es einem Angreifer ermöglicht, einen künstlich aufgeblähten Gewinn zu realisieren und Gelder aus dem Tresor abzuschöpfen.

   

   

   Keiner der Fehler allein wäre ausnutzbar gewesen. Die Rundungsasymmetrie erzeugte nur einen geringfügig negativen Wert, der bei normaler int256-Arithmetik einfach einen vernachlässigbaren Fehler dargestellt hätte. Aber sobald dieser negative Wert die ungeschützte Konvertierung erreichte, wickelte er sich in eine fast maximale vorzeichenlose Ganzzahl. Eine anschließende Grenzprüfung begrenzte den umgewickelten Wert dann auf die gesamte Aktivseitliquidität des Pools, was den Überlauf effektiv in einen Anspruch auf die gesamte Aktivseite des Marktes umwandelte.

Angriffsanalyse

Die folgende Analyse basiert auf der Angriffstransaktion 0xcb0744...0c606447.

• Schritt 1: Der Angreifer lieh sich über einen Aave Flash Loan 60.000 USDC.

• Schritt 2: Eine Hilfsadresse hinterlegte 30.000 USDC als Sicherheit und fügte eine reine Stablecoin-LP-Position von 19.980 Stablecoins hinzu. Durch die Einzahlung nur auf der Stablecoin-Seite stellte die Hilfsadresse sicher, dass ihre Aktivseiten-LP-Komponente nahe Null begann, was sie anfälliger dafür machte, durch Rundung ins Negative zu geraten.

• Schritt 3: Eine zweite Hilfsadresse hinterlegte 15.000 USDC und eröffnete eine Long-Position von 100.000 notional, was eine liquidityM-Aktualisierung verursachte, die den entscheidenden Rundungsfehler einführte. Die große notionale Größe im Verhältnis zur Liquidität des Pools verstärkte den Rundungseffekt pro Handel und drückte die rekonstruierte Aktivseitenbilanz des ersten Hilfsadressaten leicht unter Null.

• Schritt 4: Die erste Hilfsadresse rief dann realizePnL() auf. Während der Rekonstruktion der LP-Bilanz wurde der negative lpAssetBalance in eine fast maximale uint256 umgewickelt. Dieser große Wert wurde dann auf die gesamte Aktivseitenliquidität des Marktes begrenzt und erzeugte einen stark aufgeblähten Gewinn. Tatsächlich glaubte das Protokoll, dass der LP die gesamte Aktivseite des Marktes besaß.

• Schritt 5: Der Angreifer zog den aufgeblähten PnL aus dem Tresor ab.

  

Das gleiche Muster wurde wiederholt, bis die verbleibende Tresorliquidität aufgebraucht war. Nach der Rückzahlung des Flash Loans erzielte der Angreifer einen Gewinn von rund 165.600 US-Dollar.

Schlussfolgerung

Dieser Exploit wurde letztendlich durch das Fehlen einer Grenzvalidierung bei einer Konvertierung von vorzeichenbehaftet zu vorzeichenlos verursacht. Die sofortige Korrektur ist unkompliziert: Ersetzen Sie die reine Konvertierung durch SafeCast.toUint256(), die bei negativer Eingabe abbricht und nicht umwickelt.

Im Allgemeinen veranschaulicht dieses Ereignis das Risiko von Refactorings nach dem Audit, die eine externe Überprüfung umgehen. Laut dem offiziellen Post-Mortem wurde die Rundungsasymmetrie nach dem endgültigen externen Audit eingeführt, als das Team den ursprünglichen Akkumulator durch eine direkte Bilanzverfolgung ersetzte. Während das Refactoring ein Überlaufproblem löste, schuf es einen neuen Sonderfall, den interne Tests nicht erfassten. Wenn Protokolle Kernbuchhaltungslogik refaktorisieren, sollte der neue Code-Pfad als sicherheitskritisch behandelt und neu auditiert werden, insbesondere wenn rekonstruierte Werte direkt in die PnL-Abwicklungs- oder Abhebelogik fließen.

Weitere Ereignisse diese Woche

HB Token-Ereignis

Am 7. April 2026 wurde HB, ein benutzerdefinierter ERC-20-Token mit eingebetteten Kauf-/Verkauf-Hooks auf BNB Chain, für rund 193.000 US-Dollar ausgenutzt. Die Hauptursache war eine fehlerhafte Logik zur Belohnungsabrechnung: Wenn ausgelöst, rief sie swapBack() auf, die HB-Reserven direkt aus dem PancakeSwap-Paar entfernte und dann sync() aufrief, um den Pool neu zu bewerten. Nachdem der Angreifer die meisten HB-Reserven des Paares aufgekauft hatte, reduzierte die anschließende swapBack()-Ausführung die verbleibende Liquidität weiter und blähte den Spotpreis drastisch auf. Der Angreifer verkaufte dann winzige Mengen HB in den verzerrten Pool gegen überproportional große Mengen USDT, wiederholte den Zyklus, bis das Paar erschöpft war.

Hintergrund

HB ist ein benutzerdefinierter ERC-20-Token auf BNB Chain mit Kauf- und Verkaufs-Hooks, die in _transfer() eingebettet sind. Wenn Benutzer vom AMM-Paar kaufen, zeichnet _handleBuy() Informationen zur Kostenbasis auf. Wenn Benutzer verkaufen, verzweigt _handleSell() je nach Zustand des Paares in verschiedene Steuer- und Abwicklungspfade.

Der Token beinhaltet auch einen Mechanismus zur Belohnungsabrechnung, der swapBack() auslösen kann. Anstatt einen normalen, vom Router vermittelten Swap durchzuführen, überträgt swapBack() HB direkt vom PancakeSwap-Paar an die PROOF-Adresse und zwingt dann das Paar zur Neusynchronisation über sync(). Dies ermöglicht es dem Vertrag, die HB-Reserven des Paares außerhalb der normalen AMM-Handelsflüsse zu reduzieren und den Pool sofort nach oben zu bewerten.

Schwachstellenanalyse

Der Kernfehler im HB-Token-Vertrag (0x62ce...87a4b0) war, dass swapBack() Belohnungen bezog, indem Token direkt aus dem AMM-Paar und nicht aus einer Schatzkammer oder über einen vom Router vermittelten Swap entnommen wurden. Da swapBack() über den Pfad zur Belohnungsabrechnung erreichbar war, konnte ein nicht-handelnder Code-Pfad Paarreserven direkt verändern und den Spotpreis beeinflussen.

Wenn die HB-Reserven des Paares niedrig sind, reduziert eine swapBack()-Aufruf die verbleibenden HB weiter und verstärkt die Preisverzerrung, was es ermöglicht, winzige Mengen HB zu extrem überhöhten Preisen zu verkaufen.

Angriffsanalyse

Die folgende Analyse basiert auf der Angriffstransaktion 0x19671f...d71594ed.

• Schritt 1: Der Angreifer lieh sich große Mengen an Geldern von Venus.

• Schritt 2: Der Angreifer übertrug ungefähr 1.496 HB in den Token-Vertrag, wodurch der HB-Saldo des Vertrags erhöht wurde, damit der nachfolgende swapBack()-Aufruf eine größere Menge aus dem Paar entnehmen konnte.

• Schritt 3: Durch die Übertragung einer winzigen Menge HB in das PancakeSwap-Paar löste der Angreifer _swapAndLiquify() aus, das etwa 4.163 vom Token-Vertrag gehaltene HB gegen 10 USDT tauschte und die beanspruchbaren HB-Belohnungen des Angreifers erhöhte.

  

• Schritt 4: Der Angreifer gab dann 72.117.360 USDT aus, um 73.608.753 HB zu kaufen, wodurch das Paar nur noch sehr wenig verbleibende HB-Liquidität hatte.

  

• Schritt 5: Als Nächstes löste der Angreifer den Pfad für das Belohnungsdefizit aus. Um die Belohnungen zu erfüllen, rief der Token swapBack() auf, das zusätzliche HB aus dem PancakeSwap-Paar entnahm und sync() zwang, wodurch der HB-Preis stark anstieg.

  

• Schritt 6: Der Angreifer übertrug direkt USDT in das Paar, um seine USDT-Reserven aufzufüllen, und verkaufte dann nur 0,000582 HB für 37.582.322 USDT zum verzerrten Preis.

Durch die Wiederholung von Schritt 6, um HB-Token zu einem verzerrten Preis zu verkaufen, entnahm der Angreifer fast alle USDT aus dem Pool.

Schlussfolgerung

Das HB-Token-Ereignis verdeutlicht, wie gefährlich es ist, Belohnungslogiken AMM-Reserven direkt manipulieren zu lassen. Reserven beeinflussende Funktionen sollten niemals von Belohnungsabrechnungspfaden aus erreichbar sein, und Protokolle sollten interne Token-Salden nicht mit AMM-Reservenbuchhaltung in sicherheitskritischen Kontrollflüssen verwechseln. Jedes Design, das auf Spot-AMM-Preisen nach interner Störung des Pools beruht, ist anfällig für Preismanipulation.

Squid Multicall-Ereignis

Am 7. April 2026 verlor ein Squid-Nutzer rund 517.000 US-Dollar über mehrere Ketten hinweg bei einem ereignisbezogenen Problem mit Genehmigungen. Der Benutzer genehmigte versehentlich einen SquidMulticall-Vertrag anstelle des beabsichtigten Squid Routers. Dies ermöglichte es dem Angreifer, eine erlaubnisfreie SquidMulticall.run()-Funktion aufzurufen, um willkürliche externe Aufrufe auszuführen. Der Angreifer konnte daher jede dem Vertrag erteilte Erlaubnis nutzen, um Token-transferFrom()-Aufrufe gegen Benutzer durchzuführen, die ihn genehmigt hatten.

Hintergrund

Im normalen Ablauf von Squid sollten Benutzer den Squid Router genehmigen, während SquidMulticall nur als Hilfsmittel zur Ausführung dient. Der Hilfsvertrag ist dafür konzipiert, gebündelte Aufrufe als Teil der Routing-Logik auszuführen, sollte aber nicht der Spender sein, den Benutzer direkt für Token-Überweisungen genehmigen.

Da ERC-20-Genehmigungsprüfungen nur gegen die Spenderadresse durchgeführt werden, schafft jeder Vertrag, der Benutzergenehmigungen mit uneingeschränkter willkürlicher Aufruffunktion kombiniert, eine gefährliche Genehmigungssenke: Sobald dieser Vertrag genehmigt ist, kann er zu einem generischen Token-Abhebungsvektor werden, wenn jeder steuern kann, welche Aufrufe er tätigt.

Schwachstellenanalyse

Dieses Ereignis wurde nicht durch eine Schwachstelle in einem Smart Contract verursacht. Der Verlust resultierte aus dem Zusammenwirken zweier Bedingungen: einer versehentlichen Genehmigung, die auf SquidMulticall statt auf den Router abzielte, und dem erlaubnisfreien Design von run(), das beliebige Ziele und Calldata von jedem Aufrufer akzeptierte.

SquidMulticall ist dazu bestimmt, gebündelte Aufrufe als nachgelagerten Schritt im Ablauf des Routers auszuführen, wobei die Eingaben durch vertrauenswürdige Routing-Logik konstruiert werden. Im beabsichtigten Gebrauch birgt das erlaubnisfreie Design keine Gefahr. Aber eine falsch platzierte Genehmigung ändert das radikal: Ein MEV-Bot erkannte die aktive Genehmigung, rief run() mit konstruiertem Calldata auf, um transferFrom(victim, attacker, amount) aufzurufen, und zog die genehmigten Token über jede Kette ab, ohne weitere Aktion vom Opfer.

Angriffsanalyse

Das Ereignis betraf einen Benutzer auf BNB Chain, Arbitrum, Optimism, Avalanche und Base. Die folgende Analyse basiert auf der Angriffstransaktion 0x81d0c4...9b1301e9.

• Schritt 1: Das Opfer (0xacc0...f40e98) genehmigte versehentlich SquidMulticall anstelle des beabsichtigten Squid Routers.

• Schritt 2: Ein MEV-Bot erkannte diese Genehmigung und rief SquidMulticall.run() mit konstruiertem Calldata auf.

• Schritt 3: Durch den willkürlichen Aufruf rief SquidMulticall transferFrom(victim, attacker, amount) auf und übertrug genehmigte Vermögenswerte aus dem Wallet des Opfers.

  

Schlussfolgerung

Dieses Ereignis veranschaulicht das Risiko von erlaubnisfreien Verträgen für willkürliche Aufrufe, die mit genehmigungsbasierten Abläufen für Benutzer koexistieren. Die unmittelbare Ursache war eine versehentliche Genehmigung, und da SquidMulticall uneingeschränkte Aufrufer, Ziele und Calldata akzeptierte, war jede versehentlich an ihn gerichtete Genehmigung sofort und vollständig ausnutzbar. Protokolle, die Hilfsverträge für die Ausführung verwenden, sollten die Prüfung von Aufruferbeschränkungen oder die Beschränkung der von solchen Funktionen zulässigen Aufrufziele in Betracht ziehen, damit eine falsch platzierte Genehmigung nicht trivial waffenfähig gemacht werden kann.

XBIT-Ereignis

Am 11. April 2026 wurde der XBIT-Token auf BNB Chain für rund 53.000 US-Dollar ausgenutzt. Die Hauptursache war ein offener Kontrollfehler bei der Zugriffssteuerung in XBITVault: Die Autorisierungsprüfung der transfer()-Funktion war bedingt – sie setzte msg.sender == xbitContract nur durch, wenn xbitContract nicht Null war, und schloss andernfalls lautlos. Da bindXBIT() nie aufgerufen wurde, um den Vertrag zu initialisieren, war dieser Fehler dauerhaft ausgesetzt und erlaubte willkürlichen Aufrufern, XBIT-Salden von jeder Adresse zu verschieben, einschließlich des XBIT/USDT PancakeSwap-Paares. Der Angreifer nutzte dies, um XBIT aus dem Paar abzuschöpfen, und verkaufte dann wiederholt winzige Mengen XBIT zurück in den Pool gegen überproportional große Mengen USDT.

Hintergrund

XBITVault ist kein passiver Tresorvertrag. Er ist das Saldo- und Genehmigungs-Backend für das XBIT-Tokensystem und bietet tokenähnliche Funktionen wie transfer(), approve() und mintForXBIT(). Nach dem beabsichtigten Design muss der Eigentümer zuerst bindXBIT() aufrufen, um den Tresor zu initialisieren, indem xbitContract, pancakePair, pairContract und xbitDecimals festgelegt werden. Nach der Initialisierung sollen sensible zustandsändernde Funktionen nur vom gebundenen XBIT-Vertrag aufrufbar sein. Mit anderen Worten, das Sicherheitsmodell des Tresors hängt von einer erfolgreichen Initialisierung vor der öffentlichen Nutzung ab.

Schwachstellenanalyse

Der kritische Fehler ist, dass die Zugriffskontrolle im anfälligen XBITVault-Vertrag (0xc879...42391a) bedingt ist. Die transfer()-Funktion prüft msg.sender == xbitContract nur, wenn xbitContract != address(0). Das bedeutet, dass die Funktion nicht abbricht, wenn xbitContract nicht gesetzt ist, und stattdessen für jeden öffentlich aufrufbar wird. Da die Salden in _balances gespeichert sind, kann jeder externe Aufrufer XBIT von jeder Adresse an jede andere Adresse verschieben, solange die Quelladresse über ein ausreichendes Guthaben verfügt.

Der vorgesehene Initialisierungspfad war bindXBIT(), aber da er nie aufgerufen wurde, blieb der Tresor in einem nicht initialisierten und offen stehenden Zustand. Das Ergebnis war effektiv ein uneingeschränktes primitives für die Übertragung von willkürlichen Salden.

Angriffsanalyse

Die folgende Analyse basiert auf der Angriffstransaktion 0xbc877f...4df1b694.

• Schritt 1: Über die uneingeschränkte transfer()-Funktion verschob der Angreifer 1.526.216,569 XBIT aus dem XBIT/USDT-Paar, ohne entsprechende USDT bereitzustellen.

• Schritt 2: Der Angreifer rief sync() auf, um die XBIT-Reserven des Paares auf nur 1-2 Einheiten zu reduzieren.

• Schritt 3: Nachdem das Paar mit nahezu null XBIT-Liquidität zurückgelassen wurde, verkaufte der Angreifer wiederholt XBIT und entnahm so rund 53.112 USDT aus dem Paar.

  

Schlussfolgerung

Dieses Ereignis wurde durch eine initialisierungsabhängige Zugriffskontrollprüfung verursacht, die offen abbrach. transfer() war uneingeschränkt, sobald xbitContract nicht gesetzt war, und da bindXBIT() nie aufgerufen wurde, exponierte der Tresor dauerhaft ein öffentliches primitives für die Übertragung von willkürlichen Salden. Privilegierte Funktionen sollten abbrechen, bis die Initialisierung abgeschlossen ist, und Bindungsschritte zum Zeitpunkt der Bereitstellung sollten als auf der Kette durchgesetzte Voraussetzungen und nicht als Betriebsannahmen gelten.