Explotada una vulnerabilidad crítica en Cosmos EVM tras conocerse que afectaba a todas las blockchains

Aviso de Cosmos Labs sobre falla crítica

Cosmos Labs ha advertido que un fallo crítico en el manejo de saldos dentro del módulo compartido Cosmos EVM fue explotado para drenar fondos de seis blockchains entre el 20 y el 25 de agosto de 2026. La vulnerabilidad, identificada como GHSA-7g4w-cg88-2cq2, ha sido calificada como Crítica por Cosmos Labs y fue publicada sin un identificador CVE, clasificación de debilidad o puntuación CVSS.

Las versiones afectadas son anteriores a 0.6.2 y desde 0.7.0 hasta antes de 0.7.2. El parche se publicó el 19 de agosto en las versiones v0.6.2 y v0.7.2, y los operadores de cadenas deben actualizar a una de estas versiones o posteriores. Dado que el cambio rompe el estado de la cadena, se requiere una actualización coordinada de la red. Para aquellos que no puedan actualizar de inmediato, Cosmos Labs recomienda detener la cadena en lugar de intentar una actualización mediante gobernanza coordinada.

Autopsia y causas del incidente

En una autopsia publicada el 28 de agosto, Cosmos Labs explicó que el fallo fue reportado a través de su programa de recompensas por errores el 25 de abril, y en ese momento se evaluó que no representaba un riesgo para los fondos en redes en vivo. “No pudimos reproducir la vulnerabilidad en redes con 18 decimales y concluimos erróneamente que solo afectaba a redes con menos decimales”, señaló la compañía.

El 13 de agosto se confirmó que todas las cadenas Cosmos EVM estaban afectadas, sin importar la configuración decimal. A pesar de ello, el parche se distribuyó a través del mismo proceso público de parche silencioso que la empresa reserva para problemas que no causan pérdida de fondos en cadenas de producción. Cosmos Labs justificó esta decisión señalando que el parche ya estaba disponible públicamente en la rama principal sin que se conociera explotación alguna en ese momento.

La falla reside en el código que reconcilia el estado de la Máquina Virtual de Ethereum (EVM) con el módulo x/bank del SDK de Cosmos. El EVM StateDB rastrea solo el saldo gastable de una cuenta, mientras que las cuentas de vesting en el estado del SDK poseen tanto un saldo gastable como uno bloqueado. Tanto x/staking como el precompilado de staking permiten delegar la porción bloqueada. Cuando una cuenta de vesting delega más de su saldo gastable, la escritura posterior a la delegación resta el monto total delegado del saldo gastable más pequeño, pero la resta no está verificada y el saldo se envuelve a aproximadamente 2^256.

La reconciliación posterior acuña monedas en caso de delta positivo y quema en caso de delta negativo. El atacante puede mover una cantidad finita fuera de la cuenta envuelta, o enviar a una cuenta víctima 2^256 menos su saldo para que la reconciliación queme su saldo real. En cadenas con 0.6.x, la acuñación y quema ocurren en el libro mayor SDK subyacente, por lo que una gran acuñación causa un desbordamiento de suministro que detiene la cadena. En cadenas con 0.7.x, los saldos se establecen directamente en x/bank y aceptan cambios que sobreviven a la conversión de uint256 a int256.

Recomendaciones para los operadores

Cosmos Labs aconseja a los operadores que ejecutan Cosmos EVM tomar las siguientes medidas:

Actualizar a v0.6.2 o v0.7.2 o posterior, aplicándolo como una actualización coordinada de la red porque el cambio rompe el estado.
Detener la cadena en lugar de votar. Las cadenas que no pueden actualizar de inmediato deben detener la producción de bloques, ya que no existe una mitigación solo de configuración y deshabilitar el precompilado de staking elimina la vía principal de ataque pero no es un sustituto del parche.
Cerrar la condición previa rechazando mensajes MsgCreateVestingAccount, MsgCreatePermanentLockedAccount y MsgCreatePeriodicVestingAccount en el manejador ante. Las cuentas de vesting definidas en genesis no se ven afectadas.
Verificar el código en un fork. Un cherry-pick que parchea solo el helper exportado puede dejar una copia no exportada duplicada mientras todas las pruebas pasan.
Aplicar las dos correcciones que el aviso omite: la instantánea del saldo bloqueado y la protección de cuentas de módulo. Esta última rechaza cuentas de módulo incondicionalmente, lo que rompe llamadas EVM desde una cuenta de módulo.
Registrar un contacto de seguridad con Cosmos Labs, que conoció durante el incidente 11 implementaciones de Cosmos EVM que nunca se habían registrado.

Cambios y respuesta del ecosistema

El aviso documenta un cambio principal: el guardia de subflujo SubBalance, fusionado a main el 15 de mayo como pull request #1176 y retroportado el 13 de agosto. Dos correcciones adicionales de saldo residen en el mismo repositorio pero no se mencionan en el aviso. El pull request #1187, fusionado el 20 de mayo, toma una instantánea del saldo bloqueado de una cuenta para reconstruir correctamente el saldo bancario después de que un precompilado lo modifique. Los backports de #1187 se abrieron el mismo día y se fusionaron en 24 horas, mientras que el backport de #1176, igualmente rompedor, tardó unos 90 días. El commit 3524ebc, titulado “Merge commit from fork”, rechaza cualquier intento de establecer el saldo de una cuenta de módulo.

El contribuyente de ZetaChain, morde08, indicó en un port de las tres correcciones publicado el 21 de agosto que el cherry-pick del parche dejó sin parchear la ruta activa del fork, porque el fork tenía helpers no exportados duplicados mientras que el cambio upstream afectaba solo al exportado. Warden Protocol optó por otro enfoque dos días después, bloqueando la creación de cuentas de vesting por completo. “Las cuentas de vesting son la única fuente de saldos bloqueados en Warden y nada depende de que los usuarios puedan crearlas, así que eliminar esa vía cierra la condición previa en lugar de confiar en que la reconstrucción sea correcta”, explicó el contribuyente jlehtimaki.

Una solicitud de extracción pública en el fork de Push Chain de Cosmos EVM describió la vulnerabilidad y su vía de explotación en detalle a las 07:16 UTC del 20 de agosto, ocho horas y quince minutos después de que se publicaran las versiones corregidas. El primer ataque contra MANTRA comenzó a las 19:06 UTC, once horas y cincuenta minutos después. Cosmos Labs envió su primera notificación privada a través de correo seguro a las 03:36 UTC del 21 de agosto, unas dos horas después de que MANTRA informara que había sido explotada.

Cosmos Labs ha publicado parches para 37 vulnerabilidades de forma silenciosa en los últimos 13 meses sin que los desarrolladores downstream describieran públicamente las vías de explotación. Las notas de publicación de v0.6.2 y v0.7.2 indican que contienen correcciones de seguridad importantes y que deben aplicarse lo antes posible, pero ambas omiten el backport de seguridad de sus changelogs. The Hacker News confirmó el 29 de agosto que ninguna de las dos publicaciones menciona los pull requests que contenían el parche.

Cosmos Labs dijo que tiene conocimiento de seis cadenas en las que se aprovechó el exploit. Los atacantes vendieron aproximadamente 2,87 millones de dólares en activos afectados en exchanges descentralizados, según precios del 19 de agosto, cifra que la compañía dijo fue proporcionada por las cadenas afectadas y no ha sido auditada de forma independiente. Además, se vendieron alrededor de 2,85 millones de dólares en exchanges centralizados, una estimación basada en datos públicos de volumen. El ecosistema Cosmos abarca más de 115 blockchains públicas conocidas, pero la empresa afirma que no tiene un registro completo de las redes que ejecutan su software, la misma brecha que dejó a proveedores downstream parcheando vulnerabilidades de archivos empaquetados en julio.