Die Sicherheitsverletzung war ein Infrastrukturfehler. Angreifer erlangten Zugriff auf die GitHub-Zugangsdaten eines Auftragnehmers und drangen schließlich in den AWS Key Management Service von Resolv ein, um den privaten SERVICE_ROLE-Schlüssel zu entwenden. Mit diesem Schlüssel umging der Angreifer die Minting-Limits, um Token gegen minimale Sicherheiten auszugeben, extrahierte etwa 24,5 Millionen USD in ETH und verursachte ein heftiges Depegging von USR. Dieses Ereignis löste eine sekundäre Ansteckung im gesamten DeFi-Sektor aus, was zu uneinbringlichen Forderungen für Protokolle wie Morpho und Fluid führte.

Eine technische Fehlkonfiguration in Aaves CAPO löste Liquidationen bei gesunden Konten aus. Der Vorfall wurde durch eine Parameter-Abweichung zwischen dem snapshotRatio und dem snapshotTimestamp des Protokolls verursacht, was dazu führte, dass Wrapped Staked Ether (wstETH) um etwa 2,85 % unterbewertet wurde. Automatisierte Bots verarbeiteten 10.938 wstETH an Liquidationen und generierten einen Gewinn von rund 512 ETH für die Liquidatoren. Chaos Labs und die Aave DAO haben sich zu einer vollständigen Rückerstattung für die betroffenen Nutzer verpflichtet. Zukünftige Präventionsmaßnahmen konzentrieren sich auf die Implementierung obligatorischer Transaktionssimulationen und On-Chain-Plausibilitätsprüfungen, um sicherzustellen, dass die Risikoparameter mit der Marktrealität übereinstimmen.

Der Angreifer nutzte eine Design-Schwachstelle in der swap()-Funktion aus, die beliebige Executor-Aufrufe zuließ, was zum Diebstahl von Nutzern führte, die unbegrenzte Genehmigungen erteilt hatten.

Die vermutlich durchgesickerten Signaturschlüssel des Validators und ein Flash-Loan ermöglichten es dem Angreifer, exklusive Stimmrechte zu erlangen. Nachdem der Angreifer die Kontrolle über die Validatoren erlangt hatte, nutzte er in demselben Block Brückenfonds, um BONE zu kaufen, es für die Validatorenbefugnis zu delegieren, betrügerische Checkpoints zu signieren und dann das „Darlehen“ mit den gestohlenen Vermögenswerten zurückzuzahlen.

Der Angreifer nutzte einen kompromittierten privaten Schlüssel von einem Proxy-Administrator-Konto, um einen Smart Contract auf eine bösartige Version zu aktualisieren. Anschließend nutzte der Angreifer die bösartige Version des Smart Contracts, um das Guthaben des Vertrags selbst sowie die Wallets der Benutzer, die diesen Smart Contract genehmigt hatten, zu leeren.

Unautorisierter Zugriff auf die Kiln-API, einem Staking-Partner von SwissBorg, führte zum Diebstahl von 41,5 Millionen US-Dollar aus dem SOL-Earn-Staking-Programm. Die Angreifer manipulierten die Berechtigungen der Staking-Konten, ohne dass eine Multi-Signatur-Bestätigung erforderlich war. Dies ermöglichte es ihnen, die Autorität stillschweigend zu übertragen, während sie die Rolle des Withdrawer beibehielten, was ihnen half, die Standard-Überwachungstools zu umgehen, die sich auf Auszahlungsereignisse konzentrieren. Der Verstoß war ein Off-Chain-API-Exploit, der den Angreifern die Kontrolle über On-Chain-Assets verschaffte.

Ein Nemo-Entwickler hat eine neue, ungeprüfte Funktion in die Codebasis eingeführt, nachdem das erste Sicherheitsaudit bereits stattgefunden hatte, aber bevor der endgültig überarbeitete Bericht fertiggestellt war. Folglich wurde eine Version des Vertrags, die diesen ungeprüften Code enthielt, im Mainnet bereitgestellt. Die Governance-Grundursache lag in der Abhängigkeit des Protokolls von einer Einzel-Signatur-Adresse für Upgrades, was die Bereitstellung von Code, der keiner gründlichen Sicherheitsüberprüfung unterzogen worden war, nicht verhindern konnte. Zusätzlich hat der Entwickler eine andere Version des Codes bereitgestellt als die, die von der Prüfgesellschaft bestätigt wurde. Ein Angreifer nutzte diese ungeprüften Funktionen aus, um den internen Zustand zu manipulieren und erfolgreich eine beträchtliche Menge an Vermögenswerten aus dem Liquiditätspool abzuziehen.

Die Angreifer nutzten einen bösartigen Zoom-Client, um sich Privilegien auf dem Computer des Opfers zu verschaffen. Diesen Zugriff nutzten sie, um das Opfer dazu zu bringen, eine Transaktion zu genehmigen, die den Angreifer als legitimen Venus-Delegierten für ihr Konto autorisierte. Dadurch konnte der Angreifer in ihrem Namen Kredite aufnehmen und einlösen.

Angreifer verschafften sich Zugang zu einer Multisig-Wallet mit 32 Millionen AIO-Tokens. Die Gelder wurden verschoben und gegen 2 Millionen Dollar getauscht.

Der Angreifer nutzte eine Schwachstelle im Connector-Vertrag aus, der ertragsbringende Tokens (wie aUSDC) bei Auszahlungen automatisch in USDC umwandelt. Mithilfe dieses Fehlers führte der Hacker eine Auszahlung im Namen eines anderen Benutzers durch und leitete 427.000 USDC aus Aave ab.

Der Angreifer nutzte das Fehlen einer ordnungsgemäßen Validierung aus, um ungesicherte FAVOR-Token zu prägen. Er verwendete einen gefälschten Smart-Contract als Liquiditätsanbieter (LP) und führte dann einen Massen-Swap durch, um einen erheblichen Bonus zu erhalten, der in echtes Geld umgewandelt werden konnte. Der Prüfer, zokyo, hatte zuvor Schwachstellen gemeldet, die in direktem Zusammenhang mit diesem Hack standen. Aufgrund einer unzureichenden eingehenden Analyse wurde die Schwere dieser Feststellungen jedoch auf ein niedriges Niveau herabgestuft.

Die türkische Krypto-Börse BTCTurk wurde um 48 Millionen Dollar gehackt. Bei dem Angriff wurden private Schlüssel geleakt, was es den Angreifern ermöglichte, Gelder aus Hot Wallets über sieben verschiedene Blockchains abzuziehen. Die Börse hat ihre Krypto-Dienste ausgesetzt.

Odin.fun, eine auf Bitcoin basierende Startrampe und Handelsplattform für Memecoins, wurde Opfer eines Exploits. Der Angriff nutzte eine Schwachstelle im automatisierten Market-Making-Tool der Plattform aus, die im letzten Update eingeführt wurde. Die Angreifer führten ein Liquiditätsmanipulationsschema durch, indem sie Token wie SATOSHI hinzufügten, um die Preise in die Höhe zu treiben, und dann ihre Liquidität abzuziehen, um sich in Bitcoin auszahlen zu lassen.

Ein Angreifer nutzte die BRIDGE-Rolle, um Tokens ohne entsprechende Sicherheiten auszugeben. Diese Tokens wurden dann als Sicherheit für Kredite in anderen Tokens verwendet. Die geliehenen Gelder (gesichert durch die nicht unterlegten Tokens) wurden abgehoben und im Ethereum-Netzwerk gewaschen.

Die Zugriffskontrolle in der Funktion updateMerkleRoot() wurde falsch konfiguriert. Anstatt zu überprüfen, ob die aufrufende Adresse der Eigentümer IST, überprüfte der Code, ob sie der Eigentümer NICHT IST. Dieser Codierungsfehler im Smart Contract ermöglichte es einem Angreifer, einen gefälschten Merkle-Root zu erstellen und den Smart Contract damit zu aktualisieren. Der gefälschte Root ermöglichte es dem Angreifer, Token aus dem Smart Contract abzuheben.

Ein Angreifer kompromittierte das Gerät eines Entwicklers mittels einer Phishing-Attacke. Es wurde Zugang zur Entwicklungsumgebung erlangt. Der Angreifer initiierte die Abhebung von Geldern von 9 Benutzerkonten.

Der Vorfall betraf unbefugten Zugriff auf eine operative Wallet, die zur Liquiditätsbereitstellung an einer Partnerbörse verwendet wird.

Ein Supply-Chain-Angriff, der das Produktionsnetzwerk kompromittierte und es Angreifern ermöglichte, die Betriebslogik der Konto- und Risikokontrollserver zu modifizieren.

Das Protokoll verfügte über ein Schutzschalter-System, das ausgelöst wurde, als der bösartige Vertrag bereitgestellt wurde. Ein eingebauter Mechanismus, der verhindern sollte, dass das Protokoll unbegrenzt pausiert wird, wurde jedoch vom Angreifer gegen das Protokoll eingesetzt. Als das Team Simulationen mit dem bösartigen Smart Contract durchführte und keine möglichen Angriffspfade fand, setzten sie das Protokoll fort. Die nachfolgenden Aktionen des Angreifers wurden aufgrund der zuvor beschriebenen Begrenzung des erneuten Pausierens des Protokolls nicht gestoppt. Der Angreifer nutzte Flash-Loans und bösartige Calldata, um die Konten der Opfer zu leeren. Die Ursache des Hacks war ein Mangel an Calldata-Validierung.

Eine kritische Hintertür wurde in Tausenden von Verträgen entdeckt, die ERC1967Proxy verwenden. Ein Hacker konnte die Initialisierung vorwegnehmen und unbemerkt einen Hacker-Proxy dazwischen installieren, was auf einen Fehler in den Block-Explorern zurückzuführen ist. Der Hacker prägte 110.000 K-Token und startete den Angriff, um sowohl den Morpho Vault als auch den Uniswap v4 Pool zu leeren.

Der Exploit ging von dem bösartigen Smart Contract aus, der vom Angreifer erstellt wurde und dazu diente, die Ausführung während der Auftragsabwicklung zu erzeugen und zu kapern. Die Grundursache liegt in der impliziten Annahme in executeDecreaseOrder(), dass der Parameter _account ein Externally Owned Account (EOA) ist, obwohl er tatsächlich ein bösartiger Smart Contract sein kann. Diese Schwachstelle führte zu einem ausgeklügelten mehrstufigen Angriff, bei dem der Angreifer in der Lage war, das AUM des Protokolls künstlich aufzublähen und GLP für mehr Vermögenswerte einzulösen, als ihm zustand.

Ein Angreifer konnte die Rebalancing-Funktion des Texture Vaults-Vertrags ausnutzen, um eine Übertragung auszulösen. Der Angreifer stellte sein eigenes Token-Konto zur Verfügung, das der Vault während der Neuausrichtung fälschlicherweise mit LP-Tokens befüllte. Der Angreifer löste diese LP-Tokens dann gegen echte Liquidität ein.

Ein Liquiditätspool mit geringer Liquidität wurde von einem Benutzer als Orakel bei der Konfiguration eines Pods verwendet. Der Angreifer konnte diesen Pool mithilfe eines Flash-Darlehens manipulieren, woraufhin ein unterbesichertes Darlehen aufgenommen wurde.

Der Angreifer zielte auf den ResupplyPair-Vertrag ab, der die manipulierte Rate verwendet, nur Stunden nach dessen Bereitstellung. Die Ursache war ein Fehler bei der Wechselkursmanipulation, ausgelöst durch einen klassischen ERC4626 „First Donation“-Vault-Angriff, der zu einem „Division durch großen Wert“-Szenario führte, das den Wechselkurs auf null kollabieren ließ. Diese manipulierte Rate wurde verwendet, um den LTV des Kreditnehmers in der _isSolvent()-Prüfung zu berechnen. Da ltv = 0 ist, wenn exchangeRate = 0, umging der Angreifer die Solvenzprüfung und lieh sich 10 Millionen reUSD mit nur 1 Wei an Sicherheiten.

Der Exploit bezog sich auf einen Smart Contract für eine unveröffentlichte Leverage-Funktion, der zu Testzwecken bereitgestellt wurde. Er zielte auf einen peripheren Vertrag ab, der fillQuote verwendete, um silo.borrow() aufzurufen, wobei Parameter manipuliert wurden, um eine Test-Wallet des Silo Core Teams ins Visier zu nehmen.

Die Hacken-Brücke wurde ausgenutzt. Ein privater Schlüssel, der mit einem Konto mit Prägerechten verbunden war, wurde offengelegt, was es Angreifern ermöglichte, riesige Mengen an HAI-Token zu prägen und diese dann schnell an dezentralen Börsen zu verkaufen. Der private Schlüssel war mit Prägerollen in den Netzwerken Ethereum und BNB Chain verbunden. Die Angreifer konnten rund 900 Millionen HAI-Token prägen.

Nobitex, Irans größte Kryptowährungsbörse, war das Ziel eines bedeutenden Cyberangriffs, der von der pro-israelischen Hackergruppe Gonjeshke Darande, auch bekannt als Predatory Sparrow, beansprucht wurde. Die Gruppe behauptete, dass Nobitex Irans militärische Aktivitäten unterstützte und Nutzern half, internationale Sanktionen zu umgehen, und stellte die Aktion als symbolische Botschaft im Zusammenhang mit den eskalierenden Spannungen zwischen Israel und Iran dar. Der Hack umfasste den Diebstahl von Kryptowährungen aus den Hot Wallets von Nobitex über mehrere Ethereum Virtual Machine (EVM)- und Tron-kompatible Blockchains hinweg. Die Hackergruppe scheint die Krypto-Assets verbrannt zu haben, wodurch sie effektiv zerstört wurden, anstatt sie für eigene Gewinne zu entwenden.

Der Angreifer nutzte eine kritische Integer-Underflow-Schwachstelle in der Funktion BankrollNetworkStack.sell() aus, um die Dividendenzählung zu manipulieren und Gelder von Benutzern abzuziehen, die zuvor mit dem Vertrag interagiert oder diesen genehmigt hatten.

Die Schwachstelle resultierte aus dem Versäumnis, die öffentlich zugängliche Basis-mint()-Funktion, die vom OpenZeppelin ERC4626Upgradeable-Standard geerbt wurde, zu überschreiben oder einzuschränken, was Angreifern ermöglichte, 9701 mpETH ohne Bereitstellung von ETH zu prägen.

Der Exploit entstand durch eine Schwachstelle in der Verifizierungslogik der Self-Listing-Funktion. Der Angreifer nutzte eine kritische Schwachstelle in der Verifizierungslogik der create2-Funktion aus, indem er auf eine fehlgeschlagene Transaktion verwies, wodurch ein bösartiger Token Prüfungen umgehen und Gelder aus Liquiditätspools transferieren konnte.

Der Angreifer führte einen Supply-Chain-Angriff durch, um private Schlüssel zu exfiltrieren. Die geleakten Schlüssel wurden dann verwendet, um Gelder von Bridge-Smart-Contracts freizuschalten. Der Supply-Chain-Angriff zielte auf den Validator-Code ab; der bösartige Code wurde zur Build-Zeit in das Docker-Image eingeschleust.

Ein Mendi-to-Malda Migrationsvertrag wurde ausgenutzt. Der Vertrag erlaubte es, die Mendi Comptroller-Adresse dynamisch zu übergeben, anstatt sie fest zu kodieren. Der Angreifer nutzte eine Funktion, die ausschließlich dazu gedacht war, Mendi-Protokollnutzern die direkte Migration zu Malda zu ermöglichen. Der Angreifer implementierte einen gefälschten Mendi Comptroller-Vertrag, wodurch er eine betrügerische Malda-Position erstellen und Gelder dagegen abheben konnte.

Das Kernproblem hinter dem Exploit liegt in zwei kritischen Schwachstellen des Cork-Protokolls. Erstens erlaubte der Konfigurationsvertrag des Protokolls (CorkConfig) Benutzern, Märkte mit beliebigen Einlösungsvermögenswerten (RA) zu erstellen, was es dem Angreifer ermöglichte, DS als RA zu bestimmen. Zweitens fehlte der beforeSwap-Funktion des CorkHook-Vertrags eine ordnungsgemäße Zugriffskontrolle und Eingabevalidierung, wodurch jeder sie mit benutzerdefinierten Hook-Daten für CorkCall-Operationen aufrufen konnte. Durch die Ausnutzung dieser Schwachstellen erstellte der Angreifer einen bösartigen Markt, der DS als RA verwendete, und nutzte gültige DS-Token von einem legitimen Markt, um sie auf diesem gefälschten Markt einzuzahlen. Im Gegenzug erhielten sie sowohl DS- als auch CT-Token. Aufgrund des Fehlens von Beschränkungen für RA-Typen und einer unzureichenden Validierung des Aufrufers und der Eingabedaten konnte der Angreifer die Liquidität manipulieren und unautorisierte Einlösungen durchführen, wodurch der ursprüngliche Markt geleert wurde. Diese Manipulation ermöglichte es ihnen, eine große Menge an Derivaten zu erwerben, die sie schließlich für 3.761 wstETH einlösten. Die grundlegende Ursache des Exploits liegt im Versagen des Protokolls, vom Benutzer bereitgestellte Daten streng zu validieren und ordnungsgemäße Beschränkungen für die Markterstellung durchzusetzen.

Der Angreifer nutzte eine situative Schwachstelle im Einzahlungspfad des usUSDS++-Vaults aus, einem Beta-Vault, der auf dem Sky-Protokoll basiert. Die Schwachstelle konzentrierte sich auf den „Unwrap“-Prozess, bei dem USD0++ während Einzahlungen in USD0 umgewandelt wird. Durch Manipulation der Einzahlungsroute des Vaults, insbesondere der gedeckelten und begrenzten Konvertierung von USD0++ zu USD0, führte der Angreifer eine Arbitrage-Strategie aus und erzielte einen Gewinn von etwa 42.800 US-Dollar. Der Vault wurde in den letzten Monaten vier Sicherheitsaudits unterzogen. Der Exploit war nicht auf fehlerhafte Logik zurückzuführen. Stattdessen nutzte er einen Verhaltens-Grenzfall im System aus.

Das Fehlen einer Validierung der Chainlink-Oracle-Preisfeeds ermöglichte es dem Angreifer, eine alte, aber immer noch kryptografisch gültige Preissignatur zu verwenden, um eine Position zu eröffnen. Der Angreifer verwendete einen erheblich veralteten ETH-Preis von etwa 1.816 $, während der tatsächliche Marktpreis näher bei 2.520 $ lag. Die Differenz der Vermögenspreise wurde als Gewinn entnommen.

Ein Fehler in der Methode zur Überprüfung von Ganzzahlüberläufen ermöglichte es einem Angreifer, ungesicherte SUI zu prägen.

Ein fehlerhafter und veralteter Smart Contract wurde vor dem Angriff immer noch als Orakel für den Token-Preis verwendet. Der Angreifer nutzte die Spende, um die Schwachstelle im Code auszunutzen und den Preis von dGLP künstlich in die Höhe zu treiben. Anschließend nutzte der Angreifer das überbewertete dGLP als Sicherheit für die Kreditaufnahme.

Die Angriffssequenz beruhte auf umfangreichen administrativen Berechtigungen. Eine Administratorrolle wurde der Adresse eines Angreifers vom Zunami Protocol Deployer Wallet gewährt. Später führte der Angreifer den Exploit aus, indem er direkt die Funktion withdrawStuckToken() in Zunamis Strategie aufrief, eine Funktion, die für Notabhebungen konzipiert ist. Dieser einzige Aufruf ermöglichte es dem Angreifer, 296.456 LP-Token, die die Sicherheiten für zunUSD und zunETH darstellen, direkt auf seine Adresse zu übertragen.

Der ungeprüfte Smart Contract enthielt einen einfachen logischen Fehler, der es dem Angreifer ermöglichte, die gesamte Liquidität abzuziehen. Die Grundursache war die Überschreitung des 1e18-Multiplikators in der Einzahlungsbewertungsfunktion.

Der Vorfall wurde auf einen Entwickler zurückgeführt, der unwissentlich vom Team eingestellt wurde und sich als verdeckter IT-Mitarbeiter der DVRK herausstellte. Diese Person/dieses Team verschaffte sich unrechtmäßig Zugang zu den administrativen Schlüsseln des Projekts und führte eine Reihe nicht autorisierter Transaktionen aus. Der Angreifer hatte eine modifizierte Version der AToken- und VariableDebtToken-Verträge bereitgestellt. In dieser Version wurde der Zugriffssteuerungsmodifikator „onlyPool“ so geändert, dass nicht nur der Pool-Vertrag, sondern auch jede Adresse mit der Pool-Admin-Rolle Funktionen ausführen konnte, die ursprünglich eingeschränkt waren. Der Angreifer nutzte die kompromittierte Bereitsteller-Wallet, um das Leeren aller Pools zu initiieren.

Der Angreifer nutzte fehlerhaften Protokollcode aus und erstellte einen Liquiditätspool abseits des aktuellen Preises, wodurch er erhebliche Gebühren durch Wash-Swaps generierte. Diese Gebühren wurden dann verwendet, um die Bewertung der Sicherheiten zu erhöhen, wobei fehlerhafte Smart-Contract-Mathematik ausgenutzt wurde. Anschließend lieh der Angreifer Geld gegen diese überbewerteten Sicherheiten. Spätere Reinvestitionen reduzierten jedoch den Wert der Sicherheiten, was zu einer unterbesicherten Schuld führte. Diese Schuld wurde dann ohne Liquidation restrukturiert, wodurch der Angreifer die illegalen Gelder behalten konnte.

Während eines internen Updates des tETH-Orakels wurde eine Diskrepanz in der Dezimalpräzision zwischen den Orakelkomponenten eingeführt. Diese Inkonsistenz führte zu falschen Preisausgaben für tETH. Ein anonymer Liquidator führte Liquidationen in dem Zeitraum durch, in dem der falsche tETH-Preis live war.

Loopscale wurde Ziel eines Angriffs, der die Preislogik des Protokolls für von RateX ausgegebene Token ausnutzte. Durch das Spoofing der RateX PT-Marktprogramme konnte der Angreifer eine Reihe von unterbesicherten Darlehen aufnehmen. Der ausgenutzte Codepfad wurde im Rahmen einer neuen Integration mit RateX bereitgestellt und hatte noch keine formelle Prüfung durch Dritte durchlaufen.

Die Oxya Origin Deployer-Wallet scheint kompromittiert worden zu sein, was dazu führte, dass das Eigentum am $OXYZ-Token an eine verdächtige Adresse (0x2a00d9941ab583072bcf01ec2e644679e4579272) übertragen wurde. Der Angreifer prägte 9 Milliarden $OXYZ, tauschte 45.000 $ und überbrückte die Gelder über Stargate.

Eine Schwachstelle in der overPaper-Funktion des BTCMapp Smart Contracts ermöglichte es einem Angreifer, 1.311 ETH zu entnehmen, was 2.228.700 US-Dollar entspricht.

Der Angreifer manipulierte den Preis des $NUMA-Tokens, während er gleichzeitig große Short- und Long-Positionen eröffnete, hinterlegte Sicherheiten durch Selbstliquidation entfernte und das System über den Vault verließ.

Der bösartige Entwickler hatte Code in den Staking-Smart-Contract eingeschleust, der es ihm ermöglichte, eine Notentleerung des Liquiditätspools durchzuführen, wodurch Token im Wert von rund 490 ETH gestohlen wurden.

Die Schwachstelle entstand im TrustedForwarder-Vertrag, der OpenZeppelins MinimalForwarderUpgradeable erbte, aber die Execute-Methode nicht überschrieb. Infolgedessen blieb die Methode erlaubnislos und Missbrauch ausgesetzt. Der Angreifer nutzte dieses Versäumnis aus, indem er die ursprüngliche Execute-Funktion direkt von MinimalForwarderUpgradeable aufrief. In einer einzigen Transaktion eröffnete der Angreifer eine Position zu einem künstlich niedrigen Preis und schloss sie dann zu einem höheren Preis, wodurch er durch diesen Exploit einen illegitimen Gewinn erzielte.

Der Angreifer nutzte ein kompromittiertes Admin-Konto, um die verbleibenden, nicht beanspruchten Token von den ZK-Token-Merkle-Distributoren zu prägen, die für den ZKsync Airdrop vom 17. Juni 2024 verwendet wurden. Der Hacker erlangte erfolgreich die Kontrolle über 111.881.122 ZK-Token.

Die privaten Schlüssel wurden kompromittiert. Der Angreifer nutzte diese Schlüssel dann, um eine Funktion im Vertrag durch eine bösartige zu ersetzen, was ihm den Abzug von Geldern ermöglichte.