
Beosin : 36 incidents de sécurité majeurs en mai, pour des pertes totales dépassant 76 millions de dollars américains
TechFlow SélectionTechFlow Sélection

Beosin : 36 incidents de sécurité majeurs en mai, pour des pertes totales dépassant 76 millions de dollars américains
La tendance la plus profonde en matière de sécurité Web3 en 2026 est l’élargissement systémique de la surface d’attaque.
Rédaction : Beosin
Selon les données recueillies par la plateforme Beosin Alert, les pertes cumulées liées aux incidents de sécurité survenus en mai 2026 s’élèvent à environ 76,15 millions de dollars américains. Au total, « 36 » cyberattaques majeures ont été recensées, principalement dues à des vulnérabilités dans les contrats intelligents et à des fuites de clés privées. Parmi ces incidents, 17 résultent de vulnérabilités contractuelles ou réseau, tandis que 10 sont imputables à des fuites de clés privées. La sécurité du code et la sécurité opérationnelle au sein de l’écosystème DeFi font face à des défis sans précédent.
Top 10 des protocoles ayant subi les pertes les plus importantes en mai
Le pont interchaînes Verus-Ethereum Bridge, reliant la chaîne Verus L1 à Ethereum, a été victime d’une attaque exploitant une vulnérabilité contractuelle, entraînant la perte la plus importante du mois : 11,58 millions de dollars américains. Quant à Echo Protocol, il a subi une attaque découlant d’une fuite de clé privée, permettant à l’attaquant de frapper 1 000 jetons eBTC (valeur nominale estimée à environ 76,7 millions de dollars américains) ; toutefois, en raison de limitations de liquidité, le gain effectif réalisé s’élève à environ 5,13 millions de dollars américains.
Types de projets ciblés et répartition des pertes par chaîne
Les cibles des attaques couvrent divers types d’acteurs : ponts interchaînes, bourses décentralisées (DEX), protocoles d’emprunt/prêt, marchés prédictifs, stablecoins, ainsi que des utilisateurs individuels. Les ponts interchaînes concentrent la plus forte perte financière, avec un montant atteignant 27,995 millions de dollars américains. En revanche, les projets liés au domaine DeFi ont été les plus fréquemment attaqués, avec un total de 14 incidents recensés.
La chaîne Ethereum a enregistré les pertes les plus élevées en mai, dépassant 48,76 millions de dollars américains. Une grande partie des incidents impliquant des ponts interchaînes et la majorité des protocoles DeFi restent centrés sur Ethereum. Viennent ensuite BNB Chain, Monad et TON. Des incidents de sécurité ont également été signalés sur Monero et Bitcoin, confirmant une tendance claire vers des attaques multi-chaînes.
Analyse des principaux incidents de sécurité
1. Verus : Défaut de validation des messages interchaînes
Le pont Verus-Ethereum fonctionne selon le principe suivant : un soumetteur fournit des données probatoires attestant qu’une sortie valide, certifiée par un notaire, existe bien sur la chaîne Verus ; le contrat du pont procède alors à la vérification, puis libère les actifs correspondants sur Ethereum. La vulnérabilité réside dans le fait que le contrat du pont côté Ethereum, bien qu’il vérifie effectivement la preuve provenant de Verus, ne contrôle pas si cette donnée correspond bel et bien à une sortie originale valide. Ainsi, un attaquant peut fabriquer une sortie factice passant la vérification et retirer des fonds largement supérieurs à ses dépôts initiaux.
Extrait du code vulnérable :
Cette faille appartient à la même catégorie que celles ayant causé, en 2022, la perte de 320 millions de dollars américains pour Wormhole et de 190 millions de dollars américains pour Nomad : dans tous les cas, le pont valide le message lui-même, mais omet de vérifier la valeur sous-jacente des fonds concernés.
2. Trusted Volumes : Défaut dans les paramètres de signature
L’attaquant a exploité une faiblesse dans la conception des signatures utilisée dans le processus de demande de prix (RFQ) de TrustedVolumes. Lors d’un transfert réel, il a pu personnaliser les données de signature afin de désigner le contrat Resolver de TrustedVolumes comme expéditeur du transfert, ce qui a permis de passer la vérification et de transférer illégalement les actifs détenus par ce contrat.
Extrait du code vulnérable :
La vérification d’autorisation fait référence au paramètre varg4, tandis que l’exécution du transfert de fonds utilise d’autres paramètres. Cette absence de cohérence dans les vérifications entraîne une divergence entre l’adresse signataire autorisée et l’adresse réelle débitée.
Ainsi, l’attaquant n’a eu besoin que de signer une commande à l’aide d’une adresse de signataire déjà enregistrée, en définissant maker = Exploit (ce qui passe la vérification de signature), tandis que les autres paramètres de signature (jeton, montant) pouvaient être fixés arbitrairement — par exemple, une commande bidon avec un ratio 1:1 — afin de satisfaire la vérification de prix effectuée par l’oracle de prix. Le transfert des actifs depuis le contrat du protocole pouvait alors s’effectuer sans obstacle :
3. Exemple d’incident de fuite de clé privée : StablR
En mai, plusieurs incidents de fuite de clé privée se sont produits, entraînant des pertes globales supérieures à 25 millions de dollars américains. StablR, émetteur de stablecoins réglementés, est devenu un cas d’école illustrant les lacunes de gouvernance en matière de sécurité, tant pour le secteur des stablecoins que pour l’ensemble de l’écosystème DeFi.
StablR propose deux produits de stablecoins conformes à la réglementation : EURR et USDR. Le portefeuille multisignature chargé de la frappe d’EURR est l’adresse 0x8278D2881dBF8F6Fc01c98d196c4b16F1aade5Bc ; celui gérant la frappe d’USDR est l’adresse 0xF45392bd2D6e6b8C5Dc26BA6c8a12889419B82F3.
Or, ces deux portefeuilles multisignatures ne requièrent qu’une seule signature pour initier une transaction. En prenant le contrôle de l’adresse propriétaire 0xC73fD562de86d7860EE636C20813Bcb2cF4D550d, l’attaquant a réussi à ajouter l’adresse 0xD4677B5A8B1b97EA213Fdb876b0FcBAB3f9F6CD1 aux deux portefeuilles multisignatures précités, obtenant ainsi le contrôle total des droits de frappe du projet :
Cet incident ne relève pas d’une vulnérabilité logicielle, mais d’un défaut de sécurité opérationnelle : mauvaise gestion des clés privées associées aux adresses privilégiées, absence d’utilisation de seuils de signature élevés pour les opérations à haut risque ou à forte valeur, absence de verrouillage temporel (time-lock) pour les opérations massives de frappe, et manque d’un mécanisme de réponse d’urgence efficace.
Tendances des menaces de sécurité dans l’écosystème Web3
La tendance la plus profonde observée en matière de sécurité Web3 en 2026 est l’élargissement systémique de la surface d’attaque. Les vulnérabilités apparaissent désormais simultanément au niveau du code, des infrastructures, des interactions opérationnelles et des processus humains. Aucune série d’audits de sécurité ni aucun outil unique ne suffit à couvrir les domaines critiques tels que la sécurité opérationnelle, les terminaux des employés, les infrastructures cloud ou encore la chaîne logicielle d’approvisionnement. Cela impose aux projets Web3 des exigences accrues en matière de sécurité opérationnelle continue.
Par ailleurs, les attaques contre des contrats anciens ou abandonnés se multiplient, ces derniers comportant souvent des vulnérabilités ou des mécanismes d’autorisation aisément exploitables. Les développeurs et opérateurs de contrats sont invités à réexaminer soigneusement la sécurité de leurs contrats antérieurs. Pour les contrats obsolètes, il convient de traiter rapidement les fonds restants ou de les transférer de manière sécurisée, et de contacter les utilisateurs afin qu’ils révoquent toute autorisation inutile. Les utilisateurs, quant à eux, doivent régulièrement vérifier, via des explorateurs blockchain ou des outils spécialisés, les autorisations accordées à des contrats qu’ils n’utilisent plus, et les révoquer le cas échéant.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News












