À l’intérieur du piratage du bridge Verus‑Ethereum à 11,5 millions de dollars

Après ces swaps, les fonds ont été consolidés en environ 5 402 ETH, probablement pour simplifier leur déplacement vers d’autres protocoles ou blockchains.

Pourquoi les preuves cryptographiques semblaient valides

À première vue, l’attaque semblait difficile à expliquer, car le système de preuve cryptographique du bridge fonctionnait apparemment correctement.

Le bridge Verus utilisait des state roots notarisées et des preuves de Merkle pour confirmer qu’une transaction existait bien sur la blockchain source avant d’autoriser un retrait sur Ethereum.

Une preuve de Merkle permet de démontrer qu’une donnée spécifique est incluse dans un bloc ou un arbre d’état. Mais elle ne garantit pas que la transaction est économiquement valide, ni que les fonds correspondants ont réellement été verrouillés.

Les enquêteurs ont constaté que le smart contract :

• vérifiait correctement les state roots notarisées
• vérifiait correctement l’inclusion via Merkle proof
• mais ne vérifiait pas que le montant réclamé correspondait réellement à des actifs bloqués sur la chaîne source.

Autrement dit, le système authentifiait la présence d’un message… mais pas le droit d’effectuer le paiement associé.

La faille : une simple vérification manquante

Les chercheurs en sécurité décrivent le problème comme une erreur classique de logique métier dans un smart contract.

Dans un bridge correctement sécurisé, le contrat côté Ethereum devrait vérifier que plusieurs paramètres correspondent exactement aux données prouvées sur la chaîne source :

• le type de token
• le montant du transfert
• l’adresse du destinataire
• l’état comptable des réserves du bridge

Sans cette vérification, le contrat a accepté des retraits non couverts par des dépôts réels.

Selon les analyses préliminaires, l’attaquant aurait dépensé seulement quelques dollars de frais sur la chaîne Verus pour déclencher des retraits valant des millions sur Ethereum.

Comme la vulnérabilité provient d’une règle de validation manquante et non d’un problème cryptographique, les développeurs auraient préparé un correctif en Solidity pour combler cette faille.

Un schéma déjà vu : Wormhole et Nomad

L’attaque du bridge Verus s’inscrit dans un schéma déjà observé dans plusieurs piratages majeurs de bridges blockchain.

Wormhole (2022)

En février 2022, le bridge Wormhole a subi une attaque qui a permis à un pirate de créer 120 000 wrapped ETH, pour une valeur supérieure à 320 millions de dollars. L’attaque reposait sur un contournement du mécanisme de vérification des signatures.

Le système a été trompé en lui faisant croire que des fonds avaient été déposés alors que ce n’était pas le cas.

Nomad (2022)

Le bridge Nomad a été vidé d’environ 190 millions de dollars en août 2022 après une erreur de configuration qui faisait accepter automatiquement certaines transactions comme valides. Cela a permis à des attaquants de copier ou falsifier des messages pour débloquer des fonds.

Où se situe le cas Verus

L’attaque contre Verus ressemble davantage à celle de Nomad :

• les preuves ou messages semblaient valides
• mais la logique qui vérifiait ce qu’ils autorisaient réellement était incorrecte.

Résultat : des retraits non garantis depuis les réserves du bridge.

Pourquoi les bridges restent une cible majeure

Les bridges cross‑chain restent l’un des composants les plus risqués de la finance décentralisée, car ils combinent plusieurs mécanismes complexes :

• vérification cryptographique
• messagerie entre blockchains
• comptabilité des smart contracts
• conservation de réserves importantes d’actifs

Si une seule étape de validation échoue, le protocole peut autoriser des retraits supérieurs aux actifs réellement bloqués.

La leçon principale de l’incident Verus est simple :

« preuve vérifiée » ne signifie pas « transfert valide ».

Même avec une cryptographie correcte, les contrats doivent vérifier strictement les montants, les actifs, les destinataires et la cohérence comptable.

Remboursement et assurances : quelles options ?

Au moment où les premières informations ont émergé, peu de détails publics étaient disponibles concernant un éventuel remboursement ou un plan de récupération des fonds. Certaines informations initiales provenaient encore de rapports préliminaires et d’alertes de surveillance blockchain.

Si les actifs volés ne sont pas récupérés, plusieurs scénarios restent possibles :

• utilisation de réserves du projet
• décisions de gouvernance de la communauté
• négociations avec l’attaquant
• activation éventuelle d’une assurance DeFi

Ces questions relancent aussi un débat dans l’écosystème : faut‑il considérer ce type d’incident comme un bug de smart contract, un problème d’infrastructure, ou un risque de conception protocolaire — une distinction importante pour les fournisseurs d’assurance crypto.

La leçon pour la DeFi

Le piratage du bridge Verus‑Ethereum rappelle que les vulnérabilités les plus coûteuses ne viennent pas toujours de la cryptographie.

Souvent, elles proviennent d’une petite erreur dans la logique de validation d’un smart contract.

Un protocole peut vérifier parfaitement signatures, preuves et racines d’état — et rester vulnérable si le contrat ne confirme pas que les données prouvées autorisent réellement le transfert exécuté.

Cette nuance technique a déjà coûté des milliards de dollars à l’écosystème DeFi lors de différents piratages de bridges. L’incident Verus en est une nouvelle illustration.