Exploit du pont Ethereum Verus : le même bug à 11,58 millions de dollars
Le 18 mai 2026, quelqu'un a vidé le bridge Verus-Ethereum de 11,58 millions de dollars. D'après le reportage de CoinDesk, c'était le huitième hack de bridge de l'année. L'exploit du bridge Verus Ethereum ne reposait pas sur une nouvelle classe d'attaque exotique. C'était le même échec qui tue les bridges depuis 2021 : le contrat libérait des fonds sur une chaîne sans vérifier correctement ce qui s'était réellement passé sur l'autre.
La fonction vulnérable avait un nom, cette fois. checkCCEValues. C'est la routine censée confirmer que les valeurs d'export cross-chain correspondaient à la réalité avant de minter ou de libérer des fonds côté Ethereum. Elle n'a pas fait son travail, et l'attaquant est reparti avec la mise.
J'ai passé quatre ans à construire des infrastructures adjacentes aux bridges dans un contexte réglementé, et ce qui est déprimant, c'est à quel point cela est devenu prévisible. On ne fait que renommer la même blessure.
L'exploit du bridge Verus Ethereum était un échec de validation de la source
Dépouillé de tout habillage, chaque bridge fait une seule chose. Il observe un événement sur la chaîne A (un dépôt, un verrou, un export) et produit une action correspondante sur la chaîne B (un mint, un déverrouillage, une libération). Tout le modèle de sécurité se réduit à une seule question : la chaîne B croit-elle vraiment ce que la chaîne A lui a dit, et a-t-elle vérifié ?
Quand la validation qui confirme les montants côté source est défaillante, la réponse devient « non ». L'attaquant forge ou gonfle la valeur d'export déclarée, le contrat de destination lui fait confiance, et des tokens qui n'ont jamais été couverts sont mintés ou libérés. The Block a rapporté une perte d'environ 11,58 millions de dollars, drainée précisément via ce type de faille comptable dans la vérification des exports cross-chain.
C'est la validation du montant source dans un bridge, et c'est la fonction la plus critique de tout le système. Se tromper d'une comparaison suffit à transformer le bridge en imprimante à argent gratuit.
checkCCEValues n'est que le nouveau nom d'une ancienne vulnérabilité
La vulnérabilité checkCCEValues est structurellement identique à des bugs qui ont déjà coûté des milliards à l'industrie. Les noms changent. Le mécanisme, non.
- Wormhole, 2022 : une faille dans la vérification des signatures a permis à un attaquant de minter 120 000 ETH enveloppés qui n'avaient jamais été déposés.
- Nomad, 2022 : une initialisation bâclée de la racine de Merkle faisait valider n'importe quel message comme vrai, et le bridge a été pillé par copier-coller par la foule.
- Multichain, 2023 : des clés et des hypothèses de confiance que personne ne pouvait réellement vérifier de l'extérieur.
Chacun de ces cas était, dans sa nature, la chaîne de destination libérant de la valeur sans preuve solide de l'événement source. checkCCEValues est l'orthographe 2026 du même mot.
Je pense que l'industrie continue de traiter ces incidents comme des erreurs d'ingénierie individuelles alors qu'il s'agit d'un échec de catégorie. On ne règle pas un problème de catégorie en auditant une fonction plus attentivement.
Le financement via Tornado Cash révèle l'intention de l'attaquant
Le portefeuille de l'attaquant a été approvisionné via Tornado Cash avant l'exploit. Ce détail compte moins pour l'attribution que pour ce qu'il révèle sur la préparation. Ce n'était pas un whitehat qui sondait un contrat et s'est retrouvé surpris par le résultat. Le schéma de l'attaquant financé via Tornado Cash est la signature de quelqu'un qui a mis en place une couverture opérationnelle plusieurs jours à l'avance et s'attendait à devoir blanchir les fonds à la sortie.
C'est ce que les défenseurs sous-estiment. Au moment où la transaction d'exploit atterrit, la voie de sortie est déjà construite. Le traçage post-hoc aide les procureurs, mais ne fait presque rien pour le protocole qui vient de perdre huit chiffres.
Les failles de sécurité des bridges sont désormais une taxe mensuelle
En prenant du recul, le hack Verus est une ligne budgétaire, pas une anomalie. Selon les données PeckShield citées par Bitcoin.com, les exploits de bridges crypto ont totalisé environ 328 millions de dollars en mai 2026 seulement. Huit incidents en moins de cinq mois.
Le marché a tranquillement intégré cela comme un coût du business cross-chain. C'est la mauvaise leçon. Une perte mensuelle récurrente à neuf chiffres n'est pas de la volatilité, c'est un défaut structurel que l'espace de conception refuse d'affronter.
Pour quiconque déplace de la valeur réelle, la conclusion est inconfortable : la plupart des bridges sont des hypothèses de confiance déguisées en mathématiques. J'ai déjà soutenu, dans Comment les bridges de stablecoins échouent réellement, que le bridge le plus sûr est souvent celui qui admet à quel point il vérifie peu de choses.
À quoi ressemble une vérification de bridge réellement défendable
Si vous construisez ou auditez un bridge, la validation du montant source est là où vous devriez concentrer une part disproportionnée de votre paranoïa. Voici quelques points que je considérerais comme non négociables :
- Le contrat de destination doit vérifier une preuve cryptographique de l'événement source, pas la parole d'un relayer. Des preuves light-client ou zk plutôt que des attestations multisig partout où le budget de latence le permet.
- Les vérifications de montant doivent être exhaustives sur chaque chemin d'exécution. La classe de bugs
checkCCEValuesse cache généralement dans une branche que certaines entrées contournent. Fuzzez la comparaison, ne vous contentez pas de l'inspecter. - Des limites de débit et des coupe-circuits par actif, afin qu'une valeur forgée ne puisse pas vider toute la réserve en une seule transaction. Un plafond qui se met en pause automatiquement à, disons, 5 % du TVL par heure aurait atténué la plupart des incidents de 2026.
- Une surveillance indépendante des invariants qui compare en temps réel le total minté au total verrouillé et s'arrête en cas de divergence.
Rien de tout cela n'est nouveau. La pile d'audit pour détecter ces vulnérabilités existe, ce que j'ai approfondi dans l'article sur la pile d'audit. Le problème, c'est que les bridges continuent de livrer la validation comme une réflexion après coup plutôt que comme le cœur du produit.
Le prochain hack de bridge de 2026 est déjà en cours d'écriture. Il aura un nom de fonction différent et la même cause première, et nous ferons semblant d'être surpris. On ne devrait pas.