Rapport de sécurité Web3 d'août : 29 incidents majeurs, plus de 68,29 M$ perdus

Selon les données recueillies par la plateforme Beosin Alert, en août 2026, les pertes totales dues à divers événements de sécurité s'élèvent à environ 76,15 millions de dollars, avec un total de 『29』 événements majeurs de sécurité, principalement dus à des vulnérabilités de contrat. Parmi ceux-ci, 18 événements sont liés à des vulnérabilités de contrat ou de réseau, et 2 sont dus à une fuite 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é Web3.

Le 13 août, l'adresse utilisateur individuel 0x13e3....179e a été victime d'unvol causé par une fuite de clé privée, entraînant le vol d'actifs numériques tels que WBTC, cbBTC, LDO, USDS, CRV, pour une perte totale d'environ 25,6 millions de dollars, ce qui en fait l'événement sécuritaire avec la perte la plus élevée. Le 30 août, le protocole de prêt sur le réseauCronos, Tectonic, a été attaqué par un hacker exploitant une vulnérabilité contractuelle, avec une perte estimée à environ 74 millions de dollars. Cette attaque a poussé le réseau Cronos à prendre des mesures d'urgence, en suspendant le réseau et en annulant les transactions ; le hacker a finalement transféré environ 6 millions de dollars sur le réseauEthereum.

En outre, la chaîne Harmony a vu environ 4 milliards d'unités ONE supplémentaires être créées en raison d'une vulnérabilité, avec une perte nominale dépassant 4 millions de dollars, mais les jetons falsifiés ont finalement été éliminés par un rollback des transactions, de sorte qu'ils ne sont pas pris en compte dans les pertes.

Les cibles de cette année incluent des chaînes publiques, des protocoles de prêt, des applications de portefeuille, des contrats de jetons, des ponts cross-chain et des utilisateurs ordinaires. Les projets DeFi ont subi les pertes les plus élevées, atteignant 33,09 millions de dollars américains, tandis que les adresses personnelles ont perdu environ 28,4 millions de dollars américains en raison de fuites de clés privées ou d'attaques par hameçonnage. Les contrats de jetons ont été attaqués le plus souvent, avec un total de 10 incidents ; les contrats DeFi occupent la deuxième place avec 9 attaques.

La chaîne ayant subi le plus grand montant de pertes en mai est Ethereum, avec des pertes dépassant 48,58 millions de dollars américains et un total de 15 incidents de sécurité. La plupart des protocoles DeFi et des attaques de phishing ciblant les grosses poches continuent de se concentrer sur Ethereum. La deuxième chaîne la plus fréquemment attaquée est BNB Chain, mais les cibles principales sont les contrats de jetons, avec des pertes relativement faibles. En outre, des incidents de sécurité ont également été signalés sur d'autres chaînes publiques telles que Cronos, Base, Harmony, Bitcoin et Solana, reflétant une tendance aux attaques multi-chaînes.

1. Tectonic et Moonwell : manipulation des prix

Tectonic et Moonwell sont des protocoles de prêt sur chaîne dont les attaques ont été causées par la manipulation des prix de certains actifs de garantie à faible liquidité, permettant d'emprunter des montants excessifs en se basant sur des valeurs d'actifs artificiellement gonflées. Dans l'attaque contre Tectonic, l'attaquant a fait augmenter le prix du token de gouvernance de Tectonic, $TONIC, de 100 fois, obtenant ainsi un额度 d'emprunt d'environ 74 millions de dollars, qu'il a ensuite utilisé pour emprunter des actifs tels que l'USDT. Après l'incident, le réseau Cronos a suspendu d'urgence la production de blocs sur l'ensemble de la chaîne ; avant cette suspension, l'attaquant a transféré environ 6 millions de dollars via une passerelle cross-chain vers Ethereum. Par la suite, le réseau Cronos a effectué un rollback pour récupérer les pertes.

Adresse de profit de l'attaquant Ethereum : 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD et flux des fonds volés :

Actuellement, environ 2659 ETH sont toujours détenus dans 0xc4041, 140,1 ETH ont été transférés vers 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c avant d'être répartis vers plusieurs adresses nouvellement créées.

Moonwell a subi une perte d'environ 8,7 millions de dollars car l'attaquant a manipulé le prix du jeton MAMO à faible liquidité pour emprunter du cbBTC :

Ces deux attaques ne sont pas dues à une vulnérabilité du contrat intelligent, mais à la manière dont le protocole évalue les actifs garants en se basant sur une liquidité spot faible, ce qui conduit à un calcul erroné de la valeur des garanties. Pour éviter ce type d'attaque, le protocole peut récupérer des données provenant de plusieurs oracles et effectuer des vérifications supplémentaires en cas de fortes fluctuations de prix.

2. Harmony : attaque de rejeu

Harmony est une Layer 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 des reçus cryptographiques pour les transactions sortantes, tandis que le shard cible vérifie que ce reçu et sa preuve Merkle correspondent au bloc source signé avant d'enregistrer la transaction, chaque reçu n'étant utilisable qu'une seule fois.

La vulnérabilité exploitée lors de cette attaque se trouve dans les parties héritées du système de shards 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é, un attaquant peut les modifier sans compromettre aucune fonctionnalité existante. Dans cette attaque, l'attaquant a obtenu un reçu inter-shard et a modifié le ShardID et le BlockNum afin que le programme de vérification le reconnaisse 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 rejeu très typique. Tout champ utilisé comme « marqueur à usage unique » doit faire partie intégrante de l'en-tête signé. Lors de la validation du reçu, l'ID de fragment et le numéro de bloc doivent être directement extraits de l'en-tête de bloc vérifié, et non pas tirés des champs non vérifiés de la structure de preuve.

3. Finance à terme : Attaque de gouvernance

Term Finance est un protocole DeFi de prêt à taux fixe, dont chaque trésorerie (Vault) est une vault ERC-4626 basée sur le code de Yearn V3. La gouvernance des trésoreries de Term Finance n'est pas basée sur des votes d'approbation, mais sur des votes de veto. Lorsqu'un curateur soumet une proposition de modification des paramètres, les gouvernants ouvrent une fenêtre permettant aux détenteurs de jetons LP de soumettre des objections. Le seuil de vote de gouvernance présente cependant une faille grave :

● Absence de seuil absolu en votes ou en capital : les conditions pour l'adoption de la proposition, isSupportThresholdReached() et isMinParticipationReached(), ne vérifient que des proportions relatives, et non des nombres absolus de votes. Cela signifie qu'une proposition peut être adoptée dès lors qu'une majorité relative est atteinte, indépendamment du nombre total de participants ou du montant total de capital impliqué.

● Faible participation : presque aucun déposant n'a converti ses parts de trésorerie (tmvETH) en jeton de gouvernance (gtmvETH) pour participer aux votes. Cela a entraîné une offre totale très faible de jetons de gouvernance pour la trésorerie concernée.

Les attaquants ont exploité ce défaut de conception pour mener une attaque de gouvernance sur le trésor à un coût extrêmement faible :

(1) Obtenir le droit de vote : l'attaquant a échangé environ 0,5 ETH contre environ 0,485 parts du trésor tmvETH, puis a encapsulé ces parts 1:1 en 0,485 jetons de gouvernance gtmvETH pour obtenir le droit de vote.

(2) Soumission d'une proposition malveillante : lors de la création de la proposition, le contrat a enregistré un approvisionnement total de jetons de gouvernance de seulement 0,535 gtmvETH, ce qui signifie que les 0,485 gtmvETH détenus par l'attaquant représentaient 90,66 % du total.

(3) Vote et exécution : l'attaquant, en tant que seul votant, a voté en faveur. Étant donné qu'aucun vote contre n'a été émis, son taux de soutien dépasse largement le seuil de 50 % ; en outre, son pouvoir de vote personnel dépasse le seuil minimal de participation (minVotingPower) calculé sur la base d'une offre totale extrêmement faible.

(4) Extraction d'actifs : après l'adoption de la proposition, une action malveillante a été exécutée pour retirer les actifs du trésor (WETH)

Les attaquants ont utilisé la même méthode pour compromettre six coffres de Term Finance, entraînant une perte d'environ 8,5 millions de dollars.

Cet attaque est également une attaque typique de gouvernance de protocole sur chaîne. Pour la gouvernance sur chaîne, les équipes de projet devraient établir les points de contrôle suivants pour la prévention :

● Définir un nombre absolu de votes ou un seuil de capital : les propositions de gouvernance ne doivent pas être approuvées uniquement sur la base de proportions relatives. Un seuil minimal absolu doit être établi, par exemple exigeant que les votes favorables atteignent un montant spécifique (tel que 1 million de dollars) ou un nombre déterminé d'adresses indépendantes.

● Configurez un gardien ou un chemin d'annulation pour les verrous temporels : bien que l'exécution de la gouvernance soit généralement retardée, cela ne fait que prévoir un délai de réaction. Les équipes de projet doivent mettre en place un mécanisme de surveillance efficace (Guardian) ou un chemin d'annulation des propositions pendant la période de retard. En cas de détection d'une proposition malveillante pendant ce délai, le gardien peut intervenir immédiatement pour l'annuler.

● Surveiller la participation à la gouvernance : le protocole doit établir une surveillance en temps réel de la participation à la gouvernance de chaque trésorerie. Lorsqu'une participation anormalement faible à la gouvernance, en termes de quantité totale de jetons de gouvernance ou de taux de vote, est détectée, une alerte doit être déclenchée, voire des mesures de protection automatiques.

Tendances des menaces à la sécurité Web3

La tendance la plus profonde présentée par 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 ; une seule fois des audits de sécurité ou des outils ne suffisent pas à couvrir la sécurité opérationnelle, la gouvernance sur chaîne et les vulnérabilités des logiques commerciales. Cela pose de nouveaux défis aux projets Web3 pour construire un système de défense sécurisé.

En outre, les attaques contre les contrats DeFi et les utilisateurs individuels sont fréquentes. Les vulnérabilités des contrats ou les autorisations accordées peuvent facilement être exploitées par les attaquants ; les développeurs ou les opérateurs de contrats doivent réexaminer la sécurité de leurs contrats et, pour les contrats traitant des activités essentielles, effectuer plusieurs audits de sécurité par des parties indépendantes. Pour les utilisateurs individuels, il est recommandé d’utiliser régulièrement des explorateurs de blockchain ou des outils de révocation d’autorisation pour vérifier et annuler les autorisations accordées à des contrats inutilisés, ainsi que de se renseigner sur les techniques d’hameçonnage courantes et émergentes pour renforcer leur sens de la sécurité.

Cet article a été rédigé par l'équipe de sécurité Beosin en combinant le système d'alerte de sécurité Beosin Alert, les données chainées et les analyses post-incident publiques par les équipes des projets. N'hésitez pas à nous contacter pour toute question ou retour.