MANTRA Chain de retour en ligne alors que les développeurs réclament des explications sur des modifications de code silencieuses

MANTRA Chain a rétabli la production de blocs du mainnet en v8.4.0, six jours après qu'un incident de sécurité a forcé un arrêt de l'ensemble de la chaîne. Le compte rendu technique promis n'a pas encore été publié, laissant inexpliquée l'exploitation de la dépendance amont ainsi que l'activité observée dans deux portefeuilles gérés par le projet.

Selon la chronologie officielle de l'incident, le mainnet a repris à environ 05:30 UTC le 22 août. La chaîne a indiqué qu'aucun rollback ni changement d'état n'a eu lieu entre l'arrêt et le redémarrage, que les soldes des utilisateurs n'ont pas été modifiés et que les détenteurs de tokens n'avaient aucune action à entreprendre.

L'équipe a marqué l'incident comme résolu le 24 août, tout en indiquant à nouveau qu'un post-mortem serait publié dans les jours suivants. Au 27 août, ni la page de statut actuelle ni le canal officiel d'annonces ne contenaient de lien vers ce rapport.

MANTRA a déclaré que son analyse avait établi que l'incident avait affecté deux portefeuilles gérés par MANTRA et qu'aucun fonds d'utilisateur, de plateforme d'échange ou de partenaire n'avait été touché. Le compte rendu public n'identifie toutefois ni les adresses des portefeuilles, ni les hachages de transaction, ni les montants, ni les étapes techniques de l'exploit.

Lorsque l'arrêt a été signalé pour la première fois le 21 août, les tests du correctif étaient toujours en cours. Le retour du réseau met fin à l'interruption opérationnelle, mais la méthode de l'attaquant et l'évaluation de l'endiguement faite par MANTRA restent non divulguées.

Pour les opérateurs de nœuds, le registre de code public soulève une question pratique immédiate : quelle version v8.4.0 est actuellement en cours d'exécution. La page de publication actuelle renvoie au commit complet 5c08d7bd9e2619952707dae1258d2a30bf024721, tandis que MANTRA avertit que le tag a été republié pendant la récupération et demande aux opérateurs de le récupérer à nouveau.

Ce niveau de clarté sur les versions est important lors des récupérations post-incident, car les validateurs et les équipes d'infrastructure s'appuient généralement sur les tags de publication et les journaux de modifications pour confirmer qu'ils exécutent bien la version prévue après un redémarrage d'urgence. Ici, l'historique des publications est public, mais la justification des modifications du code n'est pas entièrement documentée.

Le journal des modifications de la publication mentionne une mise à jour intermédiaire du fork MANTRA EVM, passant de v0.6.0-v8-mantra-3 à v0.6.0-v8-mantra-4. Le fichier go.mod final taggé remplace cette dépendance par le fork v0.6.2-v8-mantra-1 de la chaîne.

Le gestionnaire de mise à niveau final place une adresse sur liste de blocage et désactive trois messages de création de comptes de vesting Cosmos via le circuit breaker. Ces changements décrivent l'atténuation déployée, tandis que le chemin d'attaque lui-même reste non divulgué.

Pourquoi la faille ICS20 de mars reste une simple hypothèse pour les utilisateurs de MANTRA

Un avis de Cosmos Labs publié en mars décrivait une faille critique du précompilateur ICS20, indiquait que les chaînes connues comme affectées avaient atténué le risque ou effectué une mise à niveau, et citait Mantra parmi les collaborateurs de la remédiation. Sa chronologie s'achève avec la divulgation de mars, laissant l'incident d'août hors de son périmètre documenté.

Cela rend le post-mortem manquant d'autant plus important pour les lecteurs qui tentent de distinguer les faits confirmés des références à d'anciennes vulnérabilités : le registre public montre un redémarrage, une version taggée et un ensemble limité d'atténuations, mais pas la chaîne d'événements ayant conduit à l'arrêt. Tant que MANTRA ne publie pas le compte rendu technique promis, les utilisateurs peuvent vérifier le redémarrage, le code final exact et l'impact annoncé, mais pas les adresses de portefeuilles, les hachages de transaction, les montants ni l'explication technique nécessaires pour relier cet incident à un bug antérieur.

Source | Couverture connexe