L'attaquant a ciblé le contrat ResupplyPair qui utilise le taux manipulé, quelques heures seulement après son déploiement. La cause principale était un bug de manipulation du taux de change déclenché via une attaque classique de coffre-fort ERC4626 de "première donation", résultant en un scénario de division par une grande valeur qui a effondré l'exchangeRate à zéro. Ce taux manipulé a été utilisé pour calculer le LTV de l'emprunteur lors de la vérification _isSolvent(). Étant donné que ltv = 0 lorsque exchangeRate = 0, l'attaquant a contourné la vérification de solvabilité et a emprunté 10 millions de reUSD en utilisant seulement 1 wei de garantie.

L'exploit concernait un contrat intelligent pour une fonctionnalité de levier non encore publiée, déployée à des fins de test. Il ciblait un contrat périphérique utilisant fillQuote pour appeler silo.borrow(), manipulant les paramètres afin de viser un portefeuille de test de l'équipe Silo Core.

Le pont Hacken a été exploité. Une clé privée associée à un compte ayant des droits de frappe (minting) a été exposée, permettant aux attaquants de frapper d'énormes quantités de jetons HAI et de les vendre rapidement sur des échanges décentralisés. La clé privée était associée aux rôles de frappe sur les réseaux Ethereum et BNB Chain. Les attaquants ont pu frapper environ 900 millions de jetons HAI.

Nobitex, la plus grande plateforme d'échange de cryptomonnaies d'Iran, a été la cible d'une cyberattaque importante revendiquée par le groupe de hackers pro-israélien Gonjeshke Darande, également connu sous le nom de Predatory Sparrow. Le groupe a allégué que Nobitex soutenait les activités militaires iraniennes et aidait les utilisateurs à contourner les sanctions internationales, présentant cet acte comme un message symbolique lié à l'escalade des tensions entre Israël et l'Iran. Le piratage a impliqué le vol de cryptomonnaies des portefeuilles chauds de Nobitex sur plusieurs blockchains compatibles Ethereum Virtual Machine (EVM) et Tron. Le groupe de hackers semble avoir brûlé les actifs cryptographiques, les détruisant ainsi efficacement plutôt que de les prendre pour leurs propres profits.

L'attaquant a exploité une vulnérabilité critique de dépassement de capacité (integer underflow) dans la fonction BankrollNetworkStack.sell() pour manipuler la comptabilité des dividendes et siphonner des fonds des utilisateurs qui avaient précédemment interagi avec ou approuvé le contrat.

La vulnérabilité provenait de l'incapacité à surcharger ou à restreindre la fonction de base mint() exposée publiquement et héritée du standard ERC4626Upgradeable d'OpenZeppelin, ce qui a permis aux attaquants de frapper 9701 mpETH sans fournir d'ETH.

L'exploit est né d'une vulnérabilité au sein de la logique de vérification de la fonction d'auto-inscription. L'attaquant a exploité une faille critique dans la logique de vérification de la fonction create2 en référençant une transaction échouée, permettant ainsi à un jeton malveillant de contourner les vérifications et de transférer des fonds des pools de liquidité.

L'attaquant a mené une attaque par chaîne d'approvisionnement pour exfiltrer des clés privées. Les clés divulguées ont ensuite été utilisées pour déverrouiller des fonds des contrats intelligents de pont. L'attaque par chaîne d'approvisionnement a ciblé le code du validateur, le code malveillant a été injecté dans l'image Docker au moment de la compilation.

Un contrat de migration Mendi-vers-Malda a été exploité. Le contrat permettait de passer dynamiquement l'adresse du contrôleur Mendi, plutôt que de la coder en dur. L'attaquant a utilisé une fonctionnalité conçue uniquement pour permettre aux utilisateurs du protocole Mendi de migrer directement vers Malda. L'attaquant a déployé un faux contrat de contrôleur Mendi, ce qui lui a permis de créer une position Malda frauduleuse et de retirer des fonds contre celle-ci.

Le problème principal derrière l'exploit découle de deux failles critiques dans le protocole Cork. Premièrement, le contrat de configuration du protocole (CorkConfig) permettait aux utilisateurs de créer des marchés avec des actifs de rachat (RA) arbitraires, ce qui a permis à l'attaquant de désigner DS comme RA. Deuxièmement, la fonction beforeSwap du contrat CorkHook manquait de contrôle d'accès et de validation des entrées appropriés, permettant à quiconque de l'invoquer avec des données de hook personnalisées pour les opérations CorkCall. En exploitant ces faiblesses, l'attaquant a créé un marché malveillant en utilisant DS comme RA et a utilisé des jetons DS valides d'un marché légitime pour les déposer dans ce faux marché. En retour, ils ont reçu à la fois des jetons DS et CT. En raison de l'absence de restrictions sur les types de RA et d'une validation insuffisante de l'appelant et des données d'entrée, l'attaquant a pu manipuler la liquidité et effectuer des rachats non autorisés, drainant le marché original. Cette manipulation leur a permis d'acquérir une grande quantité de produits dérivés, qu'ils ont finalement échangés contre 3 761 wstETH. La cause fondamentale de l'exploit réside dans le fait que le protocole n'a pas réussi à valider strictement les données fournies par l'utilisateur et à appliquer des restrictions appropriées sur la création de marché.

L'attaquant a exploité une vulnérabilité situationnelle dans le chemin de dépôt du coffre-fort usUSDS++, un coffre-fort bêta construit sur le protocole Sky. La vulnérabilité était centrée sur le processus de "déroulement" (unwrap), où USD0++ est converti en USD0 lors des dépôts. En manipulant la route de dépôt du coffre-fort, spécifiquement la conversion plafonnée et limitée de USD0++ en USD0, l'attaquant a exécuté une stratégie d'arbitrage et a réalisé un profit d'environ 42 800 $. Le coffre-fort a subi 4 audits de sécurité au cours des derniers mois. L'exploit n'était pas dû à une logique défectueuse. Au lieu de cela, il a tiré parti d'un cas limite comportemental dans le système.

Le manque de validation des flux de prix de Chainlink Oracle a permis à l'attaquant d'utiliser une ancienne signature de prix, mais toujours cryptographiquement valide, pour ouvrir une position. L'attaquant a utilisé un prix ETH considérablement obsolète d'environ 1 816 $, alors que le prix réel du marché était plus proche de 2 520 $. La différence des prix des actifs a été extraite comme profit.

Une faille dans la méthode de vérification du dépassement d'entier a permis à un attaquant de créer des SUI non sécurisés.

Un contrat intelligent bogué et obsolète était toujours utilisé comme oracle pour le prix du jeton avant l'attaque. L'attaquant a utilisé la donation pour exploiter la vulnérabilité dans le code et a artificiellement gonflé le prix du dGLP. L'attaquant a ensuite utilisé le dGLP surévalué comme garantie pour emprunter.

La séquence d'attaque reposait sur l'obtention de privilèges administratifs étendus. Un rôle d'administrateur a été accordé à l'adresse d'un attaquant par le portefeuille de déploiement du protocole Zunami. Plus tard, l'attaquant a exécuté l'exploit en appelant directement la fonction withdrawStuckToken() sur la stratégie de Zunami, une fonction conçue pour les retraits d'urgence. Cet appel unique a permis à l'attaquant de transférer 296 456 jetons LP, représentant la garantie pour zunUSD et zunETH, directement à son adresse.

Le contrat intelligent non audité contenait une simple erreur logique qui a permis à l'attaquant de vider toute la liquidité. La cause principale était l'excès du multiplicateur 1e18 dans la fonction d'évaluation des dépôts.

L'incident a été attribué à un développeur embauché à l'insu de l'équipe, qui s'est avéré être un informaticien infiltré de la RPDC. Cette personne/équipe a accédé illégalement aux clés administratives du projet et a exécuté une série de transactions non autorisées. L'attaquant avait déployé une version modifiée des contrats AToken et VariableDebtToken. Dans cette version, le modificateur de contrôle d'accès onlyPool a été modifié pour permettre non seulement au contrat Pool, mais aussi à toute adresse ayant le rôle d'administrateur de Pool, d'exécuter des fonctions qui étaient initialement restreintes. L'attaquant a utilisé le portefeuille de déploiement compromis pour lancer le vidage de tous les pools.

Exploitant un code de protocole défectueux, l'attaquant a créé un pool de liquidités loin du prix actuel et a généré des frais substantiels grâce à des swaps de lavage. Ces frais ont ensuite été utilisés pour gonfler l'évaluation de la garantie, en tirant parti des mathématiques défectueuses du contrat intelligent. L'attaquant a ensuite emprunté contre cette garantie surévaluée. Cependant, un réinvestissement a par la suite réduit la valeur de la garantie, entraînant une dette sous-collatéralisée. Cette dette a ensuite été restructurée sans liquidation, permettant à l'attaquant de conserver les fonds illicites.

Loopscale a été la cible d'une attaque qui a exploité la logique de tarification du protocole pour les jetons émis par RateX. En falsifiant les programmes de marché RateX PT, l'attaquant a pu contracter une série de prêts sous-collatéralisés. Le chemin de code exploité a été déployé dans le cadre d'une nouvelle intégration avec RateX et n'avait pas encore fait l'objet d'un audit formel par un tiers.

Lors d'une mise à jour interne de l'oracle tETH, une incohérence de précision décimale a été introduite entre les composants de l'oracle. Cette incohérence a entraîné des sorties de prix incorrectes pour le tETH. Un liquidateur anonyme a exécuté des liquidations pendant la période où le prix incorrect du tETH était actif.

Le portefeuille de déploiement d'Oxya Origin semble avoir été compromis, entraînant le transfert de la propriété du jeton $OXYZ vers une adresse suspecte (0x2a00d9941ab583072bcf01ec2e644679e4579272). L'attaquant a frappé 9 milliards de $OXYZ, a échangé 45 000 $ et a transféré les fonds via Stargate.

Une vulnérabilité dans la fonction overPaper du contrat intelligent BTCMapp a permis à un attaquant d'extraire 1 311 ETH, ce qui équivaut à 2 228 700 $.

L'attaquant a manipulé le prix du jeton $NUMA, tout en ouvrant simultanément de grandes positions courtes et longues, retirant le collatéral déposé en se liquidant lui-même, et sortant par le coffre-fort.

Le développeur malveillant avait injecté du code dans le contrat intelligent de staking, lui permettant d'exécuter un drainage d'urgence du pool de liquidités, ce qui a entraîné le vol d'environ 490 ETH de jetons.

La vulnérabilité a trouvé son origine dans le contrat TrustedForwarder, qui héritait de MinimalForwarderUpgradeable d'OpenZeppelin mais ne surchargeait pas la méthode execute. En conséquence, la méthode est restée sans permission et exposée à une mauvaise utilisation. L'attaquant a profité de cette négligence en appelant directement la fonction execute originale de MinimalForwarderUpgradeable. En une seule transaction, l'attaquant a ouvert une position à un prix artificiellement bas, puis l'a clôturée à un prix plus élevé, générant un profit illégitime grâce à cet exploit.

L'attaquant a utilisé un compte administrateur compromis pour créer les jetons restants non réclamés des distributeurs Merkle de jetons ZK utilisés pour le largage ZKsync du 17 juin 2024. Le pirate a réussi à prendre le contrôle de 111 881 122 jetons ZK.

Les clés privées ont été compromises. L'attaquant a ensuite utilisé ces clés pour mettre à jour une fonction dans le contrat en une fonction malveillante, lui permettant de retirer des fonds.