Exposition d’une vulnérabilité zero-day dans CometBFT : 8 milliards de dollars américains de nœuds du réseau Cosmos risquent un gel définitif

L’analyste en recherche sécurité Doyeon Park a révélé le 21 avril qu’il existe une vulnérabilité de type zero-day à haut risque notée 7,1 sur CVSS dans CometBFT, la couche de consensus de Cosmos, susceptible d’être exploitée par des pairs malveillants pour attaquer des nœuds pendant la phase de synchronisation des blocs (BlockSync) et de les faire tomber en état d’interblocage, affectant un réseau qui protège plus de 8 milliards de dollars d’actifs.

Principe technique de la vulnérabilité : un signalement de hauteur hautement manipulé par un nœud malveillant conduisant à un interblocage sans fin

La vulnérabilité se trouve dans le mécanisme BlockSync de CometBFT. Dans des conditions normales, lors de la connexion, les nœuds pairs annoncent une hauteur de bloc la plus récente en augmentation (latest). Cependant, le code actuel ne vérifie pas le cas où un pair annonce d’abord une hauteur X puis une hauteur plus basse Y — par exemple annonce d’abord 2000, puis 1001. Dans ce cas, le nœud A en synchronisation attendra indéfiniment de rattraper la hauteur 2000 ; même si le nœud malveillant se déconnecte, la hauteur cible ne sera pas recalculée, ce qui provoque un interblocage sans fin du nœud, l’empêchant de se reconnecter au réseau. Les versions concernées sont <= v0.38.16 et v1.0.0 ; les versions corrigées sont v1.0.1 et v0.38.17.

Défaillance de la divulgation coordonnée : chronologie complète de la dégradation CVE par le fournisseur

Park a suivi le processus standard de divulgation coordonnée des vulnérabilités (CVD), mais plusieurs obstacles se sont présentés au cours de la démarche : le 22 février, soumission du premier rapport ; le fournisseur a demandé qu’il soit soumis sous forme d’un GitHub issue public mais a refusé la divulgation publique ; le 4 mars, le second rapport a été marqué comme spam par HackerOne ; le 6 mars, le fournisseur a dégradé de lui-même la gravité de la vulnérabilité de « moyenne/élevée » à « informative (impact négligeable) » ; Park a soumis une preuve de concept (PoC) au niveau du réseau pour contester la dégradation ; et le 21 avril, la décision finale a été prise de divulguer publiquement.

Park a également indiqué que le fournisseur avait auparavant effectué une opération similaire de dégradation sur le CVE-2025-24371, une vulnérabilité présentant un impact identique, ce qui serait en violation des standards internationaux reconnus d’évaluation des vulnérabilités comme le CVSS.

Instructions d’urgence : actions que les validateurs doivent prendre maintenant

Avant le déploiement officiel du correctif, Park recommande à tous les validateurs Cosmos d’éviter autant que possible de redémarrer les nœuds. Les nœuds déjà en mode consensus peuvent continuer à fonctionner normalement ; toutefois, s’ils sont redémarrés et entrent dans le processus de synchronisation BlockSync, ils peuvent tomber en interblocage à cause d’une attaque par des pairs malveillants.

À titre de mesure d’atténuation temporaire : si BlockSync se bloque, vous pouvez identifier les pairs malveillants rapportant des hauteurs non valides en augmentant le niveau de journalisation, puis bloquer ce nœud au niveau P2P. La solution la plus fondamentale consiste à mettre à niveau dès que possible vers les versions corrigées v1.0.1 ou v0.38.17.

Questions fréquentes

Cette vulnérabilité de CometBFT peut-elle voler directement des actifs ?

Non. Cette vulnérabilité ne permet pas de voler directement des actifs ni de compromettre la sécurité des fonds on-chain. Son impact est de faire tomber les nœuds en interblocage pendant la phase de synchronisation BlockSync, empêchant les nœuds de participer correctement au réseau ; cela peut affecter la capacité des validateurs à produire des blocs et à voter, et donc influer sur l’activité des chaînes de blocs concernées.

Comment les validateurs peuvent-ils déterminer si un nœud a été attaqué par cette vulnérabilité ?

Si le nœud se bloque pendant la phase BlockSync, c’est un signe possible : la hauteur cible cesse d’augmenter. Vous pouvez augmenter le niveau de journalisation du module BlockSync, et vérifier si des journaux indiquent des pairs ayant envoyé des messages de hauteur anormale, afin d’identifier les nœuds malveillants potentiels, puis de les bloquer au niveau P2P.

Le fait que le fournisseur ait dégradé la vulnérabilité en « informative » est-il conforme aux standards ?

L’évaluation CVSS de Park (7,1, risque élevé) s’appuie sur la méthode standard d’évaluation internationale, et Park a soumis une PoC vérifiable au niveau du réseau pour réfuter la décision de dégradation. Le fait que le fournisseur l’ait dégradée en « impact négligeable » est considéré par la communauté de sécurité comme une violation des standards internationaux reconnus d’évaluation des vulnérabilités tels que le CVSS ; cette controverse est aussi l’une des raisons clés pour lesquelles Park a finalement décidé de divulguer publiquement.