2025 war ein weiteres intensives Jahr für die Krypto-Sicherheit. Eine Reihe von Vorfällen mit erheblichen Auswirkungen erschütterte das Ökosystem und hinterließ reale Schäden, die Nutzer, Teams und Communities in diesem Bereich betrafen. Auch wenn die Ergebnisse oft schmerzhaft waren, bekräftigt jedes Ereignis auch eine bekannte Wahrheit: Sicherheit muss als erstklassige Priorität behandelt werden.
Um der Community zu helfen, aus den Geschehnissen zu lernen, hat BlockSec zehn Vorfälle ausgewählt, die in diesem Jahr am meisten herausragten. Diese Fälle wurden nicht nur aufgrund des Ausmaßes des Verlusts ausgewählt, sondern auch wegen der beteiligten spezifischen Techniken, der unerwarteten Wendungen bei der Ausführung und der neuen oder unerforschten Angriffsflächen, die sie aufdeckten.
In diesem Beitrag beleuchten wir die zehn wichtigsten Sicherheitsvorfälle des Jahres 2025 und erläutern, warum jeder einzelne Beachtung verdient. Außerdem werden wir für jeden Fall eine eigene Nachbereitung veröffentlichen, in der die Grundursache und der vollständige Angriffsverlauf im Detail erläutert werden.
Cetus-Vorfall: Der größte DeFi-Hack des Jahres 2025
Zusammenfassung
Am 22. Mai 2025 wurde das Cetus Protocol, der größte DEX mit konzentrierter Liquidität auf Sui, für geschätzte ~223 Millionen US-Dollar ausgenutzt, als die Liquidität aus mehreren Pools abgezogen wurde. Die Grundursache war eine fehlerhafte Helper-Funktion (checked_shlw()) zur Vermeidung von Überläufen bei Festkomma-u256-Mathematik: Ein falscher Schwellenwert erlaubte einen unsicheren Links-Shift von << 64, der die oberen Bits stillschweigend abschnitt. Durch sorgfältige Auswahl der Liquiditätsgröße und enger Tick-Bereiche ließ der Angreifer Cetus berechnen, dass die erforderliche Token-Einlage ~1 Einheit beträgt, während er eine LP-Position mit enormer Liquidität gutschrieb. Anschließend wurde diese aufgeblähte Position entfernt, um reale Reserven abzuziehen.
Grund der Auswahl
Ein einziger falscher Vergleich in einem Festkomma-Helper reichte aus, um 223 Millionen US-Dollar abzuzocken. Der Angreifer manipulierte weder Orakel noch nutzte er die Governance aus: Der gesamte Angriff beruhte auf reinen arithmetischen Randfällen (Shift + Trunkierung), um nahezu kostenlose Liquidität zu erzeugen und reale Reserven deterministisch abzuziehen. Für jedes Protokoll, das auf konzentrierter Liquiditätsmathematik basiert, ist dieser Fall eine direkte Warnung, dass stille Grenzfehler bei Low-Level-Festkommaoperationen zu katastrophalen Folgen auf Protokollebene führen können.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
Bybit: Der größte Hack des Jahres 2025
Zusammenfassung
Am 21. Februar 2025 verlor Bybit etwa 1,5 Milliarden US-Dollar, nachdem ein Angreifer die Maschine eines Safe{Wallet}-Entwicklers durch Social Engineering kompromittiert hatte. Mit diesem Zugriff injizierte der Angreifer bösartigen JavaScript-Code in den AWS S3-Bucket von Safe{Wallet}. Der injizierte Code zielte speziell auf die Safe{Wallet}-Transaktionen von Bybit ab und manipulierte den Transaktionsinhalt während des Signaturvorgangs. Die manipulierte Transaktion aktualisierte den Safe{Wallet}-Vertrag von Bybit auf eine bösartige Implementierung, die es dem Angreifer ermöglichte, alle vom Vertrag gehaltenen Vermögenswerte abzuziehen.
Grund der Auswahl
Der größte Sicherheitsvorfall in der Krypto-Geschichte begann nicht mit einem Smart Contract-Fehler. Er begann mit einer kompromittierten Entwicklermaschine und einer manipulierten JavaScript-Datei in einem S3-Bucket. Der Angriffsvektor verlief vollständig über Web2-Infrastruktur: Social Engineering, Cloud-Speicher und Front-End-Code-Injektion. Für eine Branche, die sich auf On-Chain-Sicherheit konzentriert, ist Bybit eine direkte Erinnerung daran, dass operative Sicherheit und Infrastruktursicherheit gleichermaßen unerlässlich sind. Ein Multisig ist nur so sicher wie die Signaturoberfläche, der seine Eigentümer vertrauen.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
Balancer V2
Zusammenfassung
Am 3. November 2025 wurden die Composable Stable Pools von Balancer V2 und mehrere davon abgeleitete Projekte auf mehreren Chains in einem koordinierten Angriff ausgenutzt, was zu Gesamtverlusten von über 125 Millionen US-Dollar führte. Die Grundursache war ein Präzisionsverlust bei der Berechnung der Invariante, der die BPT (Balancer Pool Token)-Bewertung verzerrte. Der Angreifer nutzte diese Verzerrung aus, um sich durch gezielte Batch-Swaps Profit aus ausgewählten Stable Pools zu verschaffen.
Grund der Auswahl
Im Gegensatz zu typischen Angriffen auf Orakel-Manipulationen stammte dieser Exploit aus der Invariantenberechnung selbst: Ein geringer Präzisionsverlust in der Festkomma-Mathematik reichte aus, um die BPT-Bewertung zu verzerren und profitable Einzeltransaktionsentnahmen zu ermöglichen. Der Angriff breitete sich auf mehrere Chains aus und betraf sowohl Balancer als auch seine Forks, was zeigt, wie gemeinsam genutzte Codebasen das systemische Risiko in der komponierbaren DeFi verstärken. Die Diskussion in der Community über die Grundursache vereinfachte oft die Mechanik. Die vollständige Analyse verfolgt, wie sich Präzisionsverluste im Invariantenlöser in ausnutzbare Preisunterschiede übersetzen.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
GMX
Zusammenfassung
Am 9. Juli 2025 wurde GMX V1 auf Arbitrum für rund 42 Millionen US-Dollar ausgenutzt. Der Angreifer löste eine Reentrancy-Schwachstelle aus, um den GLP-Preis mitten in einer Transaktion zu manipulieren, und nutzte dann den verzerrten Preis, um Vermögenswerte zu erwerben, die weit über den hinterlegten Wert hinausgingen. Durch wiederholte Ausnutzung zog der Angreifer nach und nach zugrunde liegende Vermögenswerte aus den Liquiditätspools von GMX V1 ab.
Grund der Auswahl
Reentrancy ist eine der ältesten bekannten Smart Contract-Schwachstellen, dennoch hat sie ein kampferprobtes Protokoll mit einem etablierten ACL-Modell zu Fall gebracht. Der Modifier nonReentrant auf dem OrderBook-Vertrag verhinderte Reentrancy innerhalb desselben Vertrags, aber er verhinderte keine Cross-Contract-Aufrufe an die Vault während des Fallbacks. GMX V1 war seit Jahren live, eine Erfolgsbilanz, die ein falsches Sicherheitsgefühl erzeugen kann. Dieser Fall zeigt, dass die Reife eines Protokolls kein Ersatz für eine systemweite Reentrancy-Analyse ist und dass einzelne Vertragsschutzmechanismen unzureichend sind, wenn mehrere Verträge gemeinsam genutzte, veränderliche Zustände haben.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
Yearn Finance
Zusammenfassung
Am 30. November 2025 wurde der yETH Weighted Stable Pool von Yearn Finance für über 9 Millionen US-Dollar ausgenutzt. Die primäre Grundursache waren unsichere Berechnungen im Invariantenlöser _calc_supply(), dessen Rundungsfehler nach unten und Unterlauf-Fehler unabhängig voneinander für rund 8,1 Millionen US-Dollar (90 % der Verluste) verantwortlich waren. Eine sekundäre Schwachstelle, ein nicht deaktivierter Bootstrap-Pfad in add_liquidity(), ermöglichte zusätzliche rund 0,9 Millionen US-Dollar, nachdem der primäre Exploit den Pool bereits geleert hatte.
Der Angreifer führte eine mehrphasige Strategie durch: Zuerst fügte er wiederholt Liquidität hinzu und entfernte sie, um eine extreme Unwucht in den virtuellen Salden des Pools zu erzeugen. Dann nutzte er die arithmetischen Fehler aus, um den Produktterm zu kollabieren und die Gesamtsumme auf Null zu reduzieren. Schließlich re-enterte er den Bootstrap-Initialisierungspfad, um über einen Unterlauf ~2,35e56 yETH zu prägen und diese im yETH-WETH Curve-Pool gegen reale Vermögenswerte zu tauschen.
Grund der Auswahl
Der finanzielle Verlust war nach den Maßstäben von 2025 moderat, aber die technische Komplexität des Exploits ist außergewöhnlich. Der Angriff verknüpft numerische Randfälle (Divisionenkollaps, Vorzeichenwechsel im Invariantenlöser) mit Zustandsmaschinen-Re-Entry (erneutes Auslösen der Pool-Initialisierung nach der Bereitstellung), was eine präzise mehrphasige Manipulation des On-Chain-Zustands erfordert. Die vollständige Rekonstruktion des Exploits erfordert das Verständnis sowohl der Low-Level-Arithmetik als auch der übergeordneten Zustandsübergänge. Die Kombination aus Subtilität, Rigorosität und didaktischer Tiefe macht diesen Fall zu einem der analytisch lohnendsten Vorfälle des Jahres.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
Cork Protocol
Zusammenfassung
Am 28. Mai 2025 wurde das Cork Protocol auf Ethereum ausgenutzt, was zu Verlusten von rund 12 Millionen US-Dollar führte. Die Grundursache war eine Kombination aus der Manipulation des HIYA-Preises zum Ablaufdatum und fehlender Zugriffskontrolle in einem Uniswap v4 Hook-Callback. Da die HIYA-Risikoprämien mit Annäherung des Verfallsdatums an Null exponentiell ansteigen, blähten späte Swaps die HIYA auf und führten dazu, dass neu initialisierte Märkte Cover Tokens stark unterbewerteten. Gleichzeitig fehlte in CorkHook.beforeSwap die msg.sender-Authentifizierung, was beliebige Aufrufe mit speziell erstellten Parametern ermöglichte. Durch die Ausnutzung beider Fehler zog der Angreifer große Mengen CT und DS ab und tauschte sie zurück in wstETH, wobei er die Protokollreserven leerte.
Grund der Auswahl
Weder die Preiskurve zum Ablaufdatum noch der nicht authentifizierte Hook-Callback waren einzeln katastrophal. Ihre Interaktion war es. Die exponentielle HIYA-Prämie nahe dem Verfallsdatum schuf einen wirtschaftlichen Verstärker, und die fehlende msg.sender-Prüfung in CorkHook.beforeSwap gab dem Angreifer eine Möglichkeit, diese mit beliebigen Parametern auszulösen. Dieser Fall veranschaulicht eine Klasse von Schwachstellen, die einzelne Modulprüfungen wahrscheinlich übersehen werden: Annahmenungleichgewichte zwischen Modulen, bei denen wirtschaftliches Design und Zugriffskontrolle interagieren, um einen ausnutzbaren Pfad zu erzeugen.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
Trust Wallet
Zusammenfassung
Am 25. Dezember 2025 erlitt Trust Wallet einen Supply-Chain-Angriff, der über 2.000 Benutzer-Wallets kompromittierte und zu Verlusten von 8,5 Millionen US-Dollar führte. Der Angreifer erlangte den API-Schlüssel von Trust Wallet für den Chrome Web Store und nutzte ihn, um eine Backdoor-Erweiterung (v2.68) über offizielle Kanäle zu veröffentlichen. Die bösartige Erweiterung exfiltrierte Benutzer-Seed-Phrasen an einen vom Angreifer kontrollierten Server. Der Angreifer zog dann Gelder von den kompromittierten Wallets ab.
Grund der Auswahl
Der Angreifer berührte nie einen Smart Contract. Durch die Kompromittierung eines einzigen API-Schlüssels veröffentlichte er eine bösartige Erweiterung über den offiziellen Vertriebskanal von Trust Wallet und umging damit sowohl die manuelle Überprüfung als auch den Standard-Release-Prozess. Die Benutzer hatten keinen Grund, dem Update zu misstrauen. Dies ist der einzige Wallet-Supply-Chain-Angriff unter den Top 10 und deckt eine Risikokategorie auf, die On-Chain-Prüfungen nicht abdecken können: die Sicherheit der Software-Lieferkette zwischen dem Entwickler und dem Endbenutzer.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
Bunni
Zusammenfassung
Am 2. September 2025 wurde Bunni V2 für 8,4 Millionen US-Dollar im USDC/USDT-Pool auf Ethereum und im weETH/ETH-Pool auf Unichain ausgenutzt. Das Protokoll erklärte später am 23. Oktober 2025 den Bankrott. Die Grundursache war ein Rundungsfehler bei der Aktualisierung der Idle-Pool-Guthaben bei der Liquiditätsentnahme, der dazu führte, dass der Vertrag seine eigene Gesamtlusss unterschätzte.
Der Angreifer führte einen dreistufigen Angriff durch: Zuerst manipulierte er den Poolpreis, um das verfügbare USDC-Guthaben zu erschöpfen und den Rundungsfehler zu verstärken. Dann führte er eine Reihe kleiner Entnahmen durch, die die Unterschätzung der Liquidität akkumulierten. Schließlich führte er gerichtete Swaps durch, um die Lücke zwischen der vom Protokoll ausgewiesenen Liquidität und seinen tatsächlichen Reserven zu arbitrieren.
Grund der Auswahl
Bunni V2 hatte mehrere Code-Audits durchlaufen, dennoch wurde ein geringfügiger Rundungsfehler bei der Verbuchung der Idle-Guthaben unentdeckt gelassen. Der Fehler allein war pro Transaktion vernachlässigbar, aber der Angreifer verstärkte ihn durch wiederholte kleine Entnahmen, nachdem er bewusst den Poolzustand verzerrt hatte, und verwandelte einen Bruchteil des Präzisionsverlusts in einen Abfluss von 8,4 Millionen US-Dollar. Der Fall zeigt, wie Rundungsfehler, die isoliert sicher erscheinen, ausnutzbar werden können, wenn ein Angreifer die Reihenfolge und die Bedingungen kontrolliert, unter denen sie sich ansammeln.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
1inch
Zusammenfassung
Am 5. März 2025 wurde ein Drittanbieter-Resolver, der mit 1inch Fusion V1 integriert war, aufgrund unsicherer Calldata-Rekonstruktion in _settleOrder() für über 5 Millionen US-Dollar ausgenutzt. Ein vom Angreifer kontrollierter interactionLength-Wert beschädigte die In-Memory-Zusammenstellung des dynamischen Suffixes, das zur Weitergabe der Resolver-Identität und des Ausführungskontexts verwendet wurde, und ermöglichte die Injektion gefälschter Abwicklungsdaten. Da die Resolver-Verträge die vom Settlement-Vertrag weitergeleiteten Calldata ausschließlich aufgrund von msg.sender implizit vertrauten, bestand der gefälschte Kontext alle Zugriffskontrollprüfungen und führte zur unbefugten Entnahme von Vermögenswerten.
Grund der Auswahl
Dieser Exploit verwischt die Grenze zwischen Smart Contract-Schwachstellen und traditioneller Binärausnutzung. Anstatt wirtschaftliche Annahmen oder High-Level-Geschäftslogik zu missbrauchen, stützt sich der Angriff auf Zeigerarithmetik, ungeprüfte Längenfelder und Annahmen über das ABI-Speicherlayout, Muster, die häufiger bei nativen Software-Exploits wie Buffer Overflows und Pointer Underflows zu sehen sind. Er zeigt, wie Low-Level-Calldata- und Speicher-Manipulationen klassische Exploitation-Primitive in On-Chain-Systeme zurückbringen können, insbesondere wenn sie mit impliziten Vertrauenskettchen zwischen Verträgen kombiniert werden.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
Panoptic
Zusammenfassung
Am 25. August 2025 führte Panoptic mit Unterstützung von Cantina und Seal911 eine Whitehat-Rettungsaktion durch und sicherte rund 400.000 US-Dollar an gefährdeten Geldern. Die Grundursache war ein Fehler in der Konstruktion von s_positionsHash durch den Vertrag: die Verwendung von XOR zur Aggregation von Keccak256-Hash-Ergebnissen. Während eine einzelne Hash-Funktion kollisionsresistent bleibt, macht die mathematische Linearität von XOR den Gesamt-Fingerabdruck (die XOR-Summe der Hashes) unsicher und erlaubt es, dass unterschiedliche Positionsmengen identische Hashes erzeugen.
Grund der Auswahl
Die meisten Vorfälle in dieser Liste lassen sich auf arithmetische Fehler oder fehlende Zugriffskontrollen zurückführen. Die Schwachstelle von Panoptic ist anders: Es handelt sich um einen kryptografischen Designfehler auf Ebene der Datenstruktur. Das Protokoll verließ sich auf XOR, um Positions-Fingerabdrücke zu erstellen, in der Annahme, dass das Ergebnis die Kollisionsresistenz der zugrunde liegenden Keccak256-Hashes erben würde. Das tut es aber nicht. Die Linearität von XOR bedeutet, dass ein Angreifer unterschiedliche Positionsmengen konstruieren kann, die identische s_positionsHash-Werte erzeugen und so Buchhaltungs-Invarianten umgehen. Die erfolgreiche Whitehat-Rettung verhinderte Verluste, aber der zugrunde liegende Fehler ist eine nützliche Erinnerung daran, dass Hash-Komposition die gleiche Sorgfalt erfordert wie die Hash-Funktion selbst.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
