Vulnerabilidad de Cosmos EVM: 5,72 millones de dólares de seis cadenas de bloques y por qué tres cadenas tuvieron que pararse

Si tienes tokens en una cadena de bloques pequeña, tu saldo depende de dos cosas: de esa cadena y del software que comparte con muchas otras. Justo eso se hizo visible en agosto. Un fallo en un componente compartido llamado Cosmos EVM fue explotado en seis cadenas de bloques entre el 20 y el 25 de agosto de 2026. Salieron unos 5,72 millones de dólares, tres cadenas detuvieron su actividad y Cosmos Labs afirma haber contactado con 40 redes. El 28 de agosto el equipo presentó un análisis posterior que describe el desarrollo de forma abierta. Este artículo ordena qué ocurrió, por qué las cifras de daño que circulan divergen tanto y qué puedes comprobar si tienes tokens en una cadena afectada.

La vulnerabilidad de Cosmos EVM en resumen: 5,72 millones de dólares de seis cadenas

Cosmos EVM es un módulo de software que amplía una cadena de bloques Cosmos con un entorno de ejecución compatible con Ethereum. Un módulo, en este sentido, es un paquete de código terminado que un equipo integra en su propia cadena en lugar de escribir él mismo la función. La ventaja es la rapidez. El precio es una dependencia común: un fallo en el módulo es un fallo en cada cadena que lo emplea.

La vulnerabilidad lleva el identificador GHSA-7g4w-cg88-2cq2 y el propio Cosmos Labs la clasifica como crítica. Según la exposición de The Hacker News, se publicó sin número CVE, sin clasificación de vulnerabilidad y sin puntuación CVSS. Están afectadas las versiones inferiores a 0.6.2 y las que van desde 0.7.0 hasta antes de 0.7.2; el fallo se corrigió en las versiones v0.6.2 y v0.7.2, aparecidas el 19 de agosto de 2026.

No está afectado el Cosmos Hub con su token ATOM, que funciona sin este módulo. Si buscas su página de cotización, la encontrarás en nuestra predicción del precio de ATOM. El riesgo de confusión es real, porque la palabra Cosmos figura en el nombre de ambas cosas, y explica parte de la inquietud de la semana pasada.

Conciliación de saldos y desbordamiento: cómo funciona técnicamente la brecha de Cosmos EVM

El fallo se sitúa en la juntura entre dos contabilidades. Una cadena Cosmos lleva los saldos en el módulo x/bank, mientras que el entorno de Ethereum los lleva en paralelo en su propia base de datos de estado, la StateDB. Ambas deben mostrar la misma cifra después de cada transacción, y esa conciliación es el punto en el que la cosa se atascó.

Según la descripción de The Hacker News, el problema surge cuando una llamada cuenta de adquisición progresiva delega más de lo que permite su saldo libremente disponible. Una cuenta de adquisición progresiva es una dirección cuyos tokens solo se liberan conforme a un calendario; una parte del saldo está bloqueada y otra está disponible. Al reescribir tras la delegación, el código restaba el importe delegado completo del importe disponible, menor, sin comprobar si el resultado podía siquiera ser positivo.

Lo que sigue es un clásico de la aritmética informática. Si a un número sin signo se le resta más de lo que contiene, no pasa a negativo, sino que salta al extremo superior de su rango de valores. De un déficit mínimo nace un saldo del orden de 2 elevado a 256. El atacante pudo después retirar fondos de esa cuenta desbordada o enviar a una cuenta ajena un importe calculado de modo que la conciliación aniquilara el saldo de esta.

Qué es un módulo compartido en una cadena de bloques

Un módulo compartido es código que varias cadenas de bloques independientes toman de la misma fuente e integran en su propio software. Para ti como titular eso significa que la pregunta de si tu cadena es segura no puede responderse solo por la reputación de su equipo. Depende también de qué componentes ajenos emplea ese equipo y de con qué rapidez aplica las actualizaciones.

Por qué las cuentas de adquisición progresiva fueron la puerta de entrada

Las cuentas de adquisición progresiva están muy extendidas en las redes jóvenes, porque equipos, inversores y primeros colaboradores suelen recibir sus asignaciones de forma escalonada. Son por tanto un tipo de cuenta corriente que mantiene casi toda cadena nueva, y no un caso especial marginal. Por eso Cosmos Labs recomienda a las redes afectadas, entre otras cosas, rechazar temporalmente la creación de nuevas cuentas de este tipo.

Cuatro meses entre el aviso y la alarma: la cronología del análisis posterior

La secuencia procede del análisis posterior que Cosmos Labs publicó el 28 de agosto de 2026 y de los informes especializados que lo han evaluado. Es la verdadera razón por la que el caso se discute más allá del incidente concreto.

El 25 de abril de 2026 entró el aviso a través del programa de recompensas por fallos. Entonces se valoró que no suponía riesgo alguno para los fondos en redes productivas. El 15 de mayo, según expone CryptoSlate, una corrección entró en la rama principal como parche público silencioso, es decir, sin marcarse como crítica para la seguridad. El 13 de agosto el equipo confirmó internamente que todas las cadenas Cosmos EVM están afectadas, con independencia de su configuración decimal.

El 19 de agosto aparecieron las versiones corregidas. El 20 de agosto a las 07:16 UTC quedó accesible una primera descripción pública de la vía de ataque; ese mismo día a las 19:06 UTC se ejecutó la primera operación no autorizada en MANTRA. La primera notificación privada a las cadenas afectadas salió, según esta reconstrucción, el 21 de agosto a las 03:36 UTC, unas dos horas después de que MANTRA hubiera comunicado el incidente. El llamamiento público a los validadores para que detuvieran sus cadenas siguió el 24 de agosto.

Valor nominal frente a lo obtenido: por qué divergen las cifras de daño del hackeo de Cosmos EVM

Quien recorre la cobertura periodística se topa con importes que van desde algo menos de dos hasta bastante más de nueve millones de dólares. Es una cuestión de qué se mide y no una contradicción; la distinción merece la pena, porque se repite en cada aviso de exploit.

La suma citada con frecuencia de unos 5,72 millones de dólares se refiere a lo que el atacante convirtió efectivamente en dinero: unos 2,87 millones a través de exchanges descentralizados y unos 2,85 millones a través de plataformas centralizadas, calculado a las cotizaciones del 19 de agosto. Las cifras claramente superiores reflejan, en cambio, el valor nominal de los tokens salidos al precio previo al incidente.

La diferencia nace de la propia presión vendedora. En KiiChain, según el informe de Protos, la cadena cifra en 148.326.583,15 los KII salidos, cuyo valor nominal rondaba los nueve millones de dólares, mientras que su venta reportó unos 1,6 millones. Quien lea avisos así debería comprobar siempre si se habla de tokens sustraídos o de fondos obtenidos.

MANTRA, KiiChain y TAC: qué ocurrió en las tres cadenas conocidas

Hasta ahora se han nombrado públicamente tres de las seis redes explotadas. MANTRA detuvo su cadena el 21 de agosto en el bloque 17.449.398 y reanudó la producción de bloques el 22 de agosto con la versión 8.4.0. Sobre el momento del reinicio circulan datos entre las 03:38 y las 05:30 UTC; describimos el proceso el 22 de agosto en nuestro artículo sobre la parada de la red de MANTRA y la retirada bloqueada, tomando el primero de esos dos valores. El equipo declaró que los saldos de los usuarios no fueron alterados y que había dos direcciones bajo su propio control afectadas. CryptoSlate, por su parte, cifra el lado MANTRA del incidente en unos 3,6 millones de dólares de valor nominal con 720,9 millones de tokens. Ambos datos conviven, y no los limamos.

KiiChain se detuvo en el bloque 9.355.723. Según su propia exposición, allí se aplicó la misma técnica dieciocho veces seguidas. TAC paró el 22 de agosto en el bloque 24.671.475, según el equipo después de que una cuenta hubiera quedado vaciada. En ambos casos los equipos atribuyeron la causa al código compartido de Cosmos EVM y no a su propia lógica.

Más allá de las tres citadas, Cosmos Labs comunicó que otras 13 cadenas potencialmente afectadas fueron actualizadas, detenidas o aseguradas antes de que se produjera un ataque. Once instalaciones del módulo eran por completo desconocidas para el equipo antes del incidente y solo se encontraron en el curso de la revisión.

La parada de cadena como freno de emergencia: por qué Cosmos Labs aconsejó a los validadores detenerse

Una parada de cadena significa que los validadores cesan la producción de bloques; la red deja de procesar transacciones hasta que se reinicia de forma coordinada. Desde fuera parece una pérdida de control. En este caso fue la opción prudente.

La razón está en el orden. Una actualización ordinaria de red mediante una votación de gobernanza tarda de horas a días, y en ese tiempo la brecha seguiría abierta mientras la vía de ataque ya estaba descrita públicamente. Por eso Cosmos Labs aconsejó a los operadores actualizar de inmediato a v0.6.2, v0.7.2 o posterior y, si eso no era posible al momento, detener la producción de bloques en lugar de intentar una votación coordinada. De forma complementaria, el equipo recomendó rechazar la creación de cuentas de adquisición progresiva en el manejador previo, revisar la corrección tanto en las rutas de código exportadas como en las no exportadas y registrar un contacto de seguridad.

Para ti como titular esto tiene una consecuencia práctica que se pasa por alto con facilidad: una cadena detenida es una señal de alarma sobre el estado del software, pero no es automáticamente una señal sobre el estado de tu cuenta. Si tu saldo fue alterado es una cuestión distinta de si en este momento se están produciendo bloques.

Parche silencioso y recompensa por fallos: qué muestra el caso sobre los procesos de divulgación

El error de programación en sí no se discute entre los implicados. Lo que se debate es el orden en que se hizo público. Un parche silencioso es la práctica habitual de aplicar una corrección de forma discreta para que los atacantes no aprendan del propio aviso dónde deben golpear. Esa práctica solo funciona bajo una condición: los operadores que ejecutan el código deben saber antes que tienen que actuar.

KiiChain formuló este punto con claridad en su propio análisis posterior. Quien publique abiertamente una corrección de seguridad antes de que las cadenas que ejecutan ese código hayan sido informadas en privado y dispuesto de tiempo para actualizar, sostuvo, entrega la vulnerabilidad a cualquiera que lea el commit. Como causas, la cadena señaló la falta de información previa, la omisión del marcado como crítico y el retraso en la comunicación. Es el juicio de valor de una parte afectada, y lo reproducimos como tal.

Cosmos Labs remite en sus propias reglas de recompensas a la puesta en marcha de medidas de emergencia ante un riesgo inmediato o de alcance para toda la red. El análisis posterior describe que en su lugar se eligió la vía estándar prevista para casos sin pérdida de fondos. Cómo se formó esa valoración es la pregunta abierta que plantea el documento y que desde fuera no puede juzgarse de manera concluyente. El desarrollo está acreditado; la valoración sigue siendo asunto de los equipos implicados.

Qué deberían comprobar ahora los titulares de tokens afectados

Si tienes OM, KII, TAC u otro token en una cadena Cosmos EVM, lo primero es tener claridad sobre el estado de las cosas, no reaccionar deprisa en el mercado. Por orden.

Comprueba en primer lugar el estado de la red. Un explorador de bloques público de la cadena correspondiente te muestra si la altura de bloque sigue subiendo o se queda parada en un valor. Si está detenida, la cadena no produce bloques y en ese tiempo no se confirma ninguna transacción.

Comprueba en segundo lugar la versión sobre la que corre tu cadena y si el equipo ha anunciado un reinicio con alguna de las versiones corregidas. Los equipos suelen publicarlo en su página de estado o por sus canales oficiales. Que falte ese dato es, por sí mismo, una información.

Comprueba en tercer lugar, y al margen de lo anterior, si tu plataforma ha reabierto depósitos y retiros para el token afectado. Ambos estados están relacionados pero no son lo mismo, y justo ahí fallan la mayoría de las apreciaciones erróneas. Si quieres mantener tu saldo disponible con independencia de un exchange, el camino pasa por la autocustodia; qué dispositivos entran en consideración lo muestra nuestra comparativa de carteras hardware para criptomonedas.

Tres estados que debes distinguir

El primer estado atañe a la cadena: ¿produce bloques? El segundo atañe a tu saldo: ¿figura aún en tu dirección el importe que esperas? El tercero atañe a la plataforma: ¿puedes depositar y retirar? Una cadena en marcha con la retirada bloqueada en el exchange es una combinación habitual, porque las plataformas deciden por su cuenta, tras un incidente, cuándo reabren su pasarela. A la inversa, una cadena detenida puede llevar saldos inalterados.

Cómo reconocer si una cadena de bloques depende de un componente compartido

Esta pregunta puedes aclararla antes de comprar, y cuesta pocos minutos. El primer indicio es la documentación de la cadena: si allí figura que se asienta sobre un marco de trabajo como el Cosmos SDK y que obtiene la compatibilidad con la EVM mediante un módulo, comparte código con otras redes.

El segundo indicio es el repositorio público de código. Las cadenas de bloques publican por regla general su software de forma abierta, y en los archivos de dependencias consta con nombre qué paquetes ajenos están incorporados y en qué versión. No necesitas saber leer el código; basta con ver el número de versión y compararlo con el recomendado en ese momento.

El tercer indicio es la vía de comunicación. ¿Tiene la cadena una página de estado, un contacto de seguridad y un historial de incidentes anteriores con su correspondiente revisión? El caso actual muestra cuánto depende de ello: once instalaciones del módulo ni siquiera eran conocidas por quien lo publica, lo que significa que tampoco habría podido avisar a sus operadores llegado el caso. La descripción técnica de la brecha puede leerse en el aviso de seguridad GHSA-7g4w-cg88-2cq2, y la contextualización de la cronología en la reconstrucción de The Hacker News.

Impuestos y pruebas: qué documentar tras una parada de cadena

Una parada de red no es, de entrada, un hecho con efectos fiscales. Mientras nada cambie en tu saldo, no surge ni una transmisión ni una pérdida que pudieras hacer valer. La cosa se vuelve relevante solo cuando vendes efectivamente como reacción al incidente o cuando desaparecen tokens de tu dirección.

En la práctica esto significa: asegura ahora los justificantes, mientras estén al alcance. Entre ellos están las capturas de pantalla de tu saldo con fecha y hora, los identificadores de las transacciones afectadas, el aviso de estado de tu exchange sobre la pasarela bloqueada y el comunicado público del equipo de la cadena. Si más tarde deshaces una posición con pérdidas o tienes que explicar ante la administración tributaria por qué un saldo ya no existe, la prueba solo valdrá lo que hayas registrado en el momento del incidente.

Una precisión, porque la pregunta se repite: si un saldo perdido por un exploit es deducible fiscalmente depende del caso concreto y no está resuelto de forma general. Esta apreciación no sustituye al asesoramiento fiscal, y aquí no afirmamos una situación jurídica que no exista como tal.

Comprobar la vulnerabilidad de Cosmos EVM: qué te llevas de todo esto

El caso es menos una historia sobre un fallo aislado que una sobre dependencias comunes y sobre la rapidez con que una información alcanza a sus destinatarios. Tres pasos que puedes deducir de ahí:

1. Comprueba por separado el estado de tu cadena y el de tu exchange. Altura de bloque en el explorador, saldo en tu dirección y estado de la pasarela en la plataforma son tres indicadores que miden cosas distintas. Si al hacerlo adviertes que tu proveedor comunica mal tras los incidentes, el panorama de los exchanges de criptomonedas regulados te ayuda a situarlo.
2. Antes de la próxima compra, mira qué componentes ajenos emplea una cadena. El marco de trabajo, la versión del módulo y un contacto de seguridad registrado dicen más sobre la solidez de una red que sus anuncios. Para la custodia fuera de un exchange encontrarás las opciones en la comparativa de carteras de software.
3. Mantén fuera del poder de disposición ajeno los saldos que no negocias activamente. Una pasarela bloqueada solo afecta a lo que está allí depositado. Qué dispositivos sirven para ello y en qué se diferencian está en la comparativa de carteras hardware.

(29 de agosto de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)