Quand une faille circule pendant des mois dans un logiciel partagé par tout un écosystème, le risque n’est plus local. Il devient systémique. Entre le 20 et le 25 août 2026, six blockchains de la famille Cosmos ont vu des soldes se vider sans création de jetons, sans manipulation de prix, sans exploit de marché. Seulement une incohérence de comptabilité entre Cosmos EVM et le module qui tient les balances dans le SDK. Le préjudice converti tourne autour de 5,7 millions de dollars. Le plus troublant n’est pas seulement le montant. C’est que la vulnérabilité avait été signalée dès le 25 avril au programme de récompense, que les équipes n’avaient pas réussi à la reproduire sur les configurations de production, et que le correctif public est arrivé une vingtaine d’heures avant la première attaque connue.
Ce Que Révèle Vraiment L’Offensive Sur Cosmos EVM
La même semaine, Cronos a dû interrompre son réseau après une affaire Tectonic liée au prix du TONIC. Deux arrêts, deux logiques. Ici, personne n’a tordu un oracle. Personne n’a gonflé artificiellement un collatéral pour vider un pool isolé. Les attaquants ont combiné deux erreurs dans une seule transaction afin de provoquer un underflow, un sous-flux numérique. Quand un solde passe sous zéro, la valeur rebondit au maximum autorisé par le système. Cette somme fictive sert ensuite à transférer de vrais jetons depuis une autre adresse, souvent une adresse de destruction ou un ancien coffre multisignature.
Le résultat est presque clinique. Aucun actif n’est « créé » au terme de l’opération. Des jetons déjà existants changent simplement de propriétaire. C’est précisément ce qui rend la faille difficile à détecter au premier regard et facile à sous-estimer quand on la teste sur un environnement trop propre.
Les fonds n’étaient pas considérés comme menacés. Les versions corrigées sont pourtant sorties vingt heures avant la première attaque connue.
Synthèse des communications de Cosmos Labs
Une incohérence entre deux couches logicielles
Cosmos promet depuis des années une architecture modulaire. Le SDK gère l’état, le consensus, les modules métier. Cosmos EVM ajoute une couche d’exécution compatible avec Ethereum, afin que les développeurs puissent déployer des contrats familiers sans quitter l’univers interchaînes. Cette promesse attire des projets, des liquidités et des équipes qui veulent l’interopérabilité sans tout réécrire. Elle crée aussi une surface de contact. Deux modèles de soldes doivent rester parfaitement alignés. S’ils divergent d’un octet, d’un signe, d’une vérification d’overflow, la comptabilité globale ment.
Dans le cas présent, le module chargé de comptabiliser les balances et la machine EVM ne traitaient pas le même scénario de la même façon. En enchaînant deux opérations défaillantes dans la même transaction, l’attaquant forçait un passage sous zéro. Le système, au lieu de refuser l’opération, renvoyait une valeur maximale. Cette valeur n’existait pas réellement dans l’offre. Elle existait dans le registre temporaire de la transaction. Elle suffisait pourtant à autoriser un transfert depuis une adresse qui, elle, détenait de vrais jetons.
Les adresses visées n’étaient pas choisies au hasard. Une adresse de destruction concentre souvent des quantités considérables destinées à ne plus jamais circuler. Un ancien portefeuille multisignature peut rester chargé longtemps après qu’une gouvernance a changé de schéma. Ces réservoirs sont publics, lisibles, parfois oubliés. Ils deviennent des cibles parfaites dès que la règle « on ne peut pas débiter plus que le solde » cesse d’être vraie pendant une fraction de seconde.
Ce que l’exploit faisait, concrètement.
- Combiner deux erreurs dans une transaction unique.
- Faire chuter un solde sous zéro pour déclencher un sous-flux.
- Obtenir une valeur fictive proche du maximum système.
- S’en servir pour vider une adresse réelle, souvent un burn ou un vieux multisig.
- Convertir ensuite les jetons sur des plateformes décentralisées et centralisées.
Le signalement d’avril et le diagnostic trop rassurant
Le 25 avril, la faille entre dans le circuit officiel du bug bounty Cosmos. C’est le scénario que tout écosystème mature revendique : un chercheur trouve, une équipe trie, un correctif suit. Ici, le fil se casse au milieu. Les équipes ne parviennent pas à reproduire l’attaque sur les configurations utilisées en production. Elles concluent que les fonds ne sont pas menacés. Un correctif est tout de même intégré, mais sans alerte critique destinée aux opérateurs de chaînes.
Cette phrase mérite d’être lue lentement. Un correctif discret n’est pas un aveu d’innocuité. C’est souvent le signe qu’on a vu assez de fumée pour changer le code, mais pas assez de flamme pour réveiller les validateurs. Or les réseaux Cosmos EVM ne sont pas un laboratoire unique. Ce sont des déploiements hétérogènes, avec des versions, des modules optionnels, des historiques d’adresses et des politiques de mise à jour très différentes. Ce qui ne se reproduit pas sur une image « propre » peut exploser sur une chaîne qui traîne un burn wallet chargé et un vieux coffre.
Début août, de nouvelles analyses inversent le diagnostic. L’ensemble des réseaux Cosmos EVM apparaît potentiellement vulnérable. Les versions corrigées 0.6.2 et 0.7.2 sortent le 19 août. La première attaque connue survient environ vingt heures plus tard. L’écart est mince. Trop mince pour une coordination interchaînes. Assez large, en revanche, pour qu’un acteur qui surveille les dépôts de code, les notes de version ou les discussions internes comprenne qu’une fenêtre vient de s’ouvrir.
Six chaînes, un même logiciel, des destinées différentes
MANTRA est la première victime identifiée. Environ 720,9 millions de jetons, alors valorisés autour de 3,6 millions de dollars, quittent une adresse de destruction et un ancien portefeuille multisignature. Le réseau s’arrête près de quatre heures après la première transaction. Il redémarre ensuite sans réécrire l’historique. Ce choix n’est pas anodin. Annuler des blocs, c’est trancher entre la finalité et la justice comptable. Relancer sans rollback, c’est accepter que les jetons déplacés restent déplacés, tout en fermant la porte aux copies de l’exploit.
TAC et KiiChain subissent des attaques du même type. Cosmos Labs évoque six réseaux au total. Deux restent non nommés. Nesa est parfois citée, sans confirmation officielle. Sur le plan financier, les équipes parlent d’environ 2,87 millions de dollars convertis via des plateformes décentralisées et 2,85 millions via des plateformes centralisées. Les comptes utilisés sur ces dernières auraient depuis été gelés. Le gel ne répare pas la faille. Il limite la sortie.
KiiChain formule le grief le plus net. Selon cette équipe, le développeur n’aurait recommandé l’arrêt des réseaux qu’après plusieurs attaques, alors qu’une suspension coordonnée peut être plus rapide qu’un patch déployé partout en même temps. L’argument est rude, mais il touche un point réel de l’exploitation interchaînes. Quand le code est partagé, le temps de réaction n’est plus celui d’une startup isolée. C’est celui du maillon le plus lent.
Cosmos Labs reconnaît des erreurs d’évaluation et promet de revoir ses procédures de traitement et de divulgation des vulnérabilités critiques.
Position publique des équipes après les attaques
Pourquoi cette affaire n’est pas « un hack DeFi de plus »
L’industrie a pris l’habitude de classer les incidents par protocole. Un pool mal conçu. Un pont trop confiant. Un oracle manipulable. Ici, la cible n’est pas une application isolée. C’est une brique commune. Dès qu’un composant vit dans plusieurs chaînes, une erreur locale devient un risque d’écosystème. Les validateurs, les fondations, les market makers et les utilisateurs finaux découvrent d’un seul coup qu’ils partagent le même point unique de défaillance, même s’ils croyaient habiter des univers séparés.
Cette distinction explique aussi la comparaison avec Cronos. L’arrêt de Cronos après Tectonic raconte une crise de marché et de protocole. L’offensive Cosmos EVM raconte une crise de couche d’exécution. On peut fermer un marché monétaire. On ne « ferme » pas aussi facilement une machine virtuelle déployée sur six réseaux, chacun avec sa gouvernance, ses délais de vote et ses contraintes de communication.
Il faut aussi regarder le type d’actifs extraits. Vider un burn wallet ou un vieux multisig ne ressemble pas à un vol de trésorerie d’application. Cela ressemble à une réouverture de comptes que tout le monde croyait clos. Pour les communautés, le choc est double. Financièrement, des jetons reviennent en circulation ou changent de mains. Symboliquement, l’idée même de destruction ou d’adresse abandonnée perd de sa solennité. Si un solde « mort » peut ressusciter par un underflow, la comptabilité on-chain n’est plus un registre sacré. Elle redevient un logiciel, avec ses coins et ses bords.
Le calendrier serré du mois d’août
Le récit tient en quelques dates. Avril : signalement. Été : conviction que la production n’est pas exposée. Début août : réévaluation. 19 août : publications 0.6.2 et 0.7.2. 20-25 août : vague d’attaques. 31 août : bilan public, polémique sur la divulgation, comparaison immédiate avec l’affaire Cronos. Quatre mois séparent l’alerte initiale de l’exploitation massive. Vingt heures séparent le correctif visible de la première frappe. Ces deux durées ne racontent pas la même histoire. La première parle d’évaluation. La seconde parle de course.
Dans une course, le patch public est une information. Même rédigé avec prudence, il indique qu’un chemin critique vient d’être refermé quelque part. Les attaquants n’ont pas besoin du détail académique. Ils ont besoin de savoir où chercher, quelle version comparer, quel module relire. Les chercheurs en sécurité le répètent depuis des années : la fenêtre entre divulgation et déploiement est le moment le plus dangereux. Cosmos vient d’en livrer une illustration interchaînes.
Les chiffres qui cadrent l’incident.
- Signalement au bounty : 25 avril.
- Correctifs 0.6.2 et 0.7.2 : 19 août.
- Première attaque connue : environ vingt heures plus tard.
- Fenêtre d’exploitation observée : 20-25 août.
- MANTRA : 720,9 millions de jetons, environ 3,6 millions de dollars.
- Conversions estimées : 2,87 M$ en DeFi, 2,85 M$ en CEX.
- Total converti évoqué : environ 5,7 millions de dollars.
- Réseaux touchés : six, dont deux non nommés.
La polémique de la divulgation responsable
On aime les récits binaires. Soit l’équipe a caché. Soit le chercheur a trop parlé. La réalité des grandes bases de code partagées est plus grise. Reproduire un exploit dépend de l’état initial, des modules activés, des versions précises, parfois d’une adresse oubliée. Un laboratoire qui teste « comme en production » sans le désordre réel de la production peut sincèrement conclure à l’absence de danger. Cette sincérité n’absout pas la procédure. Elle en montre la fragilité.
Une alerte critique destinée aux opérateurs n’est pas une conférence de presse. C’est un canal étroit, chiffré, adressé aux équipes qui peuvent arrêter un réseau, geler un module, accélérer une mise à jour. Cosmos Labs admet aujourd’hui des erreurs d’évaluation. KiiChain estime que la recommandation d’arrêt est arrivée trop tard. Les deux phrases peuvent être vraies en même temps. L’une décrit le diagnostic. L’autre décrit le temps opérationnel.
La promesse de « revoir les procédures de traitement et de divulgation des vulnérabilités critiques » sonne familière. Chaque grand incident de l’industrie s’achève sur une phrase voisine. Ce qui comptera, dans six mois, n’est pas le communiqué. C’est la liste concrète : tests d’underflow systématiques entre EVM et modules SDK, inventaire des burn wallets et des multisigs dormants, seuils automatiques d’arrêt, devoir d’alerte dès qu’un correctif discret est fusionné, exercices de coordination entre chaînes sœurs.
Ce que l’architecture Cosmos rend plus difficile, et plus précieux
L’écosystème Cosmos s’est construit contre l’idée d’une chaîne unique et omnipotente. Chaque zone garde sa souveraineté. L’IBC relie. Le SDK factorise. Les stacks EVM permettent d’attirer des développeurs déjà formés à Solidity. Cette généalogie produit une force : on n’arrête pas tout l’univers d’un coup. Elle produit aussi une faiblesse : on n’alerte pas tout l’univers d’un coup. Une faille dans une brique partagée voyage plus vite que les procédures humaines qui devraient la contenir.
Les opérateurs le savent, en théorie. En pratique, les priorités quotidiennes restent le throughput, la compatibilité des wallets, le listing des assets, la communication marketing. La sécurité des couches basses passe après, jusqu’au jour où un sous-flux transforme une adresse morte en source de liquidités. Ce jour est arrivé pour au moins six réseaux. Il arrivera ailleurs si la leçon se limite à « patchez Cosmos EVM ».
Car le vrai sujet dépasse ATOM, MANTRA ou KiiChain. Toute stack qui juxtapose une machine virtuelle empruntée et un modèle de comptes natif crée une frontière. Les bridges l’ont appris à leurs dépens. Les rollups aussi. Les zones Cosmos EVM viennent d’ajouter leur chapitre. La frontière n’est pas un détail d’implémentation. C’est l’endroit où les invariants se rencontrent, et parfois se trahissent.
Arrêter un réseau ou garder la finalité
MANTRA s’est arrêtée près de quatre heures après la première transaction, puis a repris sans rollback. D’autres chaînes ont leurs propres calendriers, moins documentés publiquement. Derrière ces choix se joue une philosophie. Une blockchain qui réécrit son passé pour annuler un vol dit que la gouvernance vaut plus que l’immuabilité. Une blockchain qui refuse le rollback dit que la finalité vaut plus que la réparation. Aucune des deux positions n’est gratuite.
Le rollback console les victimes identifiables. Il trouble les contreparties honnêtes qui ont déjà reçu, échangé, fourni de la liquidité. Il ouvre aussi un précédent : dès qu’un exploit est assez grand, on négocie l’histoire. L’absence de rollback protège le récit de neutralité. Elle laisse les fonds chez celui qui a couru le plus vite. Dans le cas Cosmos EVM, une partie des sorties vers des plateformes centralisées a été gelée. C’est une réparation partielle, hors chaîne, qui dépend de la coopération d’acteurs que l’écosystème décentralisé prétend souvent pouvoir ignorer.
Cette ironie n’est pas nouvelle. Elle devient plus visible quand l’attaque ne vise pas un protocole DeFi isolé mais le moteur commun. Les fondations se retrouvent à demander des gels, à publier des listes d’adresses, à justifier des halts, tout en expliquant que l’interchaîne reste souveraine. La souveraineté, ici, a un coût de coordination.
Les burn wallets, ces coffres que l’on croit éteints
Une adresse de destruction est un geste politique autant que technique. On y envoie des jetons pour signaler une raréfaction, une fin de programme, une promesse de non-circulation. Les explorateurs les affichent. Les communautés les célèbrent. Les attaquants les lisent comme un inventaire. Si la règle de débit peut être contournée, ces adresses deviennent des réserves. Le cas MANTRA le montre avec une clarté brutale : des centaines de millions de jetons quittent un lieu conçu pour n’en laisser sortir aucun.
Les anciens multisigs posent un problème voisin. Une équipe change d’outil, de seuil, de fournisseur. L’ancienne adresse reste visible, parfois alimentée, parfois simplement oubliée. En temps normal, l’oubli suffit. Personne n’a les clés, donc personne ne bouge. En temps d’exploit comptable, les clés ne sont plus nécessaires. Il suffit que le moteur accepte un transfert depuis cette adresse. La gouvernance humaine disparaît de l’équation.
Une hygiène minimale s’impose désormais à toutes les chaînes qui exposent EVM sur un SDK. Cartographier les adresses à solde élevé et sans propriétaire actif. Surveiller les interactions anormales. Envisager des garde-fous au niveau module, pas seulement au niveau contrat. Un burn qui n’est qu’une convention sociale n’est pas un burn. C’est une étiquette.
Ce que les marchés ont vu, et ce qu’ils n’ont pas vu
Cinq à six millions de dollars convertis ne font pas une panique systémique à l’échelle de Bitcoin ou d’Ethereum. Ils suffisent pourtant à casser la confiance d’un appchain, à déplacer un narratif, à forcer des halts. Sur les plateformes décentralisées, la conversion est rapide, fragmentée, parfois noyée dans le bruit des memecoins. Sur les plateformes centralisées, elle laisse une trace plus saisissable, d’où les gels mentionnés par Cosmos Labs.
Les marchés n’ont pas seulement réagi au montant. Ils ont réagi à la nature interchaînes du risque. Si six réseaux tombent sur la même brique, la question suivante s’écrit toute seule : combien d’autres stacks EVM du cosmos restent en retard de version ? Combien d’opérateurs ont lu la note du 19 août comme une mise à jour de routine ? Combien de validateurs ont attendu le prochain cycle de gouvernance pour agir ?
ATOM, en tant que jeton de l’écosystème, n’est pas le butin principal décrit dans le bilan. L’affaire n’en est pas moins un test de réputation pour la marque Cosmos. Les développeurs choisissent une stack parce qu’ils veulent de la vitesse de déploiement. Ils restent s’ils croient que la sécurité partagée est mieux tenue qu’une sécurité isolée. Un underflow qui survit quatre mois dans le circuit officiel ébranle cette croyance.
Leçons opérationnelles pour les opérateurs de zones
La première leçon est triviale et rarement appliquée : traiter un correctif discret comme un signal d’alarme, pas comme une rustine cosmétique. Si le code change pour empêcher un underflow, c’est que quelqu’un a vu un chemin vers l’underflow. La reproduction ratée en laboratoire ne clôt pas le dossier. Elle ouvre une liste de variantes à tester, y compris les plus sales : adresses nulles, burns, coffres abandonnés, transactions composées.
La deuxième leçon concerne le halt. Arrêter un réseau est politiquement coûteux. Ne pas l’arrêter pendant qu’un exploit se recopie est plus coûteux encore. KiiChain a raison de rappeler qu’une suspension peut être plus rapide qu’une mise à jour coordonnée. Encore faut-il que la recommandation arrive avant la troisième copie de l’attaque, pas après.
La troisième leçon porte sur l’inventaire. Chaque chaîne devrait tenir un registre vivant des adresses à privilège historique : factories, treasuries, burns, anciens gnosis, contrats dépréciés. Ce registre n’est pas un argument marketing. C’est une carte des cibles. Les attaquants la dressent déjà, eux, en lisant l’explorateur.
- Tester les frontières EVM-SDK avec des soldes extrêmes, pas seulement des scénarios heureux.
- Alerter les opérateurs dès qu’un patch touche la comptabilité des balances.
- Prévoir un halt d’urgence plus court que le cycle de gouvernance habituel.
- Surveiller burns et multisigs dormants comme des réserves actives.
- Documenter publiquement, après coup, les versions vulnérables et les versions saines.
Ce que les utilisateurs peuvent vérifier sans attendre une fondation
Un détenteur de jetons sur une appchain Cosmos EVM n’a pas accès à la salle de guerre. Il a accès à quelques signaux. La version du nœud annoncé par les validateurs. La date du dernier halt. La présence d’un message de gouvernance sur une mise à jour 0.6.2 ou 0.7.2. Le comportement des grands wallets connus. Une activité soudaine sur une adresse de destruction n’est jamais anodine, même si le marché est calme.
Il peut aussi séparer son exposition. Un jeton d’application n’est pas un jeton de sécurité partagée. Un pont n’est pas une zone. Une ferme DeFi n’est pas le SDK. L’attaque d’août n’a pas besoin d’un utilisateur imprudent pour réussir. Elle a besoin d’un moteur qui ment sur un solde. Réduire le temps passé sur une chaîne non patchée reste pourtant la seule variable individuelle qui vaille.
Les gels côté plateformes centralisées rappellent enfin une vérité inconfortable. Quand l’exploit réussit, la récupération passe souvent par des acteurs régulés. Ceux qui avaient déjà retiré vers l’auto-garde ou vers un mixeur de liquidités décentralisées laissent moins de prise. Ce n’est pas un conseil d’anonymat. C’est un constat de délai. La chaîne d’approvisionnement du butin décide du taux de récupération.
Une mauvaise semaine, un problème de fond
Deux arrêts de blockchain en quelques jours donnent l’impression d’une malédiction saisonnière. L’impression est trompeuse. Cronos et Cosmos EVM n’ont pas subi le même accident. L’un raconte un protocole et un prix. L’autre raconte une couche d’exécution partagée et une divulgation trop confiante. Mélanger les deux, c’est perdre le diagnostic.
Le fond, pour Cosmos, n’est pas que six chaînes aient été touchées. C’est qu’une alerte d’avril n’ait pas produit, dès le premier doute, un exercice interchaînes. Les écosystèmes modulaires aiment vanter la souveraineté. Ils devront maintenant vanter aussi la discipline collective. Sans elle, le module commun n’est plus un atout. C’est un multiplicateur de crise.
Cosmos Labs a publié un bilan, reconnu des erreurs, promis de revoir ses procédures. Les réseaux nommés ont choisi leurs réponses, halt ou pas, rollback ou pas. Les deux chaînes restées dans l’ombre entretiennent un flou qui n’aide personne. La suite se jouera moins dans les communiqués que dans les versions déployées, les tests d’underflow ajoutés aux CI, et la vitesse à laquelle une prochaine alerte critique atteindra réellement les opérateurs.
Ce qu’il faudra surveiller dans les prochaines semaines
D’abord, la liste complète des six réseaux. Tant que deux noms manquent, le périmètre réel reste une hypothèse. Ensuite, le sort des fonds gelés sur les plateformes centralisées : restitution, saisie, silence. Puis les post-mortems techniques, plus détaillés que les récits de communication. On voudra voir les transactions exactes, les opcodes en cause, les conditions de reproduction qui avaient échappé en avril.
Il faudra aussi observer les autres stacks EVM de l’interchaîne. Un correctif publié n’est pas un correctif installé. Les historiques de gouvernance sont lents. Les validateurs hésitent. Les équipes secondaires recopient parfois une version « assez proche ». Assez proche ne suffit pas quand l’écart tient à deux erreurs combinées dans une seule transaction.
Enfin, le débat de gouvernance interne. Si la leçon se limite à blâmer une équipe, elle sera oubliée. Si elle produit un protocole d’alerte contraignant entre Cosmos Labs et les opérateurs de zones EVM, elle aura servi à autre chose qu’à compter 5,7 millions de dollars. C’est à cette aune, et non à celle des communiqués du 31 août, que l’on jugera la semaine.
Contrairement à l’incident Tectonic, cette attaque ne visait pas un protocole isolé, mais une brique logicielle commune à plusieurs blockchains.
Lecture de l’écart entre crise locale et risque d’écosystème
Une comptabilité qui ne doit plus mentir
Les blockchains vendent une promesse simple : le registre dit vrai. Un underflow qui transforme un solde négatif en fortune maximale viole cette promesse sans même créer de jeton. C’est pour cela que l’affaire frappe plus fort qu’un dump de memecoin ou qu’un oracle mal réveillé. Elle touche le verbe même du système. Transférer. Débiter. Créditer. Ces verbes doivent rester ennuyeux. Dès qu’ils deviennent créatifs, l’écosystème entier paie la note.
Six chaînes viennent de l’apprendre, certaines nommément, d’autres dans le silence. Le logiciel partagé qui devait accélérer Ethereum dans le cosmos a servi de rampe. Le bounty d’avril devait fermer la porte. Il l’a laissée entrouverte assez longtemps pour qu’une course de vingt heures suffise. Reste à savoir si la prochaine faille connue sera traitée comme une hypothèse de laboratoire, ou comme ce qu’elle est dès le premier signalement : un incendie possible dans toutes les maisons qui ont copié le même plan.
