La brèche était une défaillance de l'infrastructure. Les attaquants ont accédé aux identifiants GitHub d'un sous-traitant, s'infiltrant finalement dans l'AWS Key Management Service de Resolv pour s'emparer de la clé privée SERVICE_ROLE. Grâce à cette clé, l'attaquant a contourné les limites de frappe (minting) pour émettre des jetons contre une garantie minimale, extrayant environ 24,5 millions de dollars en ETH et provoquant un violent depeg de l'USR. Cet événement a déclenché une contagion secondaire dans la DeFi, entraînant des créances douteuses pour des protocoles tels que Morpho et Fluid.

Une mauvaise configuration technique dans le CAPO d'Aave a déclenché des liquidations sur des comptes sains. L'incident a été causé par un décalage de paramètres entre le snapshotRatio et le snapshotTimestamp du protocole, entraînant une sous-évaluation du Wrapped Staked Ether (wstETH) d'environ 2,85 %. Des bots automatisés ont traité 10 938 wstETH en liquidations, générant environ 512 ETH de profit pour les liquidateurs. Chaos Labs et l'Aave DAO se sont engagés à un remboursement intégral pour les utilisateurs concernés. Les futures mesures de prévention se concentrent sur la mise en œuvre de simulations de transactions obligatoires et de vérifications de cohérence on-chain pour garantir que les paramètres de risque restent alignés avec la réalité du marché.

L'attaquant a exploité une faille de conception dans la fonction swap() qui permettait des appels arbitraires d'exécuteur, entraînant le vol des fonds des utilisateurs ayant accordé des approbations illimitées.

Les clés de signature de validateur présumées avoir fuité et un prêt flash ont permis à l'attaquant d'obtenir un pouvoir de vote exclusif. Ayant le contrôle des validateurs, l'attaquant a utilisé les fonds du pont dans le même bloc pour acheter du BONE, le déléguer pour le pouvoir de validateur, signer des points de contrôle frauduleux, puis rembourser le « prêt » avec les actifs volés.

L'attaquant a utilisé une clé privée compromise d'un compte d'administrateur de proxy pour mettre à jour un contrat intelligent vers une version malveillante. L'attaquant a ensuite utilisé la version malveillante du contrat intelligent pour vider le solde du contrat lui-même, ainsi que les portefeuilles des utilisateurs qui avaient approuvé ce contrat intelligent.

Un accès non autorisé à l'API de Kiln, un partenaire de staking de SwissBorg, a conduit au vol de 4,5 millions de dollars du programme de staking SOL Earn. Les attaquants ont manipulé les autorisations des comptes de staking sans avoir besoin de confirmations multi-signatures. Cela leur a permis de transférer l'autorité en silence tout en conservant le rôle de "Withdrawer", ce qui les a aidés à contourner les outils de surveillance standards qui se concentrent sur les événements de retrait. La faille était un exploit de l'API hors chaîne qui a donné aux attaquants le contrôle sur les actifs en chaîne.

Un développeur de Nemo a introduit une nouvelle fonctionnalité non auditée dans la base de code après l'audit de sécurité initial mais avant que le rapport révisé final ne soit complet. Par conséquent, une version du contrat contenant ce code non audité a été déployée sur le réseau principal (mainnet). La cause fondamentale de la gouvernance a été la dépendance du protocole à une adresse à signature unique pour les mises à jour, ce qui n'a pas empêché le déploiement de code qui n'avait pas subi un examen de sécurité approfondi. De plus, le développeur a déployé une version du code différente de celle confirmée par la société d'audit. Un attaquant a exploité ces fonctions non auditées pour manipuler l'état interne et a réussi à siphonner une quantité substantielle d'actifs du pool de liquidité.

Les attaquants ont utilisé un client Zoom malveillant pour obtenir des privilèges sur l'ordinateur de la victime. Ils ont exploité cet accès pour inciter la victime à soumettre une transaction qui approuvait l'attaquant en tant que délégué Venus valide de son compte, permettant ainsi à l'attaquant d'emprunter et de rembourser en son nom.

Des attaquants ont eu accès à un portefeuille multisig contenant 32 millions de jetons AIO. Les fonds ont été déplacés et échangés contre 2 millions de dollars.

L'attaquant a exploité une vulnérabilité dans le contrat de connecteur, qui convertit automatiquement les jetons à rendement (comme aUSDC) en USDC lors des retraits. En utilisant cette faille, le pirate a exécuté un retrait au nom d'un autre utilisateur et a siphonné 427 000 USDC d'Aave.

L'attaquant a exploité le manque de validation appropriée pour créer des jetons FAVOR non sécurisés. Il a utilisé un faux contrat intelligent comme fournisseur de liquidité (LP), puis a exécuté un échange en masse pour obtenir un bonus significatif qui pouvait être converti en argent réel. L'auditeur, zokyo, avait déjà signalé des vulnérabilités directement liées à ce piratage. Cependant, en raison d'une analyse approfondie insuffisante, la gravité de ces découvertes a été rétrogradée à un niveau faible.

La plateforme d'échange de crypto-monnaies turque BTCTurk a été victime d'une exploitation de 48 millions de dollars. L'attaque a impliqué la fuite de clés privées, permettant aux attaquants de vider les fonds des portefeuilles chauds sur sept blockchains différentes. L'échange a suspendu ses services de cryptomonnaie.

Odin.fun, une plateforme de lancement et de trading de memecoins basée sur Bitcoin, a subi un exploit. L'attaque a exploité une faille dans l'outil de teneur de marché automatisé de la plateforme, introduit dans la dernière mise à jour. Les attaquants ont mis en œuvre un système de manipulation de liquidité en ajoutant des jetons tels que SATOSHI pour faire grimper les prix, puis en retirant leur liquidité pour encaisser en Bitcoin.

Un attaquant a utilisé le rôle BRIDGE pour émettre des jetons sans garantie appropriée. Ces jetons ont ensuite été utilisés comme garantie pour des prêts en d'autres jetons. Les fonds empruntés (garantis par les jetons sans collatéral) ont été retirés et blanchis sur le réseau Ethereum.

Le contrôle d'accès dans la fonction updateMerkleRoot() a été configuré incorrectement. Au lieu de vérifier que l'adresse appelante EST le propriétaire, le code vérifiait qu'elle N'EST PAS le propriétaire. Cette erreur de codage du contrat intelligent a permis à un attaquant de former une fausse racine de Merkle et de mettre à jour le contrat intelligent avec celle-ci. La racine fabriquée a permis à l'attaquant de retirer des jetons du contrat intelligent.

Un attaquant a compromis l'appareil d'un développeur à l'aide d'une attaque de phishing. L'accès à l'environnement de développement a été obtenu. L'attaquant a initié le retrait de fonds de 9 comptes utilisateurs.

L'incident impliquait un accès non autorisé à un portefeuille opérationnel utilisé pour la fourniture de liquidités sur une bourse partenaire.

Une attaque de la chaîne d'approvisionnement qui a compromis le réseau de production, permettant aux attaquants de modifier la logique opérationnelle des serveurs de contrôle des comptes et des risques.

Le protocole disposait d'un système de coupe-circuit qui s'est déclenché lors du déploiement du contrat malveillant. Cependant, un mécanisme intégré, conçu pour empêcher que le protocole ne soit mis en pause indéfiniment, a été utilisé par l'attaquant contre le protocole. Lorsque l'équipe a effectué des simulations avec le contrat intelligent malveillant et n'a trouvé aucune voie d'exploitation possible, elle a relancé le protocole. Les actions ultérieures de l'attaquant n'ont pas été arrêtées en raison du limiteur précédemment décrit sur la remise en pause du protocole. L'attaquant a utilisé des prêts flash et des données d'appel malveillantes (calldata) pour vider les comptes des victimes. La cause principale du piratage était un manque de validation des données d'appel.

Une porte dérobée critique a été découverte dans des milliers de contrats utilisant ERC1967Proxy. Un pirate a réussi à anticiper l'initialisation et à installer un proxy malveillant entre les deux, passant inaperçu en raison d'un bug dans les explorateurs de blocs. Le pirate a frappé 110 000 jetons K et a lancé l'attaque pour vider à la fois le coffre-fort Morpho et le pool Uniswap v4.

L'exploit a trouvé son origine dans le contrat intelligent malveillant conçu par l'attaquant, qui a été utilisé pour créer et détourner l'exécution lors de l'exécution des ordres. La cause principale réside dans l'hypothèse implicite dans executeDecreaseOrder() selon laquelle le paramètre _account est un compte détenu en externe (EOA), alors qu'il peut en fait s'agir d'un contrat intelligent malveillant. Cette vulnérabilité a conduit à une attaque sophistiquée en plusieurs étapes où l'attaquant a pu gonfler artificiellement l'AUM du protocole et échanger du GLP contre plus d'actifs qu'il n'en méritait.

Un attaquant a pu exploiter la fonction de rééquilibrage du contrat Texture Vaults pour déclencher un transfert. L'attaquant a fourni son propre compte de jetons, que le Vault a rempli par erreur de jetons LP lors du rééquilibrage. L'attaquant a ensuite échangé ces jetons LP contre de la liquidité réelle.

Un pool à faible liquidité a été utilisé par un utilisateur comme oracle lors de la configuration d'un pod. L'attaquant a pu manipuler ce pool en utilisant un prêt flash, puis un prêt sous-collatéralisé a été contracté.

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.

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.

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.

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.