Exposición de una vulnerabilidad día cero en CometBFT: los nodos de la red Cosmos de 8.000 millones de dólares enfrentan el riesgo de un bloqueo total

La investigadora de seguridad Doyeon Park reveló el 21 de abril que en la capa de consenso de Cosmos, CometBFT, existe una vulnerabilidad de día cero de gravedad alta con nivel 7.1 según CVSS, que podría permitir que nodos sean atacados por pares maliciosos durante la fase de sincronización de bloques (BlockSync) y queden en un estado de interbloqueo, afectando una red que protege activos por más de 8.000 millones de dólares.

Principio técnico de la vulnerabilidad: reportes altamente manipulados de altura por parte de nodos maliciosos que provocan un interbloqueo infinito

La vulnerabilidad se encuentra en el mecanismo de BlockSync de CometBFT. En condiciones normales, cuando un par se conecta, informa una altura más reciente y creciente (latest). Sin embargo, el código actual no valida el caso en que el par informe primero una altura X y luego una altura inferior Y; por ejemplo, informa primero 2000 y luego 1001. En ese momento, el nodo en sincronización A esperará permanentemente para alcanzar la altura 2000, incluso si el nodo malicioso se desconecta; y la altura objetivo no se recalcula, lo que hace que el nodo entre en un interbloqueo infinito, sin poder reincorporarse a la red. Las versiones afectadas son <= v0.38.16 y v1.0.0, y las versiones corregidas son v1.0.1 y v0.38.17.

Fallo en la divulgación coordinada: cronología completa de cómo el proveedor degradó el CVE

Park siguió el proceso estándar de divulgación coordinada de vulnerabilidades (CVD), pero en varias ocasiones encontró obstáculos: el 22 de febrero presentó el primer informe; el proveedor pidió que se enviara como un issue público en GitHub, pero se negó a realizar la divulgación pública; el 4 de marzo, el segundo informe fue marcado por HackerOne como correo basura; el 6 de marzo, el proveedor degradó la severidad de la vulnerabilidad de “media/alta” por su cuenta a “informativa (el impacto puede ignorarse)”, y Park presentó una prueba de concepto (PoC) a nivel de red para refutar la degradación; el 21 de abril se tomó finalmente la decisión de divulgarla públicamente.

Park también señaló que, anteriormente, el proveedor había realizado una operación similar de degradación del CVE-2025-24371, una vulnerabilidad con el mismo impacto, y se considera que esto viola los estándares internacionales de evaluación de vulnerabilidades reconocidos como CVSS.

Guía de emergencia: acciones que los validadores deben tomar ahora

Antes de que el parche se implemente de forma oficial, Park recomienda que todos los validadores de Cosmos eviten reiniciar los nodos en la medida de lo posible. Los nodos que ya están en modo de consenso pueden seguir funcionando con normalidad; pero si se reinician y entran en el proceso de sincronización BlockSync, podrían quedar en un interbloqueo debido al ataque de nodos maliciosos.

Como mitigación temporal: si se detecta que BlockSync se queda atascado, se puede identificar a los pares maliciosos que reportan alturas no válidas elevando el nivel de registro (logs) y bloquear ese nodo en la capa P2P. La solución más fundamental es actualizar lo antes posible a las versiones corregidas v1.0.1 o v0.38.17.

Preguntas frecuentes

¿Esta vulnerabilidad de CometBFT puede robar activos directamente?

No. Esta vulnerabilidad no puede robar activos directamente ni comprometer la seguridad de fondos en la cadena. Su impacto consiste en que los nodos caen en un interbloqueo durante la fase de sincronización BlockSync, lo que impide que los nodos participen normalmente en la red. Esto podría afectar la capacidad de los validadores para proponer bloques y votar, y en consecuencia afectar la actividad de las cadenas de bloques relacionadas.

¿Cómo pueden los validadores determinar si un nodo ya ha sido atacado por esta vulnerabilidad?

Si un nodo se queda atascado en la fase BlockSync, que la altura objetivo deje de aumentar es una señal posible. Se puede aumentar el nivel de registro del módulo BlockSync y revisar si hay registros de pares que hayan enviado mensajes de altura anómalos, para identificar posibles nodos maliciosos y bloquearlos en la capa P2P.

¿Es estándar que el proveedor degrade la vulnerabilidad como “informativa”?

La calificación CVSS de Park (7.1, alta) se basa en el método estándar internacional de puntuación, y Park envió una PoC a nivel de red verificable para refutar la decisión de degradación. Que el proveedor la haya degradado a “el impacto puede ignorarse” es considerado por la comunidad de seguridad como una violación de estándares internacionales de evaluación de vulnerabilidades reconocidos como CVSS; esta controversia también es una de las razones centrales por las que Park decidió divulgarla finalmente de forma pública.