Hack de Cosmos EVM: el parche llevaba 96 días en main

El arreglo del fallo que vació seis cadenas de Cosmos llevó 96 días fusionado en la rama main de cosmos/evm antes de que alguien lo retroportara a las ramas de versión, el 19 de agosto de 2026 a las 17:53 UTC. La versión que por fin lo incorporaba, v0.7.2, se publicó a las 23:01:54 de ese mismo día, y el primer ataque a MANTRA ocurrió 20 horas y 4 minutos después. Ese recorrido —de un pull request fusionado en mayo a un bloque explotado en agosto— se puede reconstruir entero con la API pública de GitHub, sin acceso privilegiado y con las marcas de tiempo del propio repositorio. Este artículo sigue esa traza commit a commit y tag a tag: qué se arregló el 15 de mayo, por qué se quedó fuera de las versiones publicadas durante tres meses, qué veía un operador diligente que actualizó en julio, y qué muestra la cronología minuto a minuto de los cinco días de robos.

¿Qué falló en el StateDB de Cosmos EVM para que un saldo se envolviera a 2²⁵⁶?

Cosmos EVM es la pieza de software que permite a una cadena del ecosistema Cosmos ejecutar contratos de Ethereum. Para lograrlo tiene que mantener dos contabilidades sincronizadas: la del StateDB (la vista de saldos que espera la máquina virtual de Ethereum) y la de x/bank (el módulo de saldos del Cosmos SDK, el kit con el que se construyen estas cadenas). El fallo vive exactamente en la costura entre ambas.

El StateDB solo modela el saldo gastable de una cuenta. Las cuentas vesting del Cosmos SDK —cuentas con tokens bloqueados que se liberan según un calendario— tienen dos cifras: la gastable y la bloqueada. Y el módulo x/staking, junto con el precompilado de staking de la EVM, permite delegar también la parte bloqueada. Cuando una cuenta vesting delegaba más de su saldo gastable, la función SubBalance del StateDB restaba sin comprobar antes si había suficiente. Como el tipo uint256 no admite negativos, la resta no daba error: envolvía el saldo hasta aproximadamente 2²⁵⁶.

La segunda mitad del ataque usa ese saldo imposible. El atacante enviaba 2^256 − saldo(víctima) tokens a una cuenta con saldo alto —la dirección cero, o un multisig creado en el génesis de la cadena—, provocando el desbordamiento inverso: la víctima quedaba a cero y el atacante se quedaba con su saldo. Y como las dos operaciones se encadenan en una sola transacción, el cambio neto de oferta total es cero, lo que hace el movimiento mucho menos visible para cualquier alarma que vigile la emisión de tokens.

El montaje previo explica por qué esto no era un accidente de laboratorio. Según el post-mortem de Cosmos Labs publicado el 28 de agosto de 2026, el atacante precalculaba la dirección determinista donde se crearía un contrato, creaba allí una cuenta vesting y después desplegaba encima un contrato malicioso. Con esa combinación disparaba el underflow y el overflow dentro de la misma transacción neutra en oferta.

Un detalle de comportamiento separa las dos ramas de versión y decide cuánto duele el ataque. La línea 0.6.x reconcilia con el libro del SDK acuñando y quemando, de modo que la acuñación masiva provocaba un desbordamiento de la oferta total que detenía la cadena. La línea 0.7.x escribe saldos directamente en x/bank y acepta el cambio mientras sobreviva a la conversión de uint256 a int256. En la práctica, las cadenas de la línea 0.6.x se paraban solas durante el intento, mientras que las de la línea 0.7.x registraban el saldo modificado y seguían produciendo bloques.

¿Por qué el arreglo de Cosmos EVM tardó 96 días en llegar a una versión publicada?

La cronología del arreglo empieza el 25 de abril de 2026, cuando un investigador reportó la vulnerabilidad por el programa de bug bounty en HackerOne. El reporte incluía una prueba de concepto que demostraba robo de fondos en varias versiones sin etiquetar de Cosmos EVM. Cosmos Labs intentó reproducir ese robo en las versiones soportadas entonces —v0.6.0 y v0.5.1— con varias configuraciones de red, no lo consiguió en las de 18 decimales y concluyó que solo podía haber pérdida de fondos en redes con decimales distintos de 18. Como todas las redes Cosmos EVM en producción conocidas usaban 18 decimales, la evaluación de riesgo determinó que no amenazaba fondos de usuarios en producción.

Ese párrafo hay que leerlo en su segunda versión. El 10 de septiembre de 2026 a las 21:17 UTC, trece días después de publicar el informe, Cosmos Labs lo modificó y añadió una sección de correcciones al final: «una versión anterior de este informe indicaba incorrectamente detalles de la prueba de concepto incluida en el primer envío de bug bounty». La versión original describía esa prueba como propia de «una red Cosmos EVM de 6 decimales», lo que la presentaba como un caso de configuración marginal; la versión corregida dice que demostraba robo de fondos, y sitúa el error en el alcance de las pruebas de reproducción, limitadas a las dos versiones soportadas en aquel momento. El cambio no altera ninguna de las fechas de esta cronología, pero sí el punto de partida: lo que llegó el 25 de abril era una demostración de robo de fondos, no un caso de decimales.

Esa clasificación activó una política concreta y pública: el proceso de parche silencioso, reservado a fallos que no causan pérdida de fondos en cadenas de producción. El arreglo se fusiona en abierto en main, sin declarar qué corrige, confiando en que su relevancia de seguridad no sea evidente para quien lea el repositorio. El PR #1176, «fix: harden statedb balance and event amount handling», se abrió el 13 de mayo de 2026 a las 15:50 UTC y se fusionó el 15 de mayo: 190 líneas añadidas, 191 borradas, 15 ficheros tocados.

Ahí es donde el reloj se detiene. El post-mortem explica que el parche no se retroportó de inmediato a las ramas de versión porque era state-breaking: cambia el estado de la cadena y obliga a los validadores a una actualización coordinada, algo que no se espera de una versión de mantenimiento. La decisión fue esperar a la siguiente versión menor, cuando los operadores ya contarían con tener que coordinarse.

Esa versión menor no llegó. v0.7.0 se había publicado el 5 de mayo de 2026, diez días antes del merge del arreglo, de modo que la ventana de coordinación acababa de cerrarse. El listado de tags de cosmos/evm consultado el 7 de septiembre de 2026 no contiene ninguna v0.8.x: entre el 15 de mayo y esa fecha, el repositorio solo ha publicado versiones estables de mantenimiento —v0.6.1 y v0.7.1 el 27 de julio, v0.6.2 y v0.7.2 el 19 de agosto, v0.6.3 y v0.7.3 el 3 de septiembre—. El arreglo llevaba 117 días esperando a una versión menor que no existe (cálculo propio sobre la API de tags, contado hasta el 9 de septiembre de 2026).

A principios de agosto llegaron reportes adicionales de investigadores independientes con información suficiente para reproducir el fallo de forma más amplia. El equipo confirmó entonces que todas las cadenas Cosmos EVM estaban afectadas, con independencia de sus decimales. En ese punto la política estándar para un fallo que sí amenaza fondos en producción es distribuir el parche por canales privados a las redes afectadas. Cosmos Labs razonó que, al llevar el arreglo meses público en main sin explotación conocida, era seguro seguir por la vía silenciosa: se ofuscó el parche, se retroportó a release/v0.6.x y release/v0.7.x, y se publicó con notas de versión que mencionaban seguridad sin describir urgencia ni severidad.

El aviso GHSA-7g4w-cg88-2cq2 (GitHub Security Advisory, el registro de avisos de seguridad del propio repositorio), publicado el 28 de agosto de 2026, fija los rangos vulnerables de Cosmos EVM en < 0.6.2 y >= 0.7.0 < 0.7.2. Un validador que hiciera lo correcto el 27 de julio de 2026 —actualizar a la última versión publicada ese día, v0.7.1— se quedó expuesto 23 días y 7 horas más, hasta que v0.7.2 salió el 19 de agosto a las 23:01:54 UTC; durante ese periodo el arreglo llevaba entre 73 y 96 días disponible en main y ninguna nota de versión le dio motivo para ir a buscarlo. El margen posterior fue todavía más estrecho: el primer ataque a MANTRA —la cadena de activos tokenizados del ecosistema Cosmos— se ejecutó en el bloque 17444928 el 20 de agosto a las 19:06:00, 20 horas y 4 minutos después de la publicación del tag, tiempo en el que un operador tenía que detectar, entender y coordinar una actualización que rompe el estado a partir de una nota que mencionaba seguridad sin decir de qué severidad (cálculo propio sobre las marcas de publicación de la API de releases).

¿Cómo fue la cronología del hack de Cosmos EVM a MANTRA, TAC y KiiChain (20-25 de agosto de 2026)?

La ventana completa de ataques va del 20 de agosto a las 19:06 UTC al 25 de agosto a las 15:20 UTC: cuatro días y 20 horas. La tabla siguiente reconstruye los hitos con las marcas del post-mortem y añade el intervalo medido entre cada uno y el anterior, calculado sobre esas mismas marcas.

Tres cifras de esa tabla merecen leerse juntas. La primera: MANTRA tardó 4 horas y 7 minutos en detener la cadena desde el ataque inicial, tiempo suficiente para que el atacante volviera a entrar una segunda vez a las 22:59:01. La segunda: TAC recibió el aviso por Slack el 21 de agosto a las 09:33:15 y fue atacada 34 horas y 13 minutos más tarde, el 22 de agosto a las 19:46:37 — el post-mortem confirma que el equipo de TAC había recibido la comunicación previa sobre la actualización. La tercera: entre la transacción que sacó 2.985 millones de TAC del pool de staking y la primera venta en KyberSwap pasaron 2 minutos y 57 segundos, con la llegada de los fondos a BNB Chain a los 60 segundos exactos. La ventana de reacción de un humano frente a esa secuencia es inexistente.

Conviene no aplanar la distinción de canal. Cosmos Labs avisó por vías privadas —correo seguro y Slack— el 21 de agosto, mientras que rekt.news y Cryptotimes sitúan el primer reconocimiento público del incidente el 24 de agosto y la recomendación pública de detener las cadenas el 25: la comunicación privada precedió a la pública en tres días. KiiChain publicó su propio post-mortem técnico el 23 de agosto, cinco días antes que Cosmos Labs.

¿Por qué el PR del fork de Push Chain decía que ninguna versión de Cosmos EVM llevaba el arreglo?

El 20 de agosto de 2026 a las 07:16:09 UTC, un desarrollador del fork de Cosmos EVM que mantiene Push Chain abrió el pull request #40 en su repositorio público. El PR hacía lo que hace cualquier equipo responsable con un fallo detectado en su auditoría: incorporar el arreglo. Su título cita el identificador de la auditoría de Hacken, F-2026-18201, y su cuerpo describe el camino de explotación con precisión de manual —la resta sin comprobación en SubBalance, la envoltura a 2²⁵⁶, las dos variantes de pago (acuñar o drenar)—.

El PR incluye además una tabla de procedencia con una columna titulada «Has fix» donde marca v0.6.0, v0.7.0, v0.6.1, v0.7.1 y las tres v1.0.0-rc como «NO», y solo main como «YES». Y concluye en texto: el arreglo existe únicamente en main de upstream, no está en ninguna versión etiquetada, y actualizar a un tag publicado no soluciona nada porque el parche hay que traérselo a mano con un cherry-pick.

Esa tabla se escribió 8 horas y 14 minutos después de que v0.7.2 publicara ya el arreglo. El post-mortem de Cosmos Labs lo confirma sin rodeos: el pull request no menciona v0.6.2 ni v0.7.2, y afirma que actualizar a un tag publicado no remediaría el problema. Esa distancia mide cuánto ocultaba el parche ofuscado: un desarrollador que estaba mirando ese arreglo commit a commit, con el identificador de la auditoría en la mano, no vio que la versión publicada ocho horas antes ya lo llevaba.

El PR permaneció abierto y visible hasta el 24 de agosto a las 01:46 UTC, con la ventana de ataques aún abierta. El post-mortem lo sitúa antes del primer incidente conocido y advierte de que publicar rutas de explotación «puede aumentar el riesgo de un exploit»; 11 horas y 50 minutos separan su publicación del primer ataque a MANTRA (cálculo propio). Esa secuencia obliga a enunciar la conclusión con cuidado. Si la única fuente del atacante fue ese pull request, el retraso de 96 días no fue la causa del robo; fue la condición que lo hizo posible, porque un backport puntual en mayo habría dejado el documento sin cadenas vulnerables a las que apuntar. La política dejó la puerta abierta y otra cosa la empujó.

Queda además un desacuerdo de severidad sobre el mismo defecto: Hacken lo clasificó como High en su ficha F-2026-18201 y el aviso de Cosmos Labs lo publicó como critical. La diferencia importa porque la severidad es lo que decide si una divulgación va por canal privado o por pull request público.

¿Se robaron 20,8 o 5,72 millones de dólares en el hack de Cosmos EVM?

Circulan dos cifras y ambas son correctas, porque miden cosas distintas. Cosmos Labs contabiliza 5,72 millones de dólares realizados sobre seis cadenas: 2,87 millones vendidos en exchanges descentralizados a precios del 19 de agosto de 2026 —con el desglose literal de 2.613.674,48 USDT — 114,129045 ETH — 93,78 TON — 1,393618 USDC — 98,87 OSMO— más 2,85 millones estimados en exchanges centralizados a partir de datos públicos de volumen; el propio documento advierte de que esas cifras no han sido auditadas de forma independiente y que las cuentas de exchange centralizado están congeladas a la espera de la investigación policial. La prensa especializada suma en cambio el valor nominal a precio pre-exploit de los tokens extraídos en tres cadenas: 3,6 millones en MANTRA, más 7,5 en TAC y 9,7 en KiiChain, que suman 20,8 millones.

El puente entre ambas es aritmético y se puede reconstruir con los datos del post-mortem.

El cálculo es propio: el precio pre-exploit sale de dividir la cifra nominal de prensa entre los tokens extraídos que da el post-mortem, y el realizado, de dividir el ingreso en USDT entre los tokens efectivamente vendidos. El resultado explica la ratio de 3,64 veces entre los 20,8 y los 5,72 millones del hack de Cosmos EVM: el atacante solo pudo colocar cuatro de cada diez tokens robados, y a un tercio del precio previo. En KiiChain quedaron 80,7 millones de KII —el 54,4 % del total extraído— dentro de la propia cadena, recuperables tras la restauración de la red; en BNB Chain quedaron unos 1.662 millones de TAC sin vender a fecha del post-mortem (28 de agosto).

El caso más extremo de esa brecha está en una cuarta cadena que el post-mortem no detalla. Según la firma de analítica Bubblemaps, citada por BeInCrypto el 27 de agosto de 2026, el atacante infló su saldo en la cadena Nesa unas 200 veces, movió el equivalente nominal a unos 50 millones de dólares en NES y se quedó con unos 60.000 dólares netos: un 0,12 % de lo nominal (cálculo propio). Son datos de analítica de terceros recogidos por prensa, no del documento primario, que omite tres de las seis cadenas por brevedad.

Un último dato ordena la escala del problema, y va en dirección contraria a la intuición. El TVL DeFi (valor total depositado) conjunto de TAC y MANTRA sumaba 1.075.822 dólares el 6 de septiembre de 2026 según DefiLlama —534.005 de TAC, un 28,0 % menos que el 19 de agosto, y 541.817 de MANTRA, prácticamente plano—. Los 5,72 millones realizados son 5,3 veces esa suma. El dinero no salió de protocolos DeFi: salió del bonded_tokens_pool, de cuentas vesting, de un multisig del génesis y de una dirección de quema. La superficie expuesta era el libro de saldos de la propia cadena, que se mide con el stake bonded (los tokens delegados a validadores) y los saldos bloqueados de las cuentas de tesorería.

¿Por qué apareció un segundo fallo crítico en el StateDB de Cosmos EVM 15 días después?

El 3 de septiembre de 2026 a las 17:53:58 UTC, cosmos/evm publicó el aviso GHSA-367m-g444-9mg3, «Non-atomic StateDB commit», también de severidad crítica. El vector es distinto —el commit no atómico del StateDB por la vía del middleware IBC (el protocolo de comunicación entre cadenas de Cosmos) de x/erc20—, pero la pieza es la misma, y los rangos vulnerables incluyen precisamente las versiones que el aviso de agosto señalaba como remedio: >= 0.7.0 < 0.7.3 y >= 0.6.0 < 0.6.3.

La consecuencia operativa es directa. Las cadenas que obedecieron la orden de emergencia del 21 de agosto y actualizaron a v0.7.2 quedaron expuestas otra vez durante 14 días y 18 horas, hasta que v0.7.3 se publicó el 3 de septiembre a las 17:52:40 UTC. La comparación de tags muestra que entre v0.7.2 y v0.7.3 hay un único commit, c3ae9067a, con el mensaje escueto «Merge commit from fork»: el que genera el flujo de arreglo en repositorio privado que GitHub asocia a los avisos de seguridad.

Son cinco avisos críticos en dieciséis meses, del 13 de mayo de 2025 al 3 de septiembre de 2026, sobre una dependencia que comparten decenas de cadenas soberanas. Ninguno tiene CVE (el identificador estándar de vulnerabilidades) ni puntuación CVSS de gravedad asignada en la API de GitHub, lo que los deja fuera del radar de las herramientas de inventario de vulnerabilidades que muchos equipos de infraestructura usan por defecto. A eso se añade el contexto que el propio Cosmos Labs documenta: más de 850.000 dólares pagados en bug bounty desde enero de 2025, 37 vulnerabilidades parcheadas en silencio en los trece meses previos al post-mortem, de julio de 2025 a agosto de 2026, y una auditoría de Sherlock —la plataforma de auditorías por concurso— publicada en julio de 2025 que no detectó este fallo.

¿Qué puede comprobar un operador de Cosmos EVM antes del próximo parche silencioso?

El post-mortem cuantifica la parte del problema que ninguna política de divulgación resuelve sola: el ecosistema Cosmos abarca más de 115 cadenas públicas conocidas, y el software es libre y desplegable sin permiso. Cosmos Labs se coordinó con 40 cadenas, seis resultaron explotadas y trece redes potencialmente expuestas parchearon, pararon o mitigaron sin incidente. Conviene no convertir eso en un «solo 13 de 40 reaccionaron»: las 40 son las cadenas con las que hubo coordinación durante la respuesta, y el censo de redes realmente expuestas nunca se ha publicado.

Cosmos Labs se ha comprometido a revisar el triaje de vulnerabilidades críticas y a publicar estándares sobre cuándo se recomienda detener una cadena en lugar de actualizarla y cuándo se usa canal privado en lugar del parche silencioso. Mientras esos estándares no existan, la verificación queda del lado de quien opera, y estas cinco comprobaciones se hacen con la API pública de GitHub sin estar en ninguna lista:

1. Comparar el tag desplegado directamente contra main: el endpoint /compare/<tag>...main devuelve los commits que faltan. En este caso, el que importaba llevaba en la lista desde el 15 de mayo de 2026 y tenía la palabra statedb en el mensaje.
2. Vigilar el apartado de avisos del propio repositorio. Los cinco avisos críticos de cosmos/evm se publican en /security/advisories con sus rangos de versión afectados, del 13 de mayo de 2025 al 3 de septiembre de 2026.
3. Tratar «menciona seguridad sin detallar» como señal, no como ruido. Las notas de v0.6.2 y v0.7.2 del 19 de agosto de 2026 estaban redactadas así por política, y ese es exactamente el aspecto que tiene un parche silencioso ya retroportado.
4. Registrar el contacto de seguridad del equipo. Once despliegues de Cosmos EVM se enteraron tarde en agosto de 2026 porque nadie de su equipo estaba en la lista de correo de Cosmos Labs.
5. Medir la exposición con el stake bonded y los saldos bloqueados. El TVL DeFi se queda muy corto como medida del alcance de un fallo de este tipo: los 5,72 millones de dólares realizados fueron 5,3 veces el TVL DeFi conjunto de TAC y MANTRA del 6 de septiembre de 2026.

Para quien tiene tokens en una cadena Cosmos EVM y no opera un validador, el aprendizaje es más sencillo de aplicar: los saldos que estuvieron en riesgo aquí fueron los de cuentas vesting, tesorerías del génesis y pools de staking, es decir, posiciones que nadie mira a diario. El calendario de versiones del repositorio del que depende tu cadena es información pública, y la distancia entre el último tag desplegado y main se consulta en un navegador.

Fuentes y enlaces: Cosmos Labs — post-mortem GHSA-7g4w-cg88-2cq2 (28-ago-2026) · Corrección del post-mortem (commit, 10-sep-2026) · Cryptotimes — recomendación pública de halt (25-ago-2026) · Aviso GHSA-7g4w-cg88-2cq2 · Aviso GHSA-367m-g444-9mg3 (3-sep-2026) · PR #1176 de cosmos/evm · Comparación v0.7.1...v0.7.2 · Release v0.7.2 · PR #40 de pushchain/push-chain-evm · Cosmos SDK — proceso de parche silencioso · Sherlock — Interchain Labs Collaborative Audit Report (jul-2025, PDF) · rekt.news — KiiChain · crypto.news (31-ago-2026) · DefiLlama — TVL histórico de TAC