THORChain : hack de 10,8 M$ et un halt de 13 heures

Le 15 mai 2026, un seul nœud malveillant a reconstitué la clé privée d'un coffre de THORChain et a drainé environ 10,8 millions de dollars répartis sur neuf chaînes simultanément. Il n'y a eu ni manipulation d'oracle ni bug de contrat intelligent : l'attaquant a brisé la cryptographie même qui répartit le contrôle des fonds entre des dizaines de validateurs. Le plus remarquable est survenu après. Le protocole qui s'est présenté pendant des années comme « inarrêtable » a stoppé ses signatures en quelques minutes et a gelé l'intégralité du réseau pendant près de 13 heures via une décision de gouvernance coordonnée, garantissant zéro perte pour les utilisateurs finaux sans émettre un seul nouveau RUNE. Cela laisse une question inconfortable sur le tapis : si une poignée d'opérateurs peut tout éteindre en quelques minutes, parle-t-on de décentralisation réelle ou d'un point de contrôle central doté d'un bon marketing ?

Que s'est-il passé exactement avec THORChain le 15 mai ?

THORChain est un protocole de liquidité cross-chain : il permet d'échanger, par exemple, du Bitcoin natif contre de l'Ethereum natif sans passer par un exchange centralisé et sans envelopper l'actif dans un token synthétique. Les fonds qui permettent chaque swap résident dans des réserves que le protocole appelle coffres Asgard.

Le 13 mai, un opérateur a rejoint l'ensemble des validateurs avec un nœud préparé pour l'attaque. Pendant deux jours, ce nœud a participé aux cérémonies de signature normales du protocole tout en exfiltrant, petit à petit, des fragments de la clé contrôlant l'un des coffres. Le 15 mai, il disposait de suffisamment de matériel pour reconstituer la clé privée complète de ce coffre — qui gérait environ un cinquième de tous les fonds du protocole — et signer seul des transferts sortants valides.

Résultat : environ 10,8 millions de dollars ont quitté le coffre sur neuf chaînes différentes (Bitcoin, Ethereum, BNB Chain, Base, Avalanche, Dogecoin, Litecoin, Bitcoin Cash et XRP) sans qu'aucun système de défense ne puisse stopper les signatures à temps, car aux yeux du protocole, ces signatures étaient légitimes. L'attaquant possédait la véritable clé.

Qu'est-ce qu'un coffre Asgard et comment sa clé est-elle répartie ?

Imaginez un coffre-fort dont la porte ne s'ouvre pas avec une seule clé, mais avec plusieurs réparties entre des dizaines de personnes ; il faut qu'un nombre minimum d'entre elles présentent leur clé en même temps. Personne ne peut l'ouvrir seul, et si une personne disparaît, le coffre continue de fonctionner avec les autres. C'est, conceptuellement, un coffre Asgard : le contrôle n'est pas aux mains d'un dépositaire unique, mais réparti entre de nombreux opérateurs de nœuds.

La technologie qui rend cela possible s'appelle la signature de seuil (TSS, pour threshold signature scheme) : chaque nœud ne conserve qu'un fragment de clé (key share), jamais la clé entière, et un quorum de fragments est nécessaire pour autoriser toute sortie de fonds. La clé privée complète, en théorie, n'existe sur aucun ordinateur à aucun moment — elle est reconstituée mathématiquement uniquement lors de l'instant de la signature, puis disparaît.

La promesse de sécurité est percutante : même si un attaquant compromet un nœud, ou plusieurs, il n'obtient rien d'utile tant qu'il n'atteint pas le quorum. C'est pourquoi le cas de THORChain est si frappant. L'attaquant n'a pas réuni le quorum : il a trompé les nœuds honnêtes pour qu'ils lui livrent, tour après tour, les morceaux qui lui manquaient.

Comment l'attaquant a-t-il brisé une signature de seuil sans réunir le quorum ?

THORChain implémente la signature de seuil avec une variante propre (un fork) de la bibliothèque tss-lib de Binance, qui applique le protocole cryptographique connu sous le nom de GG20. C'est là que se trouvait la faille.

Selon l'analyse indépendante du chercheur en sécurité Banteg, le fork de THORChain a omis une vérification de sécurité que la conception originale exige pourtant : lorsqu'un nœud se connecte, il doit prouver mathématiquement — par une preuve qui ne révèle aucun secret — que les paramètres cryptographiques qu'il fournit sont bien formés. Il s'agit d'une vérification de « solidité » sur un composant appelé module de Paillier. Dans la recette standard, elle est obligatoire ; dans la version modifiée de THORChain, elle n'était pas exécutée.

L'analogie : considérons les cérémonies de signature comme des réunions où chaque participant place son morceau de secret dans une boîte cadenassée et la transmet aux autres pour un calcul conjoint, confiant que la boîte de chacun est authentique et non un piège. La preuve de solidité est le garde qui vérifie que la boîte de chaque participant est légitime avant de le laisser entrer. THORChain a retiré le garde. L'attaquant s'est présenté avec une « boîte » manipulée et, chaque fois que les nœuds honnêtes y inséraient leur morceau pour collaborer à une signature, cette boîte truquée exfiltrait une parcelle du secret de chacun.

Répétée pendant deux jours et de nombreux cycles de signature, cette fuite — que les chercheurs décrivent comme une exfiltration progressive de matériel de clé — a suffi pour que l'attaquant accumule les pièces manquantes et reconstitue seul la clé privée complète du coffre. Dès lors, les signatures malveillantes étaient indiscernables des signatures légitimes : elles utilisaient la clé authentique.

La nuance importante est qu'il ne s'agissait pas d'une faille dans l'idée de la signature de seuil, mais d'une implémentation qui a supprimé un garde-fou. C'est une dette cryptographique : une bibliothèque complexe, un fork sans couverture de tests complète, et un détail omis que personne n'a exploité pendant des années jusqu'à ce que quelqu'un le fasse.

À combien s'est élevé le butin et comment a-t-il été réparti par chaîne ?

L'attaquant a consolidé les fonds sur une poignée d'adresses. Sur les chaînes compatibles avec Ethereum, la quasi-totalité du butin a atterri sur l'adresse 0x82fc0d…54eb ; sur Bitcoin, sur bc1ql4u…6f37. Répartition approximative de la valeur extraite :

Le nœud malveillant opérait depuis l'adresse de validateur thor16ucjv…cn84q. Contrairement au cas d'Echo sur Monad — où l'attaquant a émis 77 millions nominaux mais n'a pu monétiser que 816 000 dollars faute de liquidité pour vendre —, ici le dommage nominal et le dommage réel coïncident : l'attaquant n'avait pas besoin d'un marché pour vendre quoi que ce soit. Il a extrait des actifs réels et échangeables directement du coffre. C'est pourquoi les 10,8 millions ont été réellement perdus, sans le « pare-feu accidentel » de l'illiquidité.

Comment THORChain a-t-il réussi à s'arrêter en quelques minutes ?

Le système de défense de THORChain surveille constamment une chose très simple : ce que le protocole pense posséder par rapport à ce qu'il y a réellement sur chaque chaîne externe. C'est une vérification automatique de solvabilité, une sorte d'inventaire permanent. Lorsque les soldes réels ont commencé à chuter sans opérations légitimes pour le justifier, les alertes se sont déclenchées d'elles-mêmes : quelques minutes après le début du drainage, cette vérification a forcé la couche de communication avec les chaînes externes (Bifrost) à cesser de signer des transactions automatiquement, sans intervention humaine. Cela a protégé les coffres qui n'étaient pas encore compromis.

Ce qui a suivi n'était plus automatique, mais humain et coordonné. Les validateurs se sont organisés via leurs canaux de communication, ont confirmé le vecteur d'attaque et, en quelques heures, sont parvenus à un consensus pour effectuer un halt coordonné : geler complètement l'état du réseau. Un halt est exactement ce qu'il semble être — éteindre la machine de consensus pour qu'elle ne traite plus rien, pas même un seul swap. Le gel a duré 12 heures et 42 minutes (des blocs 26190429 à 26191149), le temps nécessaire aux développeurs pour compiler, tester et déployer un correctif d'urgence, thornode v3.18.1, qui colmatait la fuite.

Comment l'argent a-t-il été récupéré sans émettre de nouveau RUNE ?

Ici, THORChain a fait quelque chose de remarquable : il a comblé un trou de 10,8 millions sans imprimer de tokens. La tentation habituelle après un hack est d'émettre de nouveaux actifs natifs pour boucher le trou, ce qui dilue tous les détenteurs et fait souvent chuter le prix en spirale. THORChain l'a expressément interdit dans son plan de récupération, la proposition de gouvernance ADR-028.

Le plan a réparti l'impact dans cet ordre :

• D'abord, la POL. La POL (liquidité détenue par le protocole, protocol-owned liquidity) est le capital que le protocole lui-même possède dans ses pools, contrairement à celui apporté par les utilisateurs. Elle fonctionne comme le matelas de réserve de la maison. Ces réserves ont absorbé la première vague de pertes, s'épuisant en priorité pour ne toucher personne d'autre.
• Ensuite, les détenteurs de synthétiques. Le déficit résiduel non couvert par la POL a été distribué entre les synth holders (détenteurs d'actifs synthétiques du protocole), et non parmi les fournisseurs de liquidité traditionnels.
• Reconstitution sans dilution. Pour renflouer la POL au fil du temps, le protocole redirige une fraction des revenus futurs des swaps vers la reconstruction de ces réserves. Aucun nouveau RUNE n'est émis ni vendu à aucun moment.
• Sanction de l'attaquant. Le protocole a confisqué (slashed) l'intégralité de la caution en RUNE que le validateur malveillant avait déposée pour opérer, tout en protégeant les validateurs honnêtes qui partageaient le coffre et n'y étaient pour rien.

Pour les utilisateurs particuliers directement touchés, un portail de récupération doté de 10 millions de dollars de la trésorerie a été mis en place avec un délai de 21 jours — jusqu'au 4 juin 2026 — pour révoquer les approbations malveillantes et réclamer une compensation. Le résultat final a été zéro perte pour les utilisateurs finaux : ceux qui avaient des fonds sur THORChain les ont récupérés.

S'agit-il d'une décentralisation réelle ou d'un point d'arrêt centralisé ?

C'est la question éditoriale la plus intéressante, et elle n'a pas de réponse simple. THORChain s'est vendu pendant des années comme une infrastructure neutre et inarrêtable, qui ne censure pas les transactions et ne peut être éteinte par personne. Le 15 mai, un groupe coordonné d'opérateurs l'a éteinte intégralement en quelques heures.

Deux lectures sont légitimes et opposées :

La lecture optimiste : un système décentralisé capable de s'arrêter lui-même en cas d'urgence, sans PDG ni comité central pour en donner l'ordre, et de résoudre les dommages en interne sans léser ses utilisateurs, est plus robuste, pas moins. L'arrêt initial était automatique ; le gel, le fruit d'un consensus entre opérateurs indépendants — une autorégulation décentralisée en action, exactement ce que le secteur doit démontrer face aux pressions réglementaires croissantes aux États-Unis pour soumettre la DeFi à une surveillance.

La lecture critique : si un quorum de validateurs peut geler le réseau, réécrire qui assume les pertes et ouvrir un portail de compensation, alors ce quorum est un point de contrôle. Aujourd'hui, ils l'ont utilisé pour une bonne cause ; cette même capacité peut servir à censurer une transaction gênante ou à céder à une injonction judiciaire. Le protocole est « inarrêtable » jusqu'à ce que ses opérateurs en décident autrement.

La vérité pratique est que presque toute la DeFi d'importance possède ce bouton quelque part, même si son marketing prétend le contraire. Le mérite de THORChain est de l'avoir utilisé avec transparence et en faveur de l'utilisateur. Le risque de fond est que le bouton existe, et celui qui le contrôle importe autant que le code audité.

Pourquoi THORChain est-il une cible si récurrente ?

L'exploit ne survient pas dans un vide. THORChain traîne une réputation pesante : par sa philosophie de neutralité et sa résistance à la censure, sa liquidité a servi de blanchisserie à des groupes liés à la Corée du Nord. Il est confirmé qu'il a déplacé une partie des 1,5 milliard de dollars volés à BlackRock en 2025, attribués au groupe Lazarus — le contexte que nous développons dans notre analyse sur la passivité de THORChain face aux fonds illicites : complicité ou code neutre ?.

Et l'incident s'inscrit dans une série brutale. Rien qu'en avril 2026, les pertes par exploits dans le secteur ont dépassé les 600 millions de dollars, avec des cas comme KelpDAO (292 millions) et Drift (285 millions). La constante de 2026 est celle que nous documentons : le maillon faible est rarement la logique du contrat audité ; c'est la couche de gouvernance, les clés et, comme ici, la cryptographie de l'infrastructure cross-chain elle-même.

Que peut surveiller le lecteur en direct après ce cas ?

Un exploit de cette nature est une donnée figée : il a eu lieu, a été corrigé, a été raconté. Ce qui change jour après jour, c'est le risque qui persiste autour de la liquidité cross-chain. Voici trois vérifications avec des données en temps réel, plutôt que de vous fier à une capture d'écran datant de plusieurs semaines :

• Le peg des wrappers Bitcoin. THORChain déplace du BTC natif entre chaînes, mais une bonne partie du BTC circulant dans la DeFi est du BTC enveloppé. Vérifiez en direct si les principaux wrappers Bitcoin maintiennent leur parité 1:1 ou s'ils s'en écartent sur notre moniteur de wrappers BTC.
• Le risque comparé des bridges. Le vecteur de ce hack est, au fond, le risque inhérent à toute infrastructure cross-chain. Avant de déplacer des fonds entre chaînes, comparez les modèles de sécurité et l'historique des bridges sur notre comparateur de bridges.
• La santé des stablecoins et des wrappers ETH qui utilisent ces mêmes bridges, sur le moniteur de stablecoins et le moniteur de wrappers ETH.

Quelles leçons tirer de ce cas ?

L'exploit des coffres Asgard laisse trois conclusions. La technique : la cryptographie de seuil n'est aussi forte que son implémentation la plus faible — un fork qui supprime une seule preuve de solidité transforme un garde-fou mathématique en porte ouverte pendant des années, et auditer les contrats ne suffit pas si personne n'audite la bibliothèque de signature avec la même rigueur. L'opérationnelle : la vitesse de réponse a compté plus que la prévention ; THORChain n'a pas évité le vol, mais l'a contenu en quelques minutes et l'a résolu avec zéro perte pour l'utilisateur, sans diluer son token. Et la plus inconfortable : le même pouvoir qui a sauvé les utilisateurs le 15 mai est un point de contrôle qui contredit le récit de l'« inarrêtable ». RUNE a chuté de 12 % à 15 % dans les 24 heures suivantes, non pas à cause de l'argent perdu — il était récupérable — mais à cause de cette contradiction. La prochaine fois qu'un protocole cross-chain vous dira que personne ne peut l'éteindre, la bonne question n'est pas de savoir si c'est vrai. C'est : et s'ils le pouvaient, voudriez-vous qu'ils ne le puissent pas ?

Sources et liens : THORChain · Documentation de THORChain (ADR-028) · Rekt.news (couverture des exploits) · tss-lib (Binance) · Etherscan (suivi on-chain) · THORChain Network (dashboard)