Beosin : 36 incidents de sécurité majeurs en mai, avec des pertes totales dépassant 76 millions de dollars américains

Rédaction : Beosin

Selon les données de surveillance de la plateforme Beosin Alert, en mai 2026, le montant total des pertes dues à divers incidents de sécurité s'élève à environ 76,15 millions de dollars, avec un total de 36 attaques majeures par piratage, principalement dues à des vulnérabilités de contrats ou à des fuites de clés privées. Parmi celles-ci, 17 incidents sont liés à des vulnérabilités de contrats / réseaux, et 10 incidents sont dus à des fuites de clés privées. La sécurité du code et l'exploitation sécuritaire de l'écosystème DeFi font face à de graves défis.

Top 10 des protocoles en pertes en mai

Le pont cross-chain Verus-Ethereum, reliant la chaîne Verus L1 et Ethereum, a été attaqué en raison d'une vulnérabilité de contrat, avec une perte maximale de 11,58 millions de dollars. Echo Protocol a été attaqué suite à une fuite de clé privée, permettant aux attaquants de frapper 1000 eBTC (valeur nominale d'environ 76,7 millions de dollars), mais en raison de la liquidité limitée, le bénéfice réel final était d'environ 5,13 millions de dollars.

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

Les cibles des attaques incluent divers types tels que ponts cross-chain, échanges décentralisés, protocoles de prêt, marchés de prédiction, stablecoins, utilisateurs ordinaires, etc. Parmi eux, les ponts cross-chain ont subi les pertes les plus importantes, atteignant 27,995 millions, et les projets liés à DeFi ont été le plus souvent attaqués, avec 14 incidents recensés.

La chaîne ayant enregistré le plus de pertes en mai est Ethereum, avec plus de 48,76 millions de dollars, et de nombreux incidents de sécurité sur des ponts cross-chain et la majorité des protocoles DeFi continuent de se concentrer sur Ethereum. Ensuite viennent BNB Chain, Monad, TON, ainsi que Monero et Bitcoin, indiquant une tendance multi-chaînes dans les attaques.

Analyse des principaux incidents de sécurité

1. Verus : Défaut de validation des messages cross-chain

Le fonctionnement du pont Verus-Ethereum repose sur la soumission par un opérateur de preuves attestant qu'une sortie valide a été confirmée par une notarisation sur la chaîne Verus, puis le contrat de pont vérifie cette preuve pour libérer des actifs sur Ethereum. La vulnérabilité réside dans le fait que le contrat de pont sur Ethereum, bien qu'il vérifie la preuve provenant de Verus, ne vérifie pas si cette preuve correspond à une sortie valide d'origine, permettant à un attaquant de construire une fausse sortie qui passe la vérification et d'extraire des fonds bien supérieurs à leur dépôt.

Partie du code vulnérable :

Cet incident est similaire à ceux qui ont causé des pertes de 320 millions de dollars avec Wormhole en 2022 et 190 millions de dollars avec Nomad, où le vérificateur a validé le message lui-même sans vérifier la valeur des fonds sous-jacents.

2. Trusted Volumes : Défaut dans la signature

L'attaquant a exploité un défaut dans la conception des signatures lors du processus de demande de devis (RFQ) de TrustedVolumes. Lors du transfert, il a personnalisé les données de signature pour définir le destinataire comme le contrat Resolver de TrustedVolumes, puis a réussi à faire valider cette signature, permettant de transférer les actifs du contrat Resolver et de réaliser un profit.

Partie du code vulnérable :

La vérification d'autorisation se réfère à varg4, mais le transfert de fonds utilise d'autres paramètres, et l'absence de vérification entraîne une incohérence entre le domaine du signataire autorisé et l'adresse de débit réelle.

Ainsi, l'attaquant n'a qu'à signer une commande avec une adresse de signataire enregistrée (même si la vérification par signature est réussie), avec d'autres paramètres (jetons, montants) fixés arbitrairement, par exemple une fausse commande 1:1, qui passe la vérification de prix de l'oracle, puis il peut retirer des fonds du contrat de protocole :

3. Fuite de clé privée dans le cas de StablR

En mai, plusieurs incidents de fuite de clé privée ont été signalés, avec des pertes totalisant plus de 25 millions de dollars. Parmi eux, StablR, en tant qu'émetteur de stablecoins conformes, est devenu un exemple typique de leçon en matière de sécurité et de gouvernance dans le secteur des stablecoins et DeFi.

StablR a lancé deux produits de stablecoins conformes : EURR et USDR. La multi-signature contrôlant la frappe de EURR est 0x8278D2881dBF8F6Fc01c98d196c4b16F1aade5Bc ; celle contrôlant USDR est 0xF45392bd2D6e6b8C5Dc26BA6c8a12889419B82F3.

Les deux portefeuilles multi-signatures mentionnés nécessitent une seule signature pour initier une transaction. En contrôlant l'adresse propriétaire 0xC73fD562de86d7860EE636C20813Bcb2cF4D550d, l'attaquant a pu ajouter l'adresse 0xD4677B5A8B1b97EA213Fdb876b0FcBAB3f9F6CD1 à ces portefeuilles, obtenant ainsi le contrôle des droits de frappe de la monnaie du projet :

Ce type d'incident ne résulte pas d'une faille dans le code, mais d'un problème de sécurité opérationnelle : mauvaise gestion des clés privées des adresses privilégiées, absence de multi-signatures à seuil élevé pour les opérations à haute valeur, absence de verrouillage temporel pour les grandes frappes, et manque de mécanismes d'intervention rapide.

Tendances des menaces de sécurité Web3

En 2026, la tendance la plus profonde en matière de sécurité Web3 est l'expansion systématique de la surface d'attaque. Les vulnérabilités apparaissent simultanément dans le code, l'infrastructure, les interactions et les processus humains, et une simple vérification de sécurité ou des outils ne suffisent pas pour couvrir la sécurité opérationnelle, les employés, l'infrastructure cloud ou la chaîne d'approvisionnement logicielle. Cela impose des exigences plus élevées pour la sécurité opérationnelle continue des projets Web3.

De plus, les attaques contre des contrats obsolètes ou abandonnés sont fréquentes, exploitant souvent des vulnérabilités ou des autorisations facilement attaquables. Les développeurs ou opérateurs de contrats doivent vérifier à nouveau la sécurité des contrats antérieurs, traiter ou transférer rapidement les fonds restants des contrats obsolètes, et contacter les utilisateurs pour annuler les autorisations inutiles. Les utilisateurs doivent également régulièrement vérifier et révoquer les autorisations de contrats obsolètes via des explorateurs blockchain ou des outils de révocation.