2025 war ein weiteres intensives Jahr für die Krypto-Sicherheit. Eine Reihe schwerwiegender Vorfälle erschütterte das Ökosystem und hinterließ echte Schäden, die Nutzer, Teams und Communities im gesamten Bereich betrafen. Auch wenn die Ergebnisse oft schmerzhaft waren, bestätigen sie eine bekannte Wahrheit: Sicherheit muss als Priorität erster Klasse behandelt werden.
Um der Community dabei zu helfen, aus den Vorfällen zu lernen, hat BlockSec zehn Vorfälle ausgewählt, die in diesem Jahr am stärksten hervorstachen. Diese Fälle wurden nicht nur aufgrund des Schadensausmaßes ausgewählt, sondern auch wegen der spezifischen Techniken, der unerwarteten Wendungen bei der Ausführung und der neuen oder wenig erforschten Angriffsflächen, die sie offenbarten.
In diesem Beitrag stellen wir die zehn größten Sicherheitsvorfälle des Jahres 2025 vor und erläutern, warum jeder einzelne Aufmerksamkeit verdient. Wir werden zudem für jeden Fall eine eigene vertiefende Analyse veröffentlichen, in der wir die Grundursache und den vollständigen Angriffspfad im Detail aufschlüsseln.
Cetus Vorfall: Der größte DeFi-Hack des Jahres 2025
Zusammenfassung
Am 22. Mai 2025 wurde das Cetus Protocol, die größte DEX für konzentrierte Liquidität auf Sui, gehackt, wobei geschätzte ~$223M an Liquidität aus mehreren Pools abgezogen wurden. Die Ursache war ein fehlerhafter Hilfsmechanismus zur Überlaufverhinderung (checked_shlw()) in der Festkomma-u256-Mathematik: Ein falscher Schwellenwert ermöglichte einen unsicheren Linksshift (<< 64), wodurch hohe Bits unbemerkt abgeschnitten wurden. Durch die gezielte Wahl der Liquiditätsgröße und enger Preisspannen brachte der Angreifer Cetus dazu, die erforderliche Token-Einzahlung als ~1 Einheit zu berechnen, während einer LP-Position enorme Liquidität gutgeschrieben wurde. Diese aufgeblähte Position wurde dann entfernt, um echte Reserven abzuziehen.
Grund für die Auswahl
Ein einziger falscher Vergleich in einem Festkomma-Hilfsprogramm reichte aus, um $223M zu entwenden. Der Angreifer manipulierte weder Oracles noch die Governance: Der gesamte Angriff beruhte auf rein arithmetischen Grenzfällen (Shift + Truncation), um nahezu kostenlose Liquidität zu erzeugen und echte Reserven deterministisch abzuziehen. Für jedes Protokoll, das auf der Mathematik konzentrierter Liquidität basiert, ist dieser Fall eine direkte Warnung, dass subtile Grenzfehler in low-level Festkommaoperationen zu einer Katastrophe 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 den Rechner eines Entwicklers von Safe{Wallet} 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 spezifisch auf Bybits Safe{Wallet}-Transaktionen ab und manipulierte deren Inhalt während des Signierungsprozesses. Die manipulierte Transaktion aktualisierte den Safe{Wallet}-Vertrag von Bybit auf eine bösartige Implementierung, wodurch der Angreifer alle im Vertrag gehaltenen Vermögenswerte abziehen konnte.
Grund für die Auswahl
Der größte Sicherheitsvorfall in der Krypto-Geschichte begann nicht mit einem Smart-Contract-Bug. Er begann mit einem kompromittierten Entwicklerrechner und einer manipulierten JavaScript-Datei in einem S3-Bucket. Der Angriffspfad verlief vollständig über Web2-Infrastruktur: Social Engineering, Cloud-Speicher und Frontend-Code-Injektion. Für eine Branche, die sich auf On-Chain-Sicherheit konzentriert, ist Bybit eine direkte Erinnerung daran, dass Betriebs- und Infrastruktursicherheit ebenso wichtig sind. Ein Multisig ist nur so sicher wie die Signierungsschnittstelle, der seine Besitzer 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 sowie mehrere geforkte Projekte über verschiedene Chains hinweg in einem koordinierten Angriff kompromittiert, was zu einem Gesamtschaden von über 125 Millionen US-Dollar führte. Die Ursache war ein Präzisionsverlust bei der Invariantenberechnung, welcher die Preisgestaltung der BPT (Balancer Pool Token) verfälschte. Der Angreifer nutzte diese Verzerrung in zwei Stufen aus: Zuerst manipulierte er den BPT-Preis durch einen präparierten Batch-Swap und zog anschließend Profit durch den Abzug von Vermögenswerten in einer separaten Transaktion.
Grund für die Auswahl
Im Gegensatz zu typischen Oracle-Manipulationsangriffen entstand dieser Exploit direkt in der Invariantenberechnung: Ein geringfügiger Präzisionsverlust in der Festkomma-Mathematik reichte aus, um die BPT-Preisgestaltung zu verzerren und den profitablen Abzug innerhalb einer einzigen Transaktion zu ermöglichen. Der Angriff verbreitete sich über mehrere Chains und betraf sowohl Balancer als auch seine Forks, was verdeutlicht, wie geteilte Codebasen das systemische Risiko in zusammensetzbarem DeFi (Composable DeFi) verstärken. Diskussionen der Community über die Grundursache waren oft zu stark vereinfacht. Die vollständige Analyse zeigt auf, wie sich ein Präzisionsverlust im Invarianten-Solver in ausnutzbare Preislücken übersetzt.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
GMX
Zusammenfassung
Am 9. Juli 2025 wurde GMX V1 auf Arbitrum um etwa 42 Millionen US-Dollar erleichtert. Der Angreifer löste eine Reentrancy-Schwachstelle aus, um den GLP-Preis während der Transaktion zu manipulieren, und nutzte dann diesen verzerrten Preis, um Vermögenswerte zu erwerben, die den Wert der Einlage bei weitem überstiegen. Durch wiederholte Ausnutzung entzog der Angreifer schrittweise die zugrunde liegenden Vermögenswerte aus den Liquiditätspools von GMX V1.
Grund für die Auswahl
Reentrancy ist eine der ältesten bekannten Schwachstellen in Smart Contracts, und dennoch brachte sie ein kampferprobtes Protokoll mit einem etablierten ACL-Modell zu Fall. Der nonReentrant-Modifikator im OrderBook-Kontrakt verhinderte zwar Reentrancy im selben Kontrakt, stoppte jedoch keine Cross-Contract-Aufrufe an den Vault während des Fallbacks. GMX V1 war jahrelang in Betrieb – eine Erfolgsbilanz, die ein falsches Sicherheitsgefühl erzeugen kann. Dieser Fall zeigt, dass Protokollreife kein Ersatz für eine systemweite Reentrancy-Analyse ist und dass Schutzmechanismen auf einzelner Kontraktebene nicht ausreichen, wenn mehrere Kontrakte einen veränderbaren Zustand teilen.
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 um über 9 Millionen US-Dollar erleichtert. Die Hauptursache war unsichere Arithmetik im Invarianten-Solver _calc_supply(), dessen Fehler beim Abrunden und Unterlauf für etwa ~$8,1M (90% der Verluste) verantwortlich waren. Eine sekundäre Schwachstelle, ein nicht deaktivierter Bootstrap-Pfad in add_liquidity(), ermöglichte weitere ~$0,9M, nachdem der primäre Exploit den Pool bereits geleert hatte.
Der Angreifer verfolgte eine Strategie in mehreren Phasen: Zuerst fügte er wiederholt Liquidität hinzu und entfernte sie, um ein extremes Ungleichgewicht in den virtuellen Beständen des Pools zu erzeugen; dann nutzte er die arithmetischen Fehler aus, um den Produktterm zum Zusammenbruch zu bringen und die Gesamtversorgung auf Null zu drücken; schließlich stieg er erneut in den Bootstrap-Initialisierungspfad ein, um via Unterlauf ~2,35e56 yETH zu minten und diese gegen reale Vermögenswerte im yETH-WETH Curve Pool einzutauschen.
Grund für die Auswahl
Der finanzielle Verlust war für 2025er-Verhältnisse moderat, aber die technische Komplexität des Exploits ist außergewöhnlich. Der Angriff verkettet numerische Grenzfälle mit Zustandsmaschinen-Re-Entry, was eine präzise Manipulation des On-Chain-Zustands in mehreren Phasen erforderte. Die vollständige Rekonstruktion des Exploits erfordert sowohl ein Verständnis der Low-Level-Arithmetik als auch der breiteren Zustandsübergänge. Die Kombination aus Subtilität, Gründlichkeit und didaktischer Tiefe macht diesen Vorfall zu einem der analytisch lohnendsten 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 gehackt, was zu Verlusten von etwa 12 Millionen US-Dollar führte. Die Ursache war eine Kombination aus HIYA-Preismanipulation nahe der Verfallszeit und fehlender Zugriffskontrolle in einem Uniswap v4 Hook-Callback. Da HIYA (Historical Implied Yield Average, eine Risikoprämien-Metrik zur Bepreisung neuer Marktausgaben) exponentiell ansteigt, je näher die Zeit bis zur Fälligkeit gegen Null geht, blähten Swaps in der späten Phase den HIYA-Wert auf und führten dazu, dass neu initialisierte Märkte ihre Cover Tokens massiv unterbewerteten. Gleichzeitig fehlte CorkHook.beforeSwap eine msg.sender-Authentifizierung, was beliebige Aufrufe mit präparierten Parametern ermöglichte. Durch Ausnutzung beider Schwachstellen extrahierte der Angreifer große Mengen an CT und DS und tauschte sie in wstETH um, wodurch die Protokollreserven leerte wurden.
Grund für die Auswahl
Weder die Preisgestaltung zur Verfallszeit noch der unauthentifizierte Hook-Callback waren für sich genommen katastrophal. Ihr Zusammenspiel war es jedoch. Die exponentielle HIYA-Prämie kurz vor Fälligkeit wirkte als ökonomischer Verstärker, und die fehlende msg.sender-Prüfung in CorkHook.beforeSwap gab dem Angreifer die Möglichkeit, dies mit beliebigen Parametern auszulösen. Dieser Fall veranschaulicht eine Klasse von Schwachstellen, die Audits einzelner Module leicht übersehen: Diskrepanzen bei Annahmen zwischen Modulen, bei denen ökonomisches Design und Zugriffskontrolle interagieren, um einen ausnutzbaren Pfad zu schaffen.
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 Nutzer-Wallets kompromittierte und zu Verlusten von 8,5 Millionen US-Dollar führte. Der Angreifer erlangte den API-Schlüssel für den Chrome Web Store von Trust Wallet und nutzte ihn, um über offizielle Kanäle eine mit einem Backdoor versehene Erweiterung (v2.68) zu veröffentlichen. Die bösartige Erweiterung entwendete die Seed-Phrasen der Nutzer an einen vom Angreifer kontrollierten Server. Anschließend leerte der Angreifer die betroffenen Wallets.
Grund für die Auswahl
Der Angreifer berührte zu keinem Zeitpunkt 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 so sowohl die manuelle Prüfung als auch den Standard-Release-Prozess. Nutzer hatten keinen Grund, dem Update zu misstrauen. Dies ist der einzige Wallet-Supply-Chain-Angriff in den Top 10 und deckt eine Risikokategorie auf, die On-Chain-Audits nicht abdecken können: die Sicherheit der Software-Bereitstellungskette zwischen dem Entwickler und dem Endnutzer.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
Bunni
Zusammenfassung
Am 2. September 2025 wurde Bunni V2 um 8,4 Millionen US-Dollar erleichtert, betroffen waren der USDC/USDT-Pool auf Ethereum und der weETH/ETH-Pool auf Unichain. Das Protokoll meldete am 23. Oktober 2025 Insolvenz an. Die Ursache war ein Rundungsfehler bei der Aktualisierung ungenutzter Pool-Bestände während der Liquiditätsentnahme, wodurch der Kontrakt seine eigene Gesamtliquidität unterbewertete.
Der Angreifer führte einen Angriff in drei Stufen durch: Zuerst manipulierte er den Pool-Preis, um das verfügbare Guthaben an USDC zu erschöpfen und den Rundungsfehler zu verstärken; anschließend führte er eine Serie kleiner Abhebungen durch, welche die Unterschätzung der Liquidität akkumulierten; schließlich führte er gerichtete Swaps aus, um die Differenz zwischen der vom Protokoll aufgezeichneten Liquidität und den tatsächlichen Reserven zu arbitrieren.
Grund für die Auswahl
Bunni V2 hatte mehrere Code-Audits durchlaufen, dennoch blieb ein kleiner Rundungsfehler bei der Abrechnung der ungenutzten Bestände unentdeckt. Der Fehler allein war pro Transaktion vernachlässigbar, doch der Angreifer verstärkte ihn durch wiederholte kleine Abhebungen, nachdem er zuvor den Pool-Zustand vorsätzlich verzerrt hatte. Dies verwandelte einen fraktionalen Präzisionsverlust in einen 8,4-Millionen-Dollar-Abfluss. Der Fall zeigt, wie Rundungsfehler, die isoliert betrachtet sicher erscheinen, ausnutzbar werden können, wenn ein Angreifer die Reihenfolge und Bedingungen ihrer Akkumulation kontrolliert.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
1inch
Zusammenfassung
Am 5. März 2025 wurde ein Drittanbieter-Resolver, der in 1inch Fusion V1 integriert war, aufgrund einer unsicheren Calldata-Rekonstruktion in _settleOrder() um über 5 Millionen US-Dollar erleichtert. Eine vom Angreifer kontrollierte interactionLength korrumpierte die im Speicher befindliche Zusammensetzung des dynamischen Suffixes, das zur Weitergabe der Resolver-Identität und des Ausführungskontexts verwendet wird, was die Injektion gefälschter Abwicklungsdaten ermöglichte. Da Resolver-Kontrakte blindlich auf Calldata vertrauten, die vom Settlement-Kontrakt allein aufgrund des msg.sender weitergeleitet wurden, passierte der gefälschte Kontext alle Zugriffskontrollprüfungen und führte zur unbefugten Extraktion von Vermögenswerten.
Grund für die Auswahl
Dieser Exploit verwischt die Grenze zwischen Schwachstellen in Smart Contracts und klassischer binärer Ausnutzung. Statt ökonomische Annahmen oder Geschäftslogik zu missbrauchen, basiert der Angriff auf Zeigerarithmetik, ungeprüften Längenfeldern und der Annahme über das Layout des ABI-Speichers – Muster, die eher von nativen Software-Exploits wie Pufferüberläufen und Integer-Unterläufen bekannt sind. Er zeigt, wie Low-Level-Manipulationen von Calldata und Speicher klassische Exploitation-Primitive in On-Chain-Systeme zurückbringen können, besonders wenn sie mit impliziten Vertrauensketten zwischen Kontrakten 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, bei der etwa 400.000 US-Dollar an gefährdeten Geldern gesichert wurden. Die Ursache war ein Fehler in der Konstruktion von s_positionsHash im Kontrakt: 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 gesamten Fingerabdruck (die XOR-Summe der Hashes) unsicher, sodass unterschiedliche Positionsmengen identische Hashes erzeugen können.
Grund für die Auswahl
Die meisten Vorfälle in dieser Liste sind auf arithmetische Fehler oder fehlende Zugriffskontrollen zurückzuführen. Die Schwachstelle bei Panoptic ist anders: Es handelt sich um einen kryptografischen Designfehler auf der Ebene der Datenstruktur. Das Protokoll verließ sich auf XOR, um Positions-Fingerabdrücke zu erstellen, unter der Annahme, dass das Ergebnis die Kollisionsresistenz der zugrunde liegenden Keccak256-Hashes erben würde. Dies ist nicht der Fall. Aufgrund der Linearität von XOR kann ein Angreifer unterschiedliche Positionsmengen konstruieren, die identische s_positionsHash-Werte erzeugen, wodurch Abrechnungsinvarianten umgangen werden. Die erfolgreiche Whitehat-Rettung verhinderte Verluste, aber der zugrunde liegende Mangel ist eine nützliche Erinnerung daran, dass Hash-Komposition dieselbe Sorgfalt erfordert wie die Hash-Funktion selbst.
Erfahren Sie mehr über die Grundursache und die Angriffsschritte im Detail.
