Web3 Rapport de sécurité d'août : 29 événements de sécurité majeurs, pertes totales dépassant 68,29 millions de dollars

En août 2026, les principales causes des événements de sécurité majeurs étaient des vulnérabilités de contrat, avec 18 événements de sécurité dus à des vulnérabilités de contrat/réseau et 2 événements de sécurité dus à des fuites de clés privées. La sécurité des contrats intelligents et la gestion des clés privées restent des points faibles dans la sécurité de Web3.

Rédigé par : Beosin

Selon les données de surveillance de la plateforme Beosin Alert, en août 2026, le montant total des pertes dues à divers événements de sécurité s'élève à environ 76,15 millions de dollars, avec un total de 29 événements de sécurité majeurs, principalement dus à des vulnérabilités de contrat. Parmi ceux-ci, 18 événements de sécurité étaient dus à des vulnérabilités de contrat/réseau et 2 événements de sécurité étaient dus à des fuites de clés privées. La sécurité des contrats intelligents et la gestion des clés privées restent des points faibles dans la sécurité de Web3.

Pertes de août Top10

Le 13 août, l'adresse utilisateur personnelle 0x13e3....179e a été volée de WBTC, cbBTC, LDO, USDS, CRV et d'autres actifs cryptographiques en raison d'une fuite de clé privée, pour une perte totale d'environ 25,6 millions de dollars, ce qui en fait l'événement de sécurité avec la perte réelle la plus élevée. Le 30 août, le protocole de prêt Tectonic sur le réseau Cronos a été attaqué par des hackers en raison d'une vulnérabilité de contrat, avec des pertes estimées à environ 74 millions de dollars. Cette attaque a conduit le réseau Cronos à prendre des mesures d'urgence, suspendant le réseau et annulant les transactions, les hackers ayant finalement réussi à transférer environ 6 millions de dollars vers le réseau Ethereum via des transactions inter-chaînes.

De plus, la chaîne publique Harmony a été victime d'une vulnérabilité qui a permis la création supplémentaire d'environ 4 milliards de jetons ONE, avec une perte nominale de plus de 4 millions de dollars, mais a finalement été annulée par un retour en arrière des transactions, donc non comptabilisée dans les pertes.

Types de projets attaqués et pertes par chaîne

Ce mois-ci, les cibles des attaques comprenaient des chaînes publiques, des protocoles de prêt, des applications de portefeuille, des contrats de jetons, des ponts inter-chaînes et des utilisateurs ordinaires, parmi lesquels les projets DeFi ont subi les pertes les plus élevées, atteignant 33,09 millions de dollars ; tandis que les adresses personnelles ont perdu environ 28,4 millions de dollars en raison de fuites de clés privées ou de phishing. Les contrats de jetons ont été attaqués le plus souvent, avec un total de 10 attaques ; les contrats DeFi ont été attaqués 9 fois.

La chaîne ayant subi le plus de pertes en mai était Ethereum, avec des pertes dépassant 48,58 millions de dollars, totalisant 15 événements de sécurité. La plupart des attaques de phishing ciblant les baleines et les protocoles DeFi se concentrent toujours sur Ethereum. La chaîne avec le deuxième plus grand nombre d'événements de sécurité était BNB Chain, mais les cibles des attaques étaient principalement des contrats de jetons, avec des pertes relativement faibles. De plus, des événements de sécurité ont également eu lieu sur les chaînes publiques telles que Cronos, Base, Harmony, Bitcoin, Solana, montrant une tendance d'attaques multi-chaînes.

Analyse des principaux événements de sécurité

1. Tectonic et Moonwell : Manipulation des prix

Tectonic et Moonwell sont des protocoles de prêt en chaîne, attaqués en raison de la manipulation des prix des actifs de garantie de certains jetons à faible liquidité, permettant d'emprunter des actifs en valeur surestimée pour réaliser des bénéfices. Dans l'attaque de Tectonic, les attaquants ont réussi à augmenter le prix du jeton de gouvernance $TONIC de 100 fois, obtenant ainsi un montant d'emprunt d'environ 74 millions de dollars, puis empruntant des actifs tels que USDT. Après l'incident, le réseau Cronos a suspendu d'urgence toute la chaîne, et les attaquants ont transféré environ 6 millions de dollars vers Ethereum avant la suspension du réseau. Par la suite, le réseau Cronos a effectué un retour en arrière pour récupérer les pertes.

Adresse de profit des hackers sur Ethereum : 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD et flux de fonds volés :

Actuellement, environ 2659 ETH sont toujours stockés à 0xc4041, 140,1 ETH ont été transférés à 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c puis envoyés de manière dispersée à plusieurs adresses nouvellement créées.

Moonwell a également été attaqué car les attaquants ont manipulé le prix du jeton MAMO à faible liquidité pour emprunter cbBTC, entraînant une perte d'environ 8,7 millions de dollars :

Ces deux attaques ne reposent pas sur des vulnérabilités de contrat intelligent, mais sur le fait que le protocole lui-même a mal évalué la valeur des garanties en se basant sur une liquidité de marché faible. Pour éviter de telles attaques, le protocole peut obtenir des données de différentes sources via plusieurs oracles et effectuer des jugements supplémentaires en cas de fluctuations de prix importantes.

2. Harmony : Attaque de répétition

Harmony est une chaîne de couche 1 prenant en charge le sharding, fonctionnant avec quatre shards et transférant des actifs entre eux via un mécanisme asynchrone basé sur des reçus. Le shard source génère un reçu cryptographique pour les transactions sortantes, tandis que le shard cible est responsable de la vérification de ce reçu et de sa preuve Merkle avant d'enregistrer la transaction, chaque reçu ne pouvant être utilisé qu'une seule fois.

La vulnérabilité de cette attaque réside dans les parties héritées du système de sharding de Harmony. Auparavant, Harmony vérifiait si les reçus de shard avaient déjà été utilisés en consultant deux champs CXMerkleProof.ShardID et BlockNum,

Étant donné que ces deux champs se trouvent en dehors de l'en-tête de bloc signé, les attaquants peuvent les modifier sans compromettre aucune fonctionnalité existante. Dans cette attaque, les attaquants ont obtenu un reçu inter-shard et ont modifié les champs ShardID et BlockNum, amenant le vérificateur à le reconnaître comme un nouveau reçu. Le shard cible a accepté le reçu modifié et l'a enregistré à nouveau, tandis que le shard d'origine n'a pas déduit les actifs correspondants.

Il s'agit d'une attaque de répétition très typique. Pour tout champ utilisé comme "jeton à usage unique", il doit faire partie de l'en-tête signé. Lors de la vérification des reçus, les ID de shard et les numéros de blocs doivent être directement lus à partir de l'en-tête de bloc signé, et non de champs non certifiés dans la structure de preuve.

3. Term Finance : Attaque de gouvernance

Term Finance est un protocole de prêt à taux fixe DeFi, dont chaque coffre (Valut) est un coffre ERC-4626 basé sur le code Yearn V3. La gouvernance des coffres de Term Finance ne repose pas sur un vote d'approbation, mais sur un vote de rejet. Lorsque le conservateur propose un changement de paramètre, les gouverneurs ouvrent une fenêtre pour que les détenteurs de jetons LP expriment leurs objections. Cependant, il existe des vulnérabilités graves dans les seuils de vote :

● Absence de seuils de vote absolus ou de capital minimum : Les conditions de passage des propositions isSupportThresholdReached() et isMinParticipationReached() ne vérifient que des proportions relatives, et non des nombres absolus. Cela signifie que tant qu'une majorité relative est atteinte, la proposition peut passer, indépendamment du nombre total de votants ou du montant total de capital.

● Taux de participation extrêmement bas : presque aucun déposant n'a converti ses parts de coffre (tmvETH) en jetons de gouvernance (gtmvETH) pour participer au vote. Cela a conduit à un approvisionnement total de jetons de gouvernance très faible pour les coffres concernés.

Les attaquants ont exploité ces défauts de conception pour réaliser une attaque de gouvernance sur les coffres à un coût très faible :

(1) Obtention des droits de vote : Les attaquants ont échangé environ 0,5 ETH contre environ 0,485 part de coffre tmvETH et les ont encapsulées 1:1 en 0,485 jetons de gouvernance gtmvETH, obtenant ainsi des droits de vote.

(2) Proposition malveillante : Lors de la création de la proposition, le contrat a enregistré que l'approvisionnement total de jetons de gouvernance était de seulement 0,535 gtmvETH à ce moment-là. Cela signifie que les 0,485 gtmvETH détenus par les attaquants représentaient 90,66 % du total.

(3) Vote et exécution : Les attaquants, en tant que seuls votants, ont voté en faveur. Comme il n'y avait pas de votes contre, leur taux de soutien a largement dépassé le seuil de 50 % ; de plus, leur pouvoir de vote personnel a également dépassé le seuil de participation minimum calculé sur la base d'un approvisionnement total extrêmement faible (minVotingPower).

(4) Retrait d'actifs : Une fois la proposition adoptée, des opérations malveillantes ont été exécutées pour retirer les actifs (WETH) du coffre.

Les attaquants ont utilisé la même méthode pour attaquer 6 coffres de Term Finance, entraînant des pertes d'environ 8,5 millions de dollars.

Cette attaque est également un exemple très typique d'attaque de gouvernance de protocole en chaîne. Pour la gouvernance en chaîne, les projets doivent mettre en place les points de contrôle suivants pour la prévention :

● Établir des seuils de vote absolus ou de capital minimum : Les propositions de gouvernance ne doivent pas uniquement dépendre des proportions relatives pour passer. Un seuil rigide basé sur des quantités absolues doit être établi, par exemple en exigeant que les votes favorables atteignent un certain montant (comme 1 million de dollars) ou un certain nombre d'adresses distinctes.

● Équiper les délais de verrouillage avec des gardiens ou des chemins d'annulation : Bien que l'exécution de la gouvernance ait généralement un délai, cela ne fait que conserver un certain temps de réaction. Les projets doivent doter la période de délai d'un mécanisme de garde efficace (Guardian) ou d'un chemin d'annulation de proposition. Si une proposition malveillante est découverte pendant la période de délai, le gardien peut immédiatement intervenir et annuler.

● Surveiller le taux de participation à la gouvernance : Les protocoles doivent établir une surveillance en temps réel du taux de participation à la gouvernance de chaque coffre. Lorsqu'un coffre présente un approvisionnement total de jetons de gouvernance ou un taux de participation au vote anormalement bas, des alertes doivent être émises rapidement, voire des mesures de protection doivent être déclenchées automatiquement.

Tendances des menaces de sécurité Web3

La tendance la plus profonde de la sécurité Web3 en 2026 est l'élargissement systématique de la surface d'attaque. Les vulnérabilités apparaissent simultanément au niveau du code, des opérations quotidiennes et des interactions, et il est impossible de couvrir la sécurité opérationnelle, la gouvernance en chaîne, les vulnérabilités logiques commerciales, etc., uniquement par quelques audits de sécurité ou outils. Cela pose de nouveaux défis aux projets Web3 pour construire des systèmes de défense sécurisés.

De plus, les attaques ciblant les contrats DeFi et les utilisateurs individuels se multiplient. Les vulnérabilités des contrats ou les autorisations sont facilement exploitées par les attaquants. Les développeurs ou opérateurs de contrats doivent réexaminer la sécurité des contrats, et pour les contrats traitant des activités commerciales essentielles, plusieurs audits de sécurité doivent être effectués. Pour les utilisateurs individuels, il est conseillé d'utiliser régulièrement des explorateurs de blockchain ou des outils de révocation d'autorisation pour vérifier et annuler les autorisations de contrats non utilisés, et de se familiariser avec les méthodes de phishing courantes et nouvelles pour améliorer la sensibilisation à la sécurité.