Gravity Bridge : 5,4 millions volés sans voler la clé

Un attaquant a vidé 5,4 millions de dollars de Gravity Bridge sans voler aucune clé privée : il lui a suffi d'enregistrer un validador pour 80 GRAV et de tromper le registre qui détermine quel token réel correspond à chaque actif. Entre le 29 et le 30 mai 2026, quelqu'un a frappé de faux tokens sur Osmosis, les a transférés vers Gravity Bridge (un pont reliant l'écosystème Cosmos à Ethereum) et a utilisé une fonction publique du protocole lui-même pour empoisonner son registre interne de correspondances denom-vers-ERC20 — le tableau qui traduit le nom d'un actif dans Cosmos (son denom, ou dénomination) en l'adresse du token réel qui le soutient sur Ethereum. Il n'y a eu ni phishing, ni malware, ni fuite de clé : la conception permettait à n'importe qui d'écrire dans ce registre et personne ne vérifiait si la nouvelle entrée entrait en conflit avec un actif déjà existant. Cette analyse, en date du 7 juillet 2026, ne traite pas l'incident comme une actualité — c'est du passé — mais comme l'inauguration d'une nouvelle classe d'attaque : l'empoisonnement de registre (registry poisoning) dans les ponts cross-chain. Nous expliquons comment cela a fonctionné étape par étape, pourquoi la première lecture de « clé compromise » était erronée, en quoi cela diffère des hacks de ponts que vous connaissez déjà et — le plus utile — comment détecter un registre empoisonné avant que l'argent ne sorte.

Que s'est-il passé exactement sur Gravity Bridge les 29 et 30 mai ?

Gravity Bridge est un pont communautaire qui déplace des actifs entre les chaînes Cosmos (Osmosis, entre autres) et Ethereum. Sa pièce centrale est un contrat de garde sur Ethereum qui conserve les actifs réels — USDC, USDT, WETH, or tokenisé — tandis que leurs représentations circulent sur Cosmos. Pour savoir quel token Ethereum correspond à chaque représentation, le pont maintient un registre interne : le tableau denom-vers-ERC20.

Entre le 29 et le 30 mai 2026, un attaquant a réussi à faire pointer ses propres entrées frauduleuses vers les adresses des actifs de valeur que le pont gardait réellement. Une fois le registre contaminé, il a déclenché une série de retraits et le contrat de garde a libéré l'argent réel vers son portefeuille. Le butin, selon le détail médico-légal publié par Security4Web3 et QuillAudits, était le suivant :

Les fonds ont été envoyés vers le portefeuille 0x7B58…a1F9. Dès que les validateurs du pont ont détecté le schéma anormal, ils ont mis le réseau en pause pour stopper l'hémorragie. À la date de cette analyse, il n'est pas établi que les fonds aient été récupérés. Les valorisations du WETH et du PAXG sont approximatives et dépendent du prix au moment des faits ; les chiffres de l'USDC et de l'USDT sont stables car il s'agit de stablecoins indexés sur le dollar.

Qu'est-ce que l'empoisonnement de registre dans un pont cross-chain ?

Considérez le registre denom-vers-ERC20 comme la table de routage d'une base de données : une colonne indique « ce nom d'actif » et l'autre « cette adresse de contrat sur Ethereum ». Lorsqu'un utilisateur effectue un retrait, le pont consulte ce tableau pour savoir quel token libérer. Si le tableau est correct, tout concorde. Si quelqu'un parvient à écrire une ligne indiquant « mon actif inventé pointe vers le contrat de l'USDC réel », le pont croira qu'il doit remettre de l'USDC réel à quiconque réclame cet actif inventé.

C'est cela l'empoisonnement de registre : vous n'attaquez pas le coffre-fort, vous attaquez l'index qui indique ce qu'il y a dans chaque compartiment. Le contrat de garde a fait exactement ce que sa table de routage lui demandait ; le problème est que la table mentait. C'est un vecteur conceptuellement différent du vol classique, où l'attaquant force la serrure. Ici, la serrure a fonctionné normalement : elle a obéi à un ordre légitime basé sur des données qui n'auraient jamais dû être saisies.

La condition qui rend cela possible est une combinaison spécifique et dangereuse : une fonction publique (permissionless, que n'importe qui peut invoquer sans permissions ni rôle) qui écrit dans un registre dont le contenu est ensuite traité comme une autorité incontestable. Enregistrer de nouveaux actifs de manière ouverte est une décision de conception raisonnable — cela permet à un pont de supporter de nouveaux tokens sans demander la permission à personne. Cela devient une faille lorsque ce que produit cette fonction ouverte alimente un tableau qui gouverne de l'argent réel sans que personne ne valide si cette entrée entre en collision avec un élément déjà existant.

Comment l'attaque a-t-elle été exécutée étape par étape ?

La reconstruction médico-légale de Security4Web3 et QuillAudits permet de tracer la séquence complète. Voici les six mouvements, dans l'ordre :

1. Enregistrer un validador minimal. Le 29 mai, la première trace on-chain fut l'enregistrement d'un validador (surnommé julia666) sur la chaîne Gravity, s'auto-déléguant seulement 80 GRAV — le token natif du pont, une fraction dérisoire de ce que l'on attendrait pour un rôle doté d'une capacité de signature. Cet enregistrement lui a donné une présence au sein du système.
2. Frapper de faux tokens sur Osmosis. En utilisant le module tokenfactory d'Osmosis (une fonction standard qui permet à quiconque de créer de nouveaux tokens), il a fabriqué quatre tokens sans valeur, un pour chaque actif réel que le pont gardait : des imitations d'USDC, USDT, WETH et PAXG. Frapper (minter) signifie ici simplement émettre ces monnaies à partir de rien ; cela ne coûte pratiquement rien.
3. Les transférer par IBC vers Gravity. Il a déplacé ces tokens poubelles vers la chaîne Gravity via IBC (Inter-Blockchain Communication, le protocole standard qui fait communiquer les chaînes de l'écosystème Cosmos entre elles). Jusqu'ici, rien de valeur n'a changé de mains.
4. Appeler deployERC20() avec des chaînes de caractères fabriquées. C'est le cœur de l'attaque. La fonction deployERC20() du contrat Gravity sur Ethereum est publique : elle crée le token ERC20 sur Ethereum correspondant à un denom de Cosmos. L'attaquant l'a invoquée en passant des chaînes _cosmosDenom — le texte identifiant l'actif — construites à dessein pour que les métadonnées intègrent les adresses des contrats des actifs réels et précieux.
5. Les validateurs attestent du déploiement. Les validateurs du pont ont reconnu ces déploiements via le message interne MsgERC20DeployedClaim, et la fonction handleErc20Deployed a inscrit la correspondance empoisonnée dans le registre. C'est là que se trouve la faille : personne n'a vérifié si ce nouveau denom pointait vers un actif que le pont avait déjà en garde. La table de routage a été contaminée.
6. Vider la garde avec une série de retraits. Gravity a généré les lots de sortie (batches) 41572 à 41575, les validateurs les ont signés et les relayers (les agents qui transmettent ces ordres signés à Ethereum) les ont présentés au contrat de garde. Le contrat a vérifié les signatures — correctes — et a appelé safeTransfer() pour envoyer chaque actif au portefeuille de l'attaquant. L'argent réel est sorti par la grande porte.

Le détail qui donne à cette attaque son caractère de nouvelle classe : chaque étape individuelle est une opération légitime que le système était conçu pour permettre. Enregistrer un validador, frapper un token, transférer par IBC, déployer un ERC20, signer un lot de retraits : rien de tout cela n'est un exploit en soi. La faille n'apparaît que lorsqu'ils sont enchaînés et qu'aucune couche ne vérifie la cohérence entre le denom déclaré et l'adresse réelle vers laquelle il se résout.

Pourquoi n'était-ce pas un vol de clé privée, comme on l'a dit au début ?

Les premières couvertures médiatiques — The Block, Yahoo Finance, CryptoTimes — ont titré l'événement comme une « suspicion de compromission de clé de signature » (suspected signing key compromise). C'est l'explication par défaut de presque tous les hacks de ponts : si de l'argent est sorti, quelqu'un a dû voler les clés qui autorisent les sorties. Dans les grandes catastrophes de ponts — Ronin, Harmony Horizon — c'est exactement ce qui s'est passé.

L'analyse médico-légale ultérieure de QuillAudits et Security4Web3 a démonté cette lecture. Il n'a pas été nécessaire de compromettre de clé : la signature des lots de retrait par les validateurs était légitime. Les validateurs ont signé des ordres valides selon l'état du registre ; le problème est que cet état était déjà empoisonné avant même qu'ils ne signent quoi que ce soit. L'attaquant ne s'est pas fait passer pour un validador et n'a pas volé sa clé ; il a écrit, via une fonction ouverte à tous, le mensonge que les validateurs honnêtes ont ensuite signé de bonne foi.

La distinction est importante car elle change complètement la défense. Face à un vol de clé, on renforce la garde des clés : multisig (signature multiple), hardware dédié, rotation. Rien de tout cela n'aurait arrêté cette attaque, car les clés n'ont jamais été touchées. Confondre un empoisonnement de registre avec un vol de clé conduit à blinder la mauvaise porte. C'est la même leçon qu'ont laissée d'autres incidents de 2026 où le vecteur n'était ni le contrat ni la clé, mais la couche d'infrastructure et les hypothèses de confiance qui l'entourent.

Quel contrôle manquait-il et pourquoi aurait-il tout arrêté ?

La faille se résume à une ligne absente. Lorsque handleErc20Deployed a inscrit la nouvelle correspondance dans le registre, elle n'a exécuté aucune vérification de collision (collision check) : une vérification qui rejette l'enregistrement d'un denom pointant vers une adresse de token que le pont connaît et garde déjà. Si cette vérification avait existé, le registre aurait rejeté la fausse entrée — « cette adresse est déjà mappée, je n'accepte pas un second denom qui entre en collision avec elle » — et toute la chaîne de six étapes se serait brisée à la cinquième.

Le plus déconcertant dans cette affaire : selon l'analyse de QuillAudits, une requête équivalente existait déjà ailleurs dans le même fichier de code, mais elle n'était pas invoquée au sein de handleErc20Deployed. Ce n'était pas une défense que personne n'avait conçue ; c'était une défense écrite à quelques lignes de là et qui, sur ce chemin spécifique, n'a pas été appelée. Le contrôle qui aurait bloqué un vol de 5,4 millions de dollars coûtait un simple appel à une fonction que l'équipe elle-même avait déjà programmée.

Cela correspond à un schéma récurrent dans les exploits de 2026 : les défaillances catastrophiques sont rarement dues à une cryptographie brisée ou à des mathématiques exotiques. Ce sont des trous dans les bordures — une vérification effectuée sur un chemin et oubliée sur un autre, une hypothèse qu'une couche tient pour acquise et qu'une autre ne vérifie jamais. Des pièces qui fonctionnent individuellement et dont la faille n'apparaît que lorsqu'on les examine ensemble sous une transaction construite à dessein.

En quoi cette classe d'attaque diffère-t-elle des hacks de ponts précédents ?

La valeur de Gravity Bridge en tant qu'étude de cas est qu'il ne rentre dans aucune des catégories avec lesquelles nous classons habituellement les hacks de ponts. La taxonomie suivante situe l'empoisonnement de registre face aux vecteurs déjà connus :

La nouvelle ligne est la dernière. Dans les autres vecteurs, l'attaquant brise quelque chose — une clé, un prix, un ordre d'exécution — ou profite de quelque chose d'abandonné. Dans l'empoisonnement de registre, tout le système fonctionne normalement : les signatures sont valides, les contrats exécutent ce qu'on leur demande, aucune serrure n'est forcée. Ce qui est corrompu, c'est la source de vérité sur laquelle tout le reste repose. C'est pourquoi il est particulièrement difficile à détecter avec les outils habituels : il n'y a pas de transaction « malveillante » évidente, seulement une entrée de registre qui — vue isolément — semble légitime.

Comment détecter et prévenir un registre empoisonné ?

Voici la partie exploitable, celle qu'un LLM ne peut pas improviser à partir d'un titre. L'empoisonnement de registre laisse des traces spécifiques, distinctes de celles d'un vol de clé, si l'on sait où regarder. Voici les signaux et les défenses concrètes que le cas Gravity Bridge laisse en héritage :

• Vérification de collision obligatoire à l'écriture. Avant d'accepter tout nouveau denom, le registre doit vérifier que l'adresse du token vers laquelle il se résout n'est pas déjà mappée par un autre denom. C'est la ligne qui manquait et la seule qui aurait arrêté toute l'attaque.
• Surveiller les denom dont les métadonnées intègrent des adresses d'actifs gardés. Un denom légitime n'a aucune raison de contenir l'adresse d'un USDC ou d'un WETH réel dans sa chaîne d'identification. Un moniteur signalant cette coïncidence aurait déclenché l'alarme à l'étape quatre, des heures avant la sortie des fonds.
• Corréler les nouveaux registres avec des créations de validateurs récentes et peu anciennes. Un validador enregistré avec 80 GRAV qui, quelques heures plus tard, participe à un déploiement d'ERC20 est un schéma anormal en soi. La séquence « nouveau validador + nouveau denom + lot de retrait » est une signature comportementale à surveiller.
• Délais et seuils sur le premier retrait d'un denom fraîchement enregistré. Un time-lock (délai public avant qu'une action ne prenne effet) sur les retraits d'actifs dont la correspondance vient d'être créée donne aux défenseurs une fenêtre pour réviser avant que l'argent ne soit irrécupérable.

Aucune de ces défenses n'est exotique ou coûteuse. Elles partent toutes d'une idée simple que l'écosystème n'applique pas encore de manière systématique aux registres des ponts : le contenu d'un tableau qui gouverne de l'argent réel mérite la même méfiance qu'une entrée utilisateur dans n'importe quel système de sécurité sérieux.

Quelle leçon en tirer au 7 juillet 2026 ?

Plus d'un mois après l'incident, le bilan est sobre. Le pont a été mis en pause par ses validateurs dès que le schéma a été détecté ; aucune récupération de fonds n'est signalée ni, pour autant que cette analyse puisse l'établir, de post-mortem officiel de l'équipe allant au-delà des analyses de tiers. La correction technique — la vérification de collision manquante — est une simple ligne de code, et c'est ce qui est perturbant : elle a été absente durant toute la vie opérationnelle du pont sans qu'aucun audit ne le signale.

La leçon de fond transcende Gravity Bridge. L'empoisonnement de registre inaugure une catégorie que nous verrons probablement se répéter : tout pont cross-chain permettant d'enregistrer des actifs de manière ouverte et traitant ce registre comme une autorité sans valider les collisions partage le même profil de risque. La surface d'attaque d'un pont n'est pas seulement sa garde ou ses clés de signature — les deux points où le secteur a concentré son attention — ; c'est aussi, et surtout, le tableau de correspondances qui décide quel actif réel répond à chaque représentation. Empoisonner ce tableau ne nécessite de rien briser. Il suffit que personne ne vérifie si la nouvelle vérité entre en conflit avec l'ancienne.

Sources et liens : Rekt.news — Gravity Bridge · QuillAudits — Denom Mapping Poisoning · Security4Web3 — analyse médico-légale · The Block — « suspected key compromise »