Cosmos EVM, falla crítica sin CVE: seis blockchains afectadas, el parche silencioso no detuvo el exploit

El 28 de agosto de 2026, Cosmos Labs publicó un aviso en GitHub y un análisis post mortem sobre una vulnerabilidad crítica en el módulo compartido Cosmos EVM, el entorno para la ejecución de contratos inteligentes compatibles con Ethereum en el ecosistema Cosmos SDK. La falla, identificada como GHSA-7g4w-cg88-2cq2, fue clasificada como crítica por el proveedor, pero no recibió un identificador CVE, una clasificación CWE ni una puntuación CVSS. Las versiones afectadas son todas las anteriores a 0.6.2 y las comprendidas entre 0.7.0 y 0.7.1. Las correcciones se publicaron el 19 de agosto en las versiones v0.6.2 y v0.7.2, pero la actualización rompe el estado y requiere una actualización de red coordinada. Entre el 20 y el 25 de agosto, la falla fue explotada activamente contra seis blockchains, con pérdidas económicas estimadas en millones de dólares.

Cómo funciona el ataque: underflow, cuentas de vesting y saldos “inflados”

La vulnerabilidad se origina en el código que reconcilia el estado del EVM con el módulo x/bank de Cosmos SDK. El StateDB del EVM solo realiza un seguimiento del saldo gastable de una cuenta. En las cuentas de vesting, sin embargo, el estado SDK contiene tanto un saldo gastable como un saldo bloqueado, que puede delegarse a través del módulo x/staking y la precompilada de staking.

Cuando una cuenta de vesting delega más que su saldo gastable, la escritura posterior resta el importe total delegado de un saldo inferior: la resta no se comprueba y el valor entra en underflow, envolviéndose a aproximadamente 2^256. La reconciliación posterior acuña con un delta positivo y quema con un delta negativo. Por lo tanto, un atacante puede mover una cantidad finita desde una cuenta con saldo “envuelto” y enviar a una víctima una cantidad igual a 2^256 menos su saldo, de modo que la reconciliación queme los fondos reales de la víctima.

En las cadenas que ejecutan la línea 0.6.x, la acuñación o quema se produce en el libro mayor SDK subyacente: una acuñación elevada provoca un desbordamiento de la oferta que detiene la cadena. En las líneas 0.7.x, los saldos se establecen directamente en x/bank y aceptan modificaciones que sobreviven a la conversión de uint256 a int256. En ambos casos, toda la operación se ejecuta en una única transacción con una variación neta de la oferta igual a cero, a partir de un contrato desplegado en una dirección precalculada que previamente se había convertido en cuenta de vesting. La explotación requiere que la cadena permita la creación sin permisos de cuentas de vesting.

La cronología: informe en abril, confirmación en agosto, parche silencioso

La falla se informó el 25 de abril a través del programa de bug bounty de Cosmos Labs. Inicialmente, el equipo la evaluó como sin riesgo para los fondos en las redes en vivo: no pudo reproducirla en redes con 18 decimales y concluyó erróneamente que solo afectaba a redes con decimales diferentes. Solo el 13 de agosto llegó la confirmación de que todas las cadenas Cosmos EVM estaban afectadas, independientemente de la configuración de decimales.

La corrección principal — una protección contra underflow en la escritura de vuelta SubBalance del StateDB — ya se había introducido en la rama principal con la PR #1176, fusionada el 15 de mayo. Los backports se realizaron mucho más tarde: PR #1253 para la línea v0.6.x y PR #1254 para v0.7.x, que condujeron a las versiones v0.6.2 y v0.7.2 del 19 de agosto.

La corrección pasó por el proceso de parche silencioso, reservado por Cosmos Labs para los problemas que no causan pérdida de fondos en producción. La política prevé mitigaciones de emergencia o distribución privada para riesgos inmediatos, pero en este caso el equipo consideró seguro proceder en silencio porque el parche ya era público en la rama principal y no se conocía explotación alguna.

La evaluación resultó ser errónea. El 20 de agosto a las 07:16 UTC, ocho horas y quince minutos después de la publicación de las versiones, una PR pública en el fork de Push Chain describió en detalle la vulnerabilidad y la ruta de explotación. Once horas y cincuenta minutos después, a las 19:06 UTC, comenzó el primer ataque contra MANTRA. La primera notificación privada de Cosmos Labs por correo electrónico seguro no se envió hasta el 21 de agosto a las 03:36 UTC, aproximadamente dos horas después de que MANTRA informara de la explotación.

Impacto: seis cadenas, millones de dólares vendidos en exchanges

Cosmos Labs tiene conocimiento de seis blockchains en las que el exploit se utilizó activamente. MANTRA es la única nombrada explícitamente como primera víctima. Los atacantes vendieron aproximadamente 2,87 millones de dólares en activos afectados en exchanges descentralizados, cifra basada en los precios del 19 de agosto y proporcionada por las propias cadenas, no verificada de forma independiente. Otros 2,85 millones de dólares se vendieron en exchanges centralizados, estimación basada en datos públicos de volumen.

El ecosistema Cosmos comprende más de 115 blockchains públicas conocidas, pero Cosmos Labs no dispone de un registro completo de las redes que ejecutan su software. Esta brecha ya había obligado en julio a los proveedores downstream a parchear defectos de los sistemas de archivos incluidos. Durante el incidente, el equipo descubrió once implementaciones de Cosmos EVM que nunca se habían registrado en sus canales de seguridad.

Qué deben hacer los operadores: parches, workarounds y verificaciones

El aviso oficial recomienda actualizar a v0.6.2 o v0.7.2 o versiones posteriores, aplicando el cambio como una actualización de red coordinada porque rompe el estado. Si no es posible actualizar de inmediato, la recomendación es detener la cadena en lugar de intentar una actualización de gobernanza coordinada. No existe una mitigación puramente de configuración: deshabilitar la precompilada de staking elimina la ruta de activación principal, pero no sustituye el parche.

The Hacker News enumeró pasos operativos adicionales para los desarrolladores. El primero es cerrar la precondición: rechazar en el ante handler los mensajes MsgCreateVestingAccount, MsgCreatePermanentLockedAccount y MsgCreatePeriodicVestingAccount, sin tocar las cuentas de vesting definidas en la génesis. El segundo es verificar la ruta de código en vivo en un fork: un cherry-pick que solo corrige el helper exportado puede dejar una copia duplicada no exportada, mientras todas las pruebas siguen pasando. El tercero es aplicar las dos correcciones que el aviso omite: la instantánea del saldo bloqueado (PR #1187, fusionada el 20 de mayo) y la protección para cuentas de módulo (commit 3524ebc). La protección rechaza incondicionalmente las cuentas de módulo, lo que interrumpe las llamadas EVM realizadas desde una cuenta de módulo. Por último, cada equipo debería registrar un contacto de seguridad en Cosmos Labs.

ZetaChain aplicó las tres correcciones el 21 de agosto, señalando que el cherry-pick dejaba la ruta en vivo del fork sin corregir porque el fork contenía helpers duplicados no exportados. Warden Protocol, dos días después, bloqueó por completo la creación de cuentas de vesting: en Warden, las cuentas de vesting son la única fuente de saldos bloqueados y ninguna funcionalidad depende de su creación, por lo que eliminar esa ruta cierra la precondición sin depender de la corrección de la reconstrucción.

Parche silencioso y antecedentes: 37 vulnerabilidades sin descripción pública

El aviso documenta un solo cambio upstream: la protección contra underflow de la PR #1176. Pero en el mismo repositorio existen otras dos correcciones de saldo no mencionadas: la PR #1187, que captura el saldo bloqueado de una cuenta para reconstruir correctamente el saldo bancario después de una modificación desde una precompilada, y el commit 3524ebc, titulado “Merge commit from fork”, que rechaza cualquier intento de establecer el saldo de una cuenta de módulo. Los backports de la PR #1187 se abrieron y fusionaron en un plazo de veinticuatro horas en ambas líneas de lanzamiento, mientras que el backport de la PR #1176 llegó unos noventa días después.

Las notas de la versión de v0.6.2 y v0.7.2 afirman que contienen correcciones de seguridad importantes, pero omiten el backport de seguridad de los registros de cambios. The Hacker News confirmó el 29 de agosto que ninguna de las dos versiones enumera los pull requests que lo incorporan.

Cosmos Labs declaró haber distribuido en silencio parches para 37 vulnerabilidades en los últimos 13 meses, sin que los desarrolladores downstream describieran públicamente las rutas de exploit. La decisión de no distribuir el parche de forma privada después de la confirmación del 13 de agosto de que todas las cadenas estaban afectadas es ahora el centro de las críticas. The Hacker News se puso en contacto con Cosmos Labs para obtener comentarios y está a la espera de respuesta.