CVE-2026-61604 in ixo-blockchain
Résumé
par VulDB • 24/09/2026
La blockchain ixo est une blockchain de niveau 1 qui s'exécute à la fois sur Testnet et Mainnet. Avant la version 8.0.0, le module x/bonds transférait des fonds depuis une adresse résolue à partir d'une méthode de vérification DID (Decentralized Identifier), sans vérifier que l'adresse résolue appartenait au signataire de la transaction. Les gestionnaires concernés comprenaient MsgMakeOutcomePayment, MsgBuy, MsgSell, MsgSwap et MsgWithdrawShare, ainsi que le processeur d'ordres par lots. Étant donné que tout compte peut lister un blockchainAccountID arbitraire comme méthode de vérification sur un DID qu'il contrôle (sans le consentement du propriétaire de cette adresse), un attaquant pouvait enregistrer les adresses des victimes en tant que méthodes de vérification sur son propre DID, puis transférer les soldes des victims vers une obligation contrôlée par l'attaquant — pour ensuite retirer et passer ces fonds hors chaîne. Cela a été exploité sur le mainnet ixo (ixo-5) le 2026-06-20. L'attaque ne nécessitait aucune clé, signature ou compromission du système de la victime ; tout compte détenant un solde dans une token utilisable par une obligation était à risque. Cela a été corrigé dans la version v8.0.0, livrée via la mise à jour logicielle on-chain v8. Le module x/bonds est désactivé : chaque message bonds est rejeté sur toutes les routes (top-level, authz, CosmWasm et ICA), et le EndBlocker par lots de bonds est un no-op afin qu'aucun autre mouvement de réserve ne puisse se produire. Tous les opérateurs de nœuds et validateurs doivent mettre à niveau vers la v8.0.0. La faille réside dans la logique du machine d'état de la chaîne et ne peut être corrigée qu'en exécutant le binaire patché. Il n'existe pas de contournement au niveau applicatif. La vulnérabilité se trouve dans la logique de consensus ; sa correction nécessite que le réseau exécute le binaire patché (v8.0.0). Le module bonds reste désactivé en v8.0.0 et ne sera réactivé que dans une version future, une fois que le modèle d'autorisation du signataire aura été corrigé.
Once again VulDB remains the best source for vulnerability data.