Wöchentliche Web3-Sicherheitsvorfall-Zusammenfassung | 6. – 12. April 2026

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

*Der Denaria-Vorfall wurde im Bericht der letzten Woche nicht behandelt und ist zur Vollständigkeit hier enthalten.

Ab dieser Woche heben wir einen Vorfall am Anfang jedes Berichts hervor. Die Auswahl basiert nicht unbedingt auf der Höhe des Schadens – sie kann aufgrund ihres neuartigen Protokolldesign, ihrer cleveren Angriffstechnik oder ihrer breiteren Lehren für die Community gewählt werden.

Wöchentliche Hervorhebung: Denaria Vorfall

Die Perpetual DEX Denaria führte neuartige Buchhaltungsmechanismen ein, die auf komplexer Code-Logik basieren. Dennoch führte eine Refaktorierung nach dem Audit zu einer Rundungsasymmetrie, die einen subtilen Grenzfall, einen negativen Wert, erzeugen konnte, der schließlich zu einer unsicheren Typumwandlung führte und eine astronomische Wertentnahme ermöglichte.

Am 5. April 2026 wurde Denarias Perpetual DEX auf Linea für Verluste von rund 165.600 US-Dollar ausgenutzt. Die Ursache waren zwei sich überlappende Fehler in getLpLiquidityBalance(): Eine Refaktorierung der LP-Guthabenbuchhaltung nach dem Audit führte eine Rundungsasymmetrie ein, die einen leicht negativen Zwischenwert erzeugen konnte, und eine unsichere Umwandlung von int256 in uint256 wandelte diesen negativen Wert stillschweigend in eine fast maximale vorzeichenlose Ganzzahl um, anstatt einen Fehler auszulösen. Der Angreifer nutzte dies durch eine einseitige LP-Einlage und einen Long-Trade aus, zog dann künstlich aufgeblähte PnLs aus dem Tresor ab.

Hintergrund

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

LP-Eigentum in PerpPair wird nicht durch einen expliziten Token-Saldo repräsentiert. Stattdessen rekonstruiert das Protokoll den Zustand jedes LP aus einer internen Buchhaltungsmatrix, die aus zwei Buchhaltungskomponenten besteht, die hier als Aktiva-Seite und stabile Seite bezeichnet werden. Die Aktiva-Seite verfolgt den Anteil des LP an der Preisbewegung des Pools, während die stabile Seite seinen Anteil am stabilen 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 der rekonstruierte Saldo jedes LP wird aus der Differenz zwischen kumulativen globalen Werten und dem Einstiegsschnappschuss des LP abgeleitet. Dieser Buchhaltungsmechanismus wurde in einer Refaktorierung nach dem Audit eingeführt, die den ursprünglichen, auf Anteilen basierenden Akkumulator durch eine direkte Saldoverfolgung ersetzte. Der refaktorierte subtraktive Pfad führte jedoch eine Rundungsasymmetrie ein, die rekonstruierte LP-Komponenten unter bestimmten Handelssequenzen leicht negativ werden lassen konnte.

Schwachstellenanalyse

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

1. Rundungsasymmetrie in der refaktorieren Buchhaltung. Die Refaktorierung nach dem Audit, die eine direkte Saldoverfolgung einführte, schuf eine Rundungsasymmetrie im subtraktiven Rekonstruktionspfad. Unter bestimmten Handelssequenzen konnte der globale kumulative Wert nach der Rundung geringfügig kleiner sein als der Einstiegsschnappschuss des LP, was dazu führte, dass die Subtraktion ein kleines negatives Ergebnis anstelle von Null ergab. Theoretisch sollte dieser Wert Null oder nahe Null sein; die Asymmetrie war ein Fehler, der spezifisch für diese refaktorierte Implementierung war, nicht eine inhärente Eigenschaft der subtraktiven Buchhaltung im Allgemeinen.

   

2. Unsichere Vorzeichenbehaftet-zu-Vorzeichenlos-Umwandlung. In getLpLiquidityBalance() wurde eine rekonstruierte LP-Saldo-Komponente ohne Validierung von int256 in uint256 umgewandelt. In Solidity löst die Umwandlung eines negativen int256 in uint256 keinen Fehler aus; sie wickelt den Wert modulo 2^256, wodurch eine kleine negative Zahl wie -1 in eine fast maximale vorzeichenlose Ganzzahl (2^256 - 1) umgewandelt wird. Da dieser rekonstruierte Saldo für die Abrechnung in calcPnL() verwendet wurde, würde jeder negative Eingabewert als enorme LP-Position interpretiert werden, was es einem Angreifer ermöglichen würde, einen künstlich aufgeblähten Gewinn zu erzielen und Gelder aus dem Tresor abzuziehen.

   

   

   Kein einzelner Fehler allein wäre ausnutzbar gewesen. Die Rundungsasymmetrie erzeugte nur einen leicht negativen Wert, der unter normaler int256-Arithmetik einfach einen vernachlässigbaren Fehler darstellen würde. Aber sobald dieser negative Wert die unbewachte Umwandlung erreichte, wickelte er sich in eine fast maximale vorzeichenlose Ganzzahl ein. Eine anschließende Bereichsprüfung begrenzte den umgewandelten Wert auf die gesamte Aktiva-Liquidität des Pools und wandelte den Überlauf effektiv in einen Anspruch auf die gesamte Aktiva-Seite des Marktes um.

Angriffsanalyse

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

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

• Schritt 2: Eine Hilfsadresse zahlte 30.000 USDC als Sicherheit ein und fügte eine reine stabile LP-Position von 19.980 Stable-Tokens hinzu. Durch die Einzahlung nur auf der stabilen Seite stellte die Hilfsadresse sicher, dass ihre Aktiva-seitige LP-Komponente nahe Null begann, wodurch sie anfälliger dafür wurde, durch Rundung in den negativen Bereich zu geraten.

• Schritt 3: Eine zweite Hilfsadresse zahlte 15.000 USDC ein und eröffnete eine Long-Position von 100.000 Nennwert, was eine liquidityM-Aktualisierung verursachte, die den entscheidenden Rundungsfehler einführte. Die große Nominallänge im Verhältnis zur Liquidität des Pools verstärkte die Rundungsauswirkung pro Handel und drückte den rekonstruierten Aktiva-seitigen Saldo der ersten Hilfsadresse leicht unter Null.

• Schritt 4: Die erste Hilfsadresse rief dann realizePnL() auf. Während der Rekonstruktion des LP-Saldos wurde der negative lpAssetBalance in eine fast maximale uint256 umgewandelt. Dieser große Wert wurde dann auf die gesamte Aktiva-seitige Liquidität des Marktes begrenzt und generierte einen stark aufgeblähten Gewinn. Effektiv glaubte das Protokoll, dass der LP die gesamte Aktiva-Seite des Marktes besaß.

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

  

  Das gleiche Muster wiederholte sich, bis die verbleibende Tresorliquidität erschöpft war. Nach Rückzahlung des Flash-Loans erzielte der Angreifer einen Gewinn von rund 165.600 US-Dollar.

Fazit

Dieser Exploit wurde letztendlich durch fehlende Bereichsprüfung bei einer Vorzeichenbehaftet-zu-Vorzeichenlos-Konvertierung verursacht. Die sofortige Korrektur ist unkompliziert: Ersetzen Sie die nackte Umwandlung durch SafeCast.toUint256(), die bei negativem Input fehlschlägt, anstatt ihn zu verpacken.

Im breiteren Sinne veranschaulicht dieser Vorfall das Risiko von Refaktorierungen nach dem Audit, die eine externe Überprüfung umgehen. Laut dem offiziellen Post-Mortem wurde die Rundungsasymmetrie nach dem abschließenden externen Audit eingeführt, als das Team den ursprünglichen Akkumulator durch eine direkte Saldoverfolgung ersetzte. Während die Refaktorierung ein Überlaufproblem löste, schuf sie einen neuen Grenzfall, den interne Tests nicht erfassten. Wenn Protokolle Kernbuchhaltungslogiken refaktorieren, sollte der neue Code-Pfad als sicherheitskritisch behandelt und neu auditiert werden, insbesondere wenn rekonstruierte Werte direkt in die PnL-Abrechnungs- oder Auszahlungslogik einfließen.

HB Token Vorfall

Am 7. April 2026 wurde HB, ein benutzerdefinierter ERC-20-Token mit integrierten Kauf-/Verkaufs-Hooks auf der BNB Chain, für rund 193.000 US-Dollar ausgenutzt. Die Ursache 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 Ausführung von swapBack() die verbleibende Liquidität weiter und blähte den Spotpreis stark auf. Der Angreifer verkaufte dann winzige Mengen HB in den verzerrten Pool für überproportional große Mengen USDT, wiederholte den Zyklus, bis das Paar erschöpft war.

Hintergrund

HB ist ein benutzerdefinierter ERC-20-Token auf der 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() in verschiedene Steuer- und Abwicklungspfade, abhängig vom Zustand des Paares.

Der Token enthält auch einen Belohnungsabrechnungsmechanismus, der swapBack() auslösen kann. Anstatt einen normalen, von einem Router vermittelten Tausch durchzuführen, überträgt swapBack() HB direkt vom PancakeSwap-Paar an die PROOF-Adresse und erzwingt dann, dass das Paar über sync() neu synchronisiert wird. Dies ermöglicht es dem Vertrag, die HB-Reserven des Paares außerhalb der normalen AMM-Handelsflüsse zu verringern und den Pool sofort nach oben neu zu bewerten.

Schwachstellenanalyse

Der Kernfehler im HB-Tokenvertrag (0x62ce...87a4b0) war, dass swapBack() Belohnungen aus dem AMM-Paar direkt bezog und nicht aus einer Kasse oder über einen von einem Router vermittelten Tausch. Da swapBack() über den Belohnungsabrechnungspfad erreichbar war, konnte ein Nicht-Handelspfad die 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, wodurch es möglich wird, winzige Mengen HB zu extrem überhöhten Preisen zu verkaufen.

Angriffsanalyse

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

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

• Schritt 2: Der Angreifer überwies etwa 1.496 HB in den Tokenvertrag, wodurch der HB-Saldo des Vertrags erhöht wurde, damit die anschließende swapBack() einen größeren Betrag vom Paar abziehen 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 Tokenvertrag 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 des Belohnungsfehlbetrags aus. Um die Belohnungen zu erfüllen, rief der Token swapBack() auf, das zusätzliche HB aus dem PancakeSwap-Paar zog und sync() zwang, was den HB-Preis stark erhöhte.

  

• Schritt 6: Der Angreifer überwies 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.

Fazit

Der Vorfall mit dem HB-Token verdeutlicht, wie gefährlich es ist, Belohnungslogik direkt die AMM-Reserven verändern zu lassen. Reserven beeinflussende Funktionen sollten niemals von Belohnungsabrechnungspfaden aus erreichbar sein, und Protokolle sollten interne Token-Salden nicht mit der AMM-Reservenbuchhaltung in sicherheitskritischen Kontrollflüssen vermischen. Jedes Design, das auf Spot-AMM-Preise angewiesen ist, nachdem der Pool intern gestört wurde, ist anfällig für Preismanipulation.

Squid Multicall Vorfall

Am 7. April 2026 verlor ein Squid-Benutzer auf mehreren Ketten rund 517.000 US-Dollar in einem Genehmigungs-bezogenen Vorfall. Der Benutzer erteilte versehentlich einem SquidMulticall-Vertrag anstelle des beabsichtigten Squid-Routers eine Genehmigung. Dies ermöglichte es dem Angreifer, eine erlaubnisfreie Funktion SquidMulticall.run() aufzurufen, um beliebige externe Aufrufe auszuführen. Der Angreifer konnte somit jede an den Vertrag genehmigte Berechtigung nutzen, um Token-transferFrom()-Aufrufe gegen Benutzer auszuführen, die ihn genehmigt hatten.

Hintergrund

Im normalen Ablauf von Squid sollten Benutzer den Squid-Router genehmigen, während SquidMulticall nur als Ausführungshelfer fungiert. Der Helfervertrag ist dafür konzipiert, Batch-Aufrufe als Teil der Routing-Logik auszuführen, aber er sollte 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 beliebiger Aufruffunktion kombiniert, ein gefährliches Genehmigungs-Sink: Sobald dieser Vertrag genehmigt ist, kann er zu einem generischen Token-Abhebungsvektor werden, wenn irgendjemand steuern kann, welche Aufrufe er tätigt.

Schwachstellenanalyse

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

SquidMulticall ist dazu bestimmt, Batch-Aufrufe als nachgelagerten Schritt im Ablauf des Routers auszuführen, wo Eingaben durch vertrauenswürdige Routing-Logik konstruiert werden. Bei bestimmungsgemäßer Verwendung birgt das erlaubnisfreie Design kein Risiko. Eine fehlplatzierte Genehmigung ändert dies jedoch vollständig: Ein MEV-Bot erkannte die aktive Genehmigung, rief run() mit konstruierten Calldata auf, um transferFrom(victim, attacker, amount) aufzurufen, und zog die genehmigten Token über jede Kette ab, ohne weitere Maßnahmen des Opfers.

Angriffsanalyse

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

• Schritt 1: Das Opfer (0xacc0...f40e98) erteilte versehentlich SquidMulticall anstelle des beabsichtigten Squid-Routers eine Genehmigung.

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

• Schritt 3: Über den beliebigen Aufruf rief SquidMulticall transferFrom(victim, attacker, amount) auf und überwies genehmigte Vermögenswerte aus dem Wallet des Opfers.

  

Fazit

Dieser Vorfall veranschaulicht das Risiko, dass erlaubnisfreie Verträge für beliebige Aufrufe mit benutzerorientierten Genehmigungsflüssen koexistieren. Die unmittelbare Ursache war eine versehentliche Genehmigung, und da SquidMulticall uneingeschränkte Aufrufer, beliebige Ziele und beliebige Calldata akzeptierte, war jede versehentlich an ihn gerichtete Genehmigung sofort und vollständig ausnutzbar. Protokolle, die Ausführungshelferverträge verwenden, sollten erwägen, Aufruferbeschränkungen hinzuzufügen oder die von solchen Funktionen erlaubten Aufrufziele einzuschränken, damit eine fehlplatzierte Genehmigung nicht trivial als Waffe eingesetzt werden kann.

XBIT Vorfall

Am 11. April 2026 wurde der XBIT-Token auf der BNB Chain für rund 53.000 US-Dollar ausgenutzt. Die Ursache war ein Fail-Open-Zugriffskontrollfehler in XBITVault: Die Autorisierungsprüfung der transfer()-Funktion war bedingt – sie erzwang msg.sender == xbitContract nur, wenn xbitContract nicht null war, und bestand andernfalls stillschweigend. Da bindXBIT() nie aufgerufen wurde, um den Vertrag zu initialisieren, war dieser Fehler permanent aufgedeckt, was es beliebigen Aufrufern ermöglichte, XBIT-Salden von jeder Adresse zu verschieben, einschließlich des XBIT/USDT PancakeSwap-Paares. Der Angreifer nutzte dies, um XBIT aus dem Paar abzuziehen, und verkaufte dann wiederholt winzige Mengen XBIT zurück in den Pool gegen überproportional große Mengen USDT.

Hintergrund

XBITVault ist kein passiver Tresorvertrag. Es ist das Backend für Salden und Genehmigungen des XBIT-Tokensystems und bietet tokenähnliche Funktionen wie transfer(), approve() und mintForXBIT(). Im Rahmen des beabsichtigten Designs muss der Eigentümer zuerst bindXBIT() aufrufen, um das Vault zu initialisieren, indem er xbitContract, pancakePair, pairContract und xbitDecimals setzt. Nach der Initialisierung sollten sicherheitsrelevante zustandsändernde Funktionen nur vom gebundenen XBIT-Vertrag aufrufbar sein. Mit anderen Worten, das Sicherheitsmodell des Vault 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 fehlschlägt, wenn xbitContract nicht gesetzt ist, und stattdessen von jedem ö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 ausreichende Guthaben verfügt.

Der vorgesehene Initialisierungspfad war bindXBIT(), aber da er nie aufgerufen wurde, blieb das Vault in einem nicht initialisierten und offenbleibenden Zustand. Das Ergebnis war effektiv ein uneingeschränktes primitives für beliebige Saldoübertragungen.

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 entsprechendes 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 fast keine XBIT-Liquidität mehr hatte, verkaufte der Angreifer wiederholt XBIT und zog rund 53.112 USDT aus dem Paar ab.

  

Fazit

Dieser Vorfall wurde durch eine Initialisierungsabhängige Zugriffskontrolle verursacht, die offen blieb. transfer() war uneingeschränkt, wenn xbitContract nicht gesetzt war, und da bindXBIT() nie aufgerufen wurde, exponierte das Vault dauerhaft ein öffentliches primitives zur Übertragung beliebiger Salden. Privilegierte Funktionen sollten zurücktreten, bis die Initialisierung abgeschlossen ist, und bindende Schritte zur Bereitstellungszeit sollten als On-Chain-erzwungene Voraussetzungen und nicht als betriebliche Annahmen behandelt werden.

Ü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 Nachverfolgung illegaler Gelder und der Erfüllung von AML/CFT-Verpflichtungen während des gesamten Lebenszyklus von Protokollen und Plattformen unterstützen.

BlockSec hat mehrere Veröffentlichungen zur Blockchain-Sicherheit auf angesehenen Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe von DeFi-Anwendungen gemeldet, zahlreiche Hackerangriffe blockiert, um mehr als 20 Millionen Dollar zu retten, und Kryptowährungen im Wert von mehreren Milliarden Dollar gesichert.

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

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

• 🔗 BlockSec Audit-Service: Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance