Rédigé par : Beosin
Selon les données de surveillance de la plateforme Beosin Alert, en mai 2026, le montant total des pertes liées aux divers incidents de sécurité s'élève à environ 76,15 millions de dollars. Il y a eu un total de « 36 » incidents majeurs de piratage, principalement dus à des vulnérabilités de contrat et à des fuites de clés privées. Parmi eux, 17 incidents de sécurité étaient dus à des vulnérabilités de contrat/réseau, et 10 incidents de pertes étaient dus à des fuites de clés privées. La sécurité du code et la sécurité opérationnelle de l'écosystème DeFi sont confrontées à des défis majeurs.
Top 10 des protocoles en pertes pour mai
Le pont inter-chaînes Verus-Ethereum, reliant la chaîne Verus L1 à Ethereum, a été attaqué en raison d'une vulnérabilité de contrat, entraînant les pertes les plus importantes, s'élevant à 11,58 millions de dollars. Echo Protocol a été attaqué suite à une fuite de clé privée, permettant au pirate de frapper 1000 eBTC (valeur nominale d'environ 76,7 millions de dollars), mais en raison de la liquidité limitée, le profit réel final a été d'environ 5,13 millions de dollars.
Types de projets attaqués et situation des pertes par chaîne
Les cibles des attaques couvraient divers types tels que les ponts inter-chaînes, les échanges décentralisés, les protocoles de prêt, les marchés de prédiction, les stablecoins et les utilisateurs ordinaires. Parmi eux, les ponts inter-chaînes ont subi les pertes les plus élevées, avec un montant de 27,995 millions de dollars, et les projets liés au DeFi ont été les plus fréquemment attaqués, avec un total de 14 incidents.
En mai, la chaîne ayant subi le plus de pertes était Ethereum, avec un montant dépassant 48,76 millions de dollars. La plupart des incidents de sécurité impliquant des ponts inter-chaînes et de nombreux protocoles DeFi se concentrent toujours sur Ethereum. Viennent ensuite BNB Chain, Monad, TON, et des incidents de sécurité ont également eu lieu sur Monero et Bitcoin, montrant une tendance d'attaques multi-chaînes.
Analyse des principaux incidents de sécurité
1. Verus : Défaut de vérification des messages inter-chaînes
Le fonctionnement du pont Verus-Ethereum Bridge repose sur un soumissionnaire fournissant des données de preuve attestant de l'existence sur la chaîne Verus d'une sortie qualifiée et notariée. Le contrat du pont vérifie ces preuves sur Ethereum avant de libérer les actifs. La vulnérabilité réside dans le fait que le contrat de pont côté Ethereum vérifie bien la preuve venant de la chaîne Verus, mais ne vérifie pas si ces données correspondent à une sortie originale valide. Cela a permis à un attaquant de construire une fausse sortie passant la vérification et d'extraire des fonds largement supérieurs à son dépôt.
Partie du code contenant la vulnérabilité :
La vulnérabilité de cet incident est du même type que celles qui ont causé des pertes de 320 millions de dollars à Wormhole et de 190 millions de dollars à Nomad en 2022 : le pont a vérifié le message lui-même, mais pas la valeur des fonds sous-jacents.
2. Trusted Volumes : Défaut des paramètres de signature
L'attaquant a exploité un défaut de conception de la signature dans le processus de demande de prix (RFQ) de TrustedVolumes. Lors du transfert réel, en utilisant des données de signature personnalisées, il a défini l'expéditeur du transfert comme le contrat Resolver de TrustedVolumes, ce qui a passé la vérification, permettant ainsi de transférer les actifs du contrat Resolver pour en tirer profit.
Partie du code contenant la vulnérabilité :
La vérification de l'autorisation faisait référence à varg4, tandis que l'exécution du transfert de fonds référençait d'autres paramètres. L'absence de vérification a conduit à une inadéquation entre le domaine du signataire autorisé et l'adresse de débit réel.
L'attaquant n'avait donc qu'à signer une commande avec l'adresse du signataire enregistrée, où maker = Exploit (passant la vérification de signature), et les autres paramètres de signature (jeton, montant) pouvaient être définis sur des valeurs arbitraires, par exemple une fausse commande 1:1, pour qu'elle passe la vérification de prix raisonnable par l'oracle, puis transférer les actifs du contrat du protocole :
3. Les incidents de fuite de clés privées, exemple de StablR
Plusieurs incidents de fuite de clés privées sont survenus en mai, avec des pertes totales dépassant 25 millions de dollars. StablR, en tant qu'émetteur de stablecoins conformes, est devenu une leçon typique en matière de gouvernance de sécurité pour les stablecoins et le secteur DeFi.
StablR a lancé deux produits de stablecoins conformes : EURR et USDR. Le portefeuille multi-signature contrôlant la frappe d'EURR est 0x8278D2881dBF8F6Fc01c98d196c4b16F1aade5Bc ; le portefeuille multi-signature contrôlant la frappe d'USDR est 0xF45392bd2D6e6b8C5Dc26BA6c8a12889419B82F3.
Comme ces 2 portefeuilles multi-signatures ne nécessitaient qu'1 signature pour initier une transaction, l'attaquant, en contrôlant l'adresse propriétaire 0xC73fD562de86d7860EE636C20813Bcb2cF4D550d, a ajouté l'adresse 0xD4677B5A8B1b97EA213Fdb876b0FcBAB3f9F6CD1 à ces 2 portefeuilles multi-signatures, prenant ainsi le contrôle des permissions de frappe du projet :
Ce type d'incident ne relève pas d'une vulnérabilité de code, mais d'un problème de sécurité opérationnelle de l'équipe du projet : ne pas avoir correctement sauvegardé les clés privées des adresses privilégiées, ne pas utiliser de multi-signature à seuil élevé pour les opérations à haute valeur/risque, absence de délai d'exécution (timelock) pour les opérations de frappe importantes, manque de mécanisme de réponse d'urgence rapide.
Tendances des menaces à la sécurité Web3
La tendance la plus profonde en matière de sécurité Web3 en 2026 est l'expansion systémique de la surface d'attaque. Les vulnérabilités apparaissent simultanément dans le code, l'infrastructure, l'interopérabilité et les processus humains. Compter uniquement sur quelques audits de sécurité ou des outils ne peut couvrir les domaines de la sécurité opérationnelle, des terminaux employés, de l'infrastructure cloud et de la chaîne d'approvisionnement logicielle. Cela impose des exigences plus élevées en matière de sécurité opérationnelle continue pour les projets Web3.
De plus, les attaques contre les contrats anciens/abandonnés sont fréquentes, leurs vulnérabilités ou autorisations étant facilement exploitables par les attaquants. Les développeurs ou opérateurs de contrats devraient réexaminer la sécurité de leurs anciens contrats. Pour les contrats abandonnés, ils devraient traiter ou transférer correctement les fonds restants dans le contrat, et contacter les utilisateurs pour annuler les autorisations inutiles. Les utilisateurs devraient également vérifier régulièrement à l'aide d'un explorateur de blocs ou d'outils de révocation d'autorisation et annuler les autorisations de contrat qu'ils n'utilisent plus.
