Cosmos EVM, faille critique sans CVE : six blockchains touchées, le correctif silencieux n’a pas empêché l’exploit

Le 28 août 2026, Cosmos Labs a publié un avis GitHub et un post-mortem concernant une vulnérabilité critique dans le module partagé Cosmos EVM, l’environnement d’exécution de contrats intelligents compatibles Ethereum au sein de l’écosystème Cosmos SDK. La faille, identifiée comme GHSA-7g4w-cg88-2cq2, a été classée critique par l’éditeur, mais n’a reçu ni identifiant CVE, ni classification CWE, ni score CVSS. Les versions affectées sont toutes celles antérieures à 0.6.2 et celles comprises entre 0.7.0 et 0.7.1. Les correctifs ont été publiés le 19 août dans les versions v0.6.2 et v0.7.2, mais la mise à jour est incompatible avec l’état (state-breaking) et nécessite une mise à niveau coordonnée du réseau. Entre le 20 et le 25 août, la faille a été activement exploitée contre six blockchains, avec des pertes économiques estimées en millions de dollars.

Comment fonctionne l’attaque : underflow, comptes de vesting et soldes « gonflés »

La vulnérabilité trouve son origine dans le code qui réconcilie l’état de l’EVM avec le module x/bank du Cosmos SDK. Le StateDB de l’EVM ne suit que le solde disponible d’un compte. Dans les comptes de vesting, en revanche, l’état SDK contient à la fois un solde disponible et un solde bloqué, qui peut être délégué via le module x/staking et la précompilation de staking.

Lorsqu’un compte de vesting délègue plus que son solde disponible, l’écriture suivante soustrait le montant total délégué d’un solde inférieur : la soustraction n’est pas contrôlée et la valeur passe en underflow, s’enroulant jusqu’à environ 2^256. La réconciliation ultérieure frappe (mint) sur un delta positif et brûle (burn) sur un delta négatif. Un attaquant peut donc déplacer un montant fini depuis un compte au solde « enroulé » et envoyer à une victime une quantité égale à 2^256 moins son solde, provoquant ainsi, lors de la réconciliation, la destruction des disponibilités réelles de la victime.

Sur les chaînes exécutant la branche 0.6.x, le mint ou le burn s’effectue sur le ledger SDK sous-jacent : un mint élevé provoque un dépassement de l’offre qui arrête la chaîne. Sur les branches 0.7.x, les soldes sont définis directement dans x/bank et acceptent des modifications qui survivent à la conversion de uint256 vers int256. Dans les deux cas, l’opération entière est exécutée en une seule transaction avec une variation nette de l’offre égale à zéro, à partir d’un contrat déployé sur une adresse précalculée qui avait été transformée au préalable en compte de vesting. L’exploitation nécessite que la chaîne autorise la création sans permission de comptes de vesting.

Chronologie : signalement en avril, confirmation en août, correctif silencieux

La faille a été signalée le 25 avril via le programme de bug bounty de Cosmos Labs. Dans un premier temps, l’équipe l’a évaluée comme sans risque pour les fonds sur les réseaux en production : elle ne parvenait pas à la reproduire sur des réseaux à 18 décimales et a conclu à tort qu’elle ne concernait que les réseaux avec des décimales différentes. Ce n’est que le 13 août qu’est arrivée la confirmation que toutes les chaînes Cosmos EVM étaient affectées, indépendamment de la configuration des décimales.

La correction principale – une protection contre l’underflow dans le write-back SubBalance du StateDB – avait déjà été introduite sur la branche principale avec la PR #1176, fusionnée le 15 mai. Les backports ont eu lieu beaucoup plus tard : PR #1253 pour la branche v0.6.x et PR #1254 pour v0.7.x, qui ont conduit aux versions v0.6.2 et v0.7.2 du 19 août.

Le correctif est passé par le processus de correctif silencieux, réservé par Cosmos Labs aux problèmes qui ne causent pas de perte de fonds en production. La politique prévoit des mesures d’atténuation d’urgence ou une distribution privée pour les risques immédiats, mais dans ce cas l’équipe a jugé sûr de procéder en silence car le correctif était déjà public sur la branche principale et aucun exploit connu n’était recensé.

L’évaluation s’est révélée erronée. Le 20 août à 07 h 16 UTC, soit huit heures et quinze minutes après la publication des versions, une PR publique dans le fork de Push Chain a décrit en détail la vulnérabilité et le chemin d’exploitation. Onze heures et cinquante minutes plus tard, à 19 h 06 UTC, la première attaque contre MANTRA a commencé. La première notification privée de Cosmos Labs par e-mail sécurisé n’est partie que le 21 août à 03 h 36 UTC, environ deux heures après que MANTRA eut signalé l’exploitation.

Impact : six chaînes, des millions de dollars vendus sur les échanges

Cosmos Labs a connaissance de six blockchains où l’exploit a été utilisé activement. MANTRA est la seule nommée explicitement comme première victime. Les attaquants ont vendu environ 2,87 millions de dollars d’actifs affectés sur des échanges décentralisés, montant basé sur les prix du 19 août et fourni par les chaînes elles-mêmes, non vérifié de manière indépendante. 2,85 millions de dollars supplémentaires ont été vendus sur des échanges centralisés, estimation fondée sur des données de volume publiques.

L’écosystème Cosmos comprend plus de 115 blockchains publiques connues, mais Cosmos Labs ne dispose pas d’un registre complet des réseaux exécutant son logiciel. Cette lacune avait déjà contraint en juillet les fournisseurs en aval à corriger des défauts de systèmes de fichiers inclus. Pendant l’incident, l’équipe a découvert onze implémentations Cosmos EVM jamais enregistrées auprès de ses canaux de sécurité.

Ce que doivent faire les opérateurs : correctif, contournement et vérifications

L’avis officiel recommande de mettre à niveau vers v0.6.2 ou v0.7.2 ou version ultérieure, en appliquant la modification comme une mise à niveau réseau coordonnée car elle est incompatible avec l’état. Si la mise à niveau immédiate est impossible, il est recommandé d’arrêter la chaîne plutôt que de tenter une mise à niveau de gouvernance coordonnée. Il n’existe pas de mesure d’atténuation purement configurationnelle : désactiver la précompilation de staking supprime le principal chemin d’activation, mais ne remplace pas le correctif.

The Hacker News a énuméré des étapes opérationnelles supplémentaires pour les développeurs. La première consiste à fermer la condition préalable : refuser dans l’ante handler les messages MsgCreateVestingAccount, MsgCreatePermanentLockedAccount et MsgCreatePeriodicVestingAccount, sans toucher aux comptes de vesting définis dans la genèse. La deuxième consiste à vérifier le chemin de code en production sur un fork : un cherry-pick qui ne corrige que l’helper exporté peut laisser une copie non exportée dupliquée, tandis que tous les tests continuent de passer. La troisième consiste à appliquer les deux corrections que l’avis omet : l’instantané du solde bloqué (PR #1187, fusionnée le 20 mai) et la protection pour les comptes de module (commit 3524ebc). Cette protection rejette inconditionnellement les comptes de module, ce qui interrompt les appels EVM effectués depuis un compte de module. Enfin, chaque équipe devrait enregistrer un contact de sécurité auprès de Cosmos Labs.

ZetaChain a appliqué les trois corrections le 21 août, en constatant que le cherry-pick laissait le chemin de production du fork non corrigé parce que le fork contenait des helpers non exportés dupliqués. Warden Protocol, deux jours plus tard, a bloqué complètement la création de comptes de vesting : sur Warden, les comptes de vesting sont la seule source de soldes bloqués et aucune fonctionnalité ne dépend de leur création ; supprimer ce chemin ferme donc la condition préalable sans dépendre de l’exactitude de la reconstruction.

Correctif silencieux et précédents : 37 vulnérabilités sans description publique

L’avis documente un seul changement en amont : la protection contre l’underflow de la PR #1176. Mais dans le même dépôt, deux autres corrections de solde ne sont pas mentionnées : la PR #1187, qui photographie le solde bloqué d’un compte pour reconstruire correctement le solde bancaire après une modification issue d’une précompilation, et le commit 3524ebc, intitulé « Merge commit from fork », qui refuse toute tentative de définir le solde d’un compte de module. Les backports de la PR #1187 ont été ouverts et fusionnés en moins de vingt-quatre heures sur les deux branches de release, tandis que le backport de la PR #1176 a suivi environ quatre-vingt-dix jours plus tard.

Les notes de version de v0.6.2 et v0.7.2 affirment contenir des corrections de sécurité importantes, mais omettent le backport de sécurité des changelogs. The Hacker News a confirmé le 29 août qu’aucune des deux versions ne liste les pull requests qui la composent.

Cosmos Labs a déclaré avoir distribué en silence des correctifs pour 37 vulnérabilités au cours des 13 derniers mois, sans que les développeurs en aval ne décrivent publiquement les chemins d’exploitation. La décision de ne pas distribuer privément le correctif après la confirmation du 13 août que toutes les chaînes étaient affectées est aujourd’hui au centre des critiques. The Hacker News a contacté Cosmos Labs pour un commentaire et attend une réponse.