Depuis le début de cette série, nous essayons de séparer les faits du bruit.

Plusieurs attaques ont été présentées comme des « hacks de Cosmos » alors qu’elles concernaient des smart contracts, des bridges ou des applications indépendantes. Ni le Cosmos Hub, ni ATOM, ni IBC n’étaient nécessairement responsables.

Cette fois, la situation est différente.

Entre le 20 et le 22 août 2026, plusieurs blockchains utilisant Cosmos EVM ont été exploitées ou contraintes d’interrompre leur réseau.

Le Hub n’a pas été hacké. ATOM n’a pas été directement touché. Mais la vulnérabilité concerne bien un composant officiel du Cosmos Stack.

Plusieurs chaînes touchées par une infrastructure commune

Cosmos EVM permet d’ajouter un environnement compatible Ethereum à une blockchain construite avec le Cosmos SDK. Il donne accès à Solidity, MetaMask et aux outils EVM tout en conservant des fonctionnalités propres à Cosmos, comme le staking et IBC.

Cette technologie est utilisée ou intégrée par plusieurs réseaux, notamment MANTRA, TAC, KiiChain, Mezo, Stable et la sidechain XRP Ledger.

Cette adoption démontre un intérêt commercial et technique réel pour le Cosmos Stack. Mais une infrastructure partagée crée aussi un risque partagé.

MANTRA a détecté une attaque le 20 août. Deux portefeuilles appartenant à son infrastructure interne ont été affectés, sans perte annoncée pour les utilisateurs. La chaîne a été interrompue pendant environ 30 heures avant de redémarrer avec un binaire corrigé. L’équipe a depuis publié un rapport complet sur son incident.

Le 22 août, KiiChain a subi 18 exploitations successives. Selon son communiqué officiel, l’attaquant a retiré 148,3 millions de KII avant l’arrêt de la chaîne.

Ce montant nominal ne correspond pas nécessairement à la valeur réellement vendue ou définitivement perdue. Une partie des tokens serait restée bloquée sur le réseau. L’incident demeure néanmoins important par son ampleur et sa répétition.

TAC a également interrompu son réseau après qu’un attaquant a exploité la couche de precompiles Cosmos EVM pour vider un compte. L’équipe précise dans son rapport que la vulnérabilité se trouvait dans le module partagé et non dans du code spécifique à TAC.

Nesa a, de son côté, signalé une activité malveillante liée à Cosmos EVM.

Les détails techniques semblent varier selon les chaînes. Il faut donc éviter d’affirmer que toutes ces attaques reposaient exactement sur la même combinaison de défauts avant la publication du rapport global de Cosmos Labs.

Des correctifs publiés avant les attaques

La chronologie publique soulève néanmoins plusieurs questions.

Les versions v0.6.2 et v0.7.2 de Cosmos EVM ont été publiées le 19 août. Le dépôt GitHub officiel indiquait qu’elles contenaient d’importants correctifs de sécurité et recommandait aux chaînes de les installer rapidement.

Ces mises à jour étaient toutefois state-breaking. Elles demandaient donc de préparer un nouveau binaire, de le tester et de coordonner son activation avec les validateurs.

MANTRA a été attaqué le 20 août. KiiChain et TAC ont annoncé leurs incidents le 22 août.

Le 24 août, Cosmos Labs a publié un avertissement général, recommandant aux chaînes encore vulnérables d’interrompre la production de blocs et d’appliquer les correctifs.

Cette chronologie publique ne permet pas de savoir quelles alertes privées avaient été transmises auparavant, à quelles chaînes, ni avec quel niveau d’urgence.

KiiChain estime que le processus de divulgation n’a pas laissé suffisamment de temps aux projets pour se mettre en sécurité. Selon son équipe, la publication d’un correctif dans un dépôt public aurait également pu permettre à des attaquants d’étudier les modifications pour retrouver la vulnérabilité.

Il s’agit, à ce stade, de la position de KiiChain. Cosmos Labs a annoncé qu’un rapport complet serait publié une fois l’incident entièrement maîtrisé.

Ce rapport devra notamment clarifier :

• quand la vulnérabilité a été découverte ;
• quelles chaînes ont été contactées avant la publication ;
• quel niveau de risque leur a été communiqué ;
• et pourquoi plusieurs réseaux n’avaient pas encore appliqué les correctifs lors des attaques.

En tant qu’opérateur, nous savons qu’une mise à jour state-breaking ne s’installe pas instantanément. Elle doit être intégrée, testée et coordonnée avec l’ensemble des validateurs.

C’est précisément pourquoi la qualité et le calendrier des alertes sont aussi importants que le correctif lui-même.

Déjà adopté, mais pas encore stable

Un autre élément mérite d’être rappelé.

Cosmos EVM est toujours publié en versions v0.x. Son dépôt officiel précise que le code est encore audité et testé, que des changements incompatibles peuvent intervenir et que Cosmos Labs ne le considérera stable qu’à partir d’une future version v1.

Cela ne signifie pas que les projets ne devraient pas l’utiliser. De nombreuses technologies sont déployées avant leur première version stable.

Mais cela nuance les annonces d’adoption.

La présence de projets importants parmi les utilisateurs de Cosmos EVM démontre une demande réelle. Elle ne démontre pas encore que le framework a atteint sa maturité définitive.

Or Cosmos Labs positionne notamment sa technologie auprès de projets financiers et institutionnels. Pour ces clients, les performances ne suffisent pas : la stabilité, les audits, la communication et les procédures d’urgence font également partie du produit.

Le Hub n’a pas été hacké

Il faut éviter l’excès inverse.

Le Cosmos Hub n’utilise actuellement pas Cosmos EVM. La chaîne cosmoshub-4, les balances ATOM et le consensus du Hub n’ont pas été compromis. IBC n’est pas présenté comme la cause initiale des attaques.

Dire que « le Cosmos Hub a été hacké » serait donc faux.

Mais prétendre que cet incident ne concerne pas Cosmos parce qu’il s’est produit sur d’autres chaînes serait tout aussi imprécis.

Cosmos EVM est maintenu par Cosmos Labs et présenté comme un produit stratégique du Cosmos Stack.

La distinction est importante : le Hub n’est pas responsable de l’incident, mais l’incident concerne bien une technologie officielle de Cosmos.

Une conséquence directe pour le futur du Hub

Cosmos Labs étudie toujours la possibilité de placer une EVM dans l’orbite du Hub, soit directement sur la chaîne, soit au moyen d’une sidechain utilisant ATOM.

Une EVM native pourrait mieux relier les applications, la liquidité et ATOM. Elle augmenterait aussi la complexité et la surface d’attaque du Hub.

Une sidechain isolerait davantage les risques techniques, mais maintiendrait une partie de la fragmentation actuelle.

L’incident d’août ne tranche pas ce débat. Il ajoute cependant une condition incontournable : toute intégration devra reposer sur une version suffisamment stable, auditée et accompagnée de procédures de sécurité adaptées à l’importance du Hub.

Il ne s’agit donc pas de rejeter Cosmos EVM, mais de s’assurer que le calendrier technique ne soit pas dicté par les seules attentes commerciales.

Cette fois, le FUD ne suffit pas comme explication

Depuis plusieurs mois, Cosmos souffre d’un mélange permanent entre problèmes réels et conclusions exagérées.

Certains utilisent chaque fermeture, chaque départ ou chaque hack pour annoncer la mort de tout l’écosystème. D’autres répondent presque automatiquement que le Hub fonctionne toujours et que les critiques ne sont que du FUD.

L’incident Cosmos EVM ne rentre confortablement dans aucun de ces deux récits.

Il ne prouve pas que le Cosmos Hub est mort. Mais cette fois, la vulnérabilité concerne bien un produit maintenu et promu par Cosmos Labs. Plusieurs chaînes ont été exploitées et la coordination des correctifs fait désormais l’objet de questions légitimes.

Répondre simplement que « ce n’est pas le Hub » ne suffit donc pas.

Le principal dommage pourrait même dépasser les pertes directement observées. Cosmos Labs construit actuellement sa nouvelle stratégie autour de la confiance : celle des institutions dans le Cosmos Stack, celle des projets dans Cosmos EVM et celle des détenteurs d’ATOM dans sa capacité à transformer cette adoption en activité pour le Hub.

Cette crédibilité est désormais mise à l’épreuve.

ATOM n’est pas techniquement responsable de la faille. Mais son avenir dépend en partie d’une feuille de route portée par Cosmos Labs. Un incident touchant l’un de ses produits stratégiques affecte donc inévitablement la perception de cette feuille de route.

Le marché ne distingue pas toujours aussi précisément le Cosmos Stack, Cosmos Labs, le Hub et ATOM que nous essayons de le faire dans cette série. Une crise touchant l’un peut rapidement contaminer la perception des autres.

Ce n’est pas nécessairement juste. Mais économiquement, c’est une réalité.

Depuis le début de cette série, nous avons corrigé les accusations lorsque Cosmos était injustement mis en cause. Nous devons appliquer la même exigence lorsqu’une vulnérabilité concerne réellement son code.

Cosmos Labs devra maintenant fournir une chronologie complète, expliquer son processus de divulgation et démontrer que ses chaînes clientes peuvent continuer à lui confier une partie critique de leur infrastructure.

Ce rapport sera aussi un test de la communication plus transparente promise ces derniers mois.

Être indépendant ne signifie pas être systématiquement contre. Cela signifie pouvoir reconnaître les réussites, signaler les failles et attendre les faits avant de distribuer les responsabilités.

Dans notre neuvième et dernier article, nous reviendrons à la question centrale : le Hub est-il réellement en train de renaître, ou sa nouvelle valeur repose-t-elle encore trop largement sur une confiance qui reste à reconstruire ?