Cosmos Labs subestimó el fallo antes del exploit de $5.72 millones en seis cadenas
Puntos clave
- •El Cosmos Hub en sí no fue hackeado; el fallo estaba en el software cosmos/evm utilizado por seis redes, incluidas MANTRA, TAC y KiiChain.
- •Los atacantes convirtieron o vendieron aproximadamente $5.72 millones, con unos $2.85 millones pasando por exchanges centralizados cuyas cuentas fueron posteriormente congeladas.
- •La vulnerabilidad fue un subdesbordamiento de enteros causado por restar montos delegados, incluidos tokens bloqueados, de un saldo disponible más pequeño, lo que permitió el robo directo de fondos de las víctimas.
- •Cosmos Labs inicialmente juzgó mal el fallo como limitado tras no poder reproducirlo en cadenas de 18 decimales, y sus parches silenciosos posteriores carecían de notas que indicaran que retrasar las actualizaciones arriesgaba fondos de usuarios.
- •Cosmos Labs planea ampliar la evaluación de vulnerabilidades, expandir y verificar su red de contactos de seguridad, y someterse a una auditoría externa de sus prácticas de seguridad operativa.

El Cosmos Hub no fue hackeado
El incidente no comprometió el Cosmos Hub, ni a todas las blockchains del amplio ecosistema Cosmos. El fallo estaba en cosmos/evm, un software compartido que permite a redes independientes basadas en Cosmos ejecutar aplicaciones compatibles con Ethereum.
Según el análisis posterior al incidente de Cosmos Labs, seis redes que utilizaban ese software fueron explotadas entre el 20 y el 25 de agosto. MANTRA, TAC y KiiChain fueron mencionadas en la línea de tiempo detallada; el documento no identificó públicamente a las otras tres.
Esa distinción importa: evita que un fallo de software compartido se convierta en un titular engañoso de "hackeo a Cosmos". La misma regla de alcance se aplicó al exploit del puente de The Sandbox — una integración comprometida no significaba que todo el protocolo subyacente hubiera sido hackeado.
Los atacantes convirtieron $5.72 millones por dos vías
Cosmos Labs estimó que los atacantes intercambiaron aproximadamente $2.87 millones en plataformas descentralizadas, según los precios del 19 de agosto. Describió esa cifra como una estimación que no había sido auditada de forma independiente. Otros $2.85 millones fueron presuntamente vendidos a través de exchanges centralizados, lo que eleva el total convertido o vendido a unos $5.72 millones.
Cosmos Labs dijo que las cadenas afectadas informaron que las cuentas en los exchanges centralizados habían sido congeladas mientras continuaban las investigaciones policiales. El total convertido de $5.72 millones no cambiará, pero la recuperación de los saldos congelados en exchanges podría reducir la pérdida neta final.
La respuesta también limitó el daño. Cosmos Labs trabajó con otras 13 redes potencialmente expuestas para parchearlas, detenerlas o protegerlas de otra forma sin incidentes adicionales reportados, y coordinó con 40 cadenas en total.
Cómo una discrepancia contable expuso saldos válidos
La vulnerabilidad se originó en dos partes del software que calculaban los saldos de manera diferente. El StateDB de Cosmos EVM registraba únicamente el monto que una cuenta podía gastar de inmediato. Sin embargo, una cuenta de vesting de Cosmos podía contener tanto tokens disponibles como bloqueados, y el sistema de staking permitía delegar los tokens bloqueados.
Cuando el software restaba el monto total delegado del saldo disponible más pequeño, un subdesbordamiento aritmético sin verificación podía envolver el resultado en un número cercano a 2^256. Un atacante podía luego combinar ese subdesbordamiento con un desbordamiento durante una transferencia. Esta clase de fallo — subdesbordamiento y desbordamiento de enteros en aritmética sin signo — es una categoría bien documentada de vulnerabilidad en contratos inteligentes y blockchains, y es una razón por la que los lenguajes modernos de contratos inteligentes incluyen aritmética verificada por defecto.
La secuencia no creó un aumento duradero en la oferta. En cambio, podía reducir a cero la cuenta de una víctima con saldo alto y dejar al atacante con el saldo que esa cuenta tenía previamente. Eso convertía al fallo en un riesgo directo de robo de fondos, no meramente en una visualización inexacta o una anomalía contable.
La advertencia llegó casi cuatro meses antes de los ataques
El robo fue el final de una secuencia más larga. El error decisivo ocurrió durante la evaluación inicial, meses antes de que alguien explotara el código.
Cosmos Labs trató una amenaza de producción como mantenimiento rutinario
La prueba de concepto original usaba una cadena configurada con seis decimales. Cosmos Labs probó configuraciones de 18 decimales, no pudo reproducir el resultado y concluyó que las redes de producción conocidas estaban seguras. Esa conclusión era errónea: la discrepancia subyacente de saldos podía afectar a cada cadena Cosmos EVM, independientemente de su configuración decimal.
Una vez que reportes posteriores establecieron el alcance mayor, Cosmos Labs supo que los fondos de producción estaban expuestos. Optó por un proceso de parcheo silencioso destinado a poner el código corregido en manos de los operadores sin publicar detalles que pudieran ayudar a los atacantes.
Las versiones estuvieron disponibles unas 20 horas antes del primer ataque conocido, pero sus notas no indicaron la gravedad ni advirtieron a los operadores que retrasar la actualización podía exponer los fondos de los usuarios. Los operadores podían ver que las nuevas versiones contenían correcciones de seguridad, pero las notas no explicaban que las cadenas sin parchear enfrentaban una posible pérdida de fondos.
La divulgación se hizo pública la mañana siguiente. Un pull request en un fork descendiente describió la ruta del exploit e identificó las etiquetas de versión afectadas aproximadamente 12 horas antes del primer ataque. El pull request público les dio a los atacantes una ruta más clara, y Cosmos Labs ya había dejado a los operadores sin una advertencia que explicara la urgencia.
El dilema que enfrentó Cosmos Labs es conocido en la seguridad de código abierto: divulgar completamente una vulnerabilidad puede armar a los atacantes antes de que todos los operadores hayan parcheado, mientras que guardar silencio puede dejar a los operadores sin capacidad de evaluar la urgencia. Las prácticas de divulgación coordinada en la industria del software intentan equilibrar precisamente esta disyuntiva, y este incidente muestra qué sucede cuando el equilibrio falla en ambos sentidos.
Cosmos no conocía todas las cadenas que debían ser advertidas
Incluso un proceso de advertencia privado solo funciona si los mantenedores saben a quién contactar. Cosmos Labs dijo que el ecosistema incluye más de 115 cadenas públicas conocidas, pero carece de un registro completo. Durante la respuesta, se enteró de 11 despliegues de Cosmos EVM que no estaban registrados en sus canales de seguridad.
Cosmos Labs mantenía el código compartido sin conocer todas las redes que lo habían desplegado. Esa brecha dificultó entregar una advertencia confidencial antes de publicar suficiente información para que los equipos de las cadenas reconocieran la amenaza por sí mismos.
La línea de tiempo de la respuesta también muestra por qué el mensaje debía ser explícito. Después de que MANTRA reportó el primer ataque, Cosmos Labs envió su primer correo crítico de seguridad unas dos horas después. TAC fue atacada aproximadamente 45 horas después de MANTRA a pesar de la comunicación previa, y la guía luego se escaló hasta aconsejar que todas las cadenas Cosmos EVM se detuvieran.
Para las cadenas Cosmos EVM independientes, publicar el código fue insuficiente. Sus equipos aún tenían que enterarse de que la actualización era urgente y coordinar una versión con cambios de estado.
Las cadenas vulnerables deben actualizar o detenerse
El aviso de seguridad crítico enumera como afectadas las versiones anteriores a 0.6.2 y las versiones desde 0.7.0 hasta, sin incluir, 0.7.2. Los operadores deberían migrar a Cosmos EVM 0.6.2, 0.7.2 o una versión posterior.
No existe una solución alternativa basada solo en configuración. Deshabilitar el precompilado de staking elimina el desencadenante principal descrito en el aviso, pero Cosmos Labs no considera ese paso un sustituto de la actualización. Una cadena que no pueda instalar de inmediato una versión parcheada debería detenerse.
BTCPay emitió recientemente instrucciones igualmente específicas por versión tras confirmar fondos robados: actualizar las instalaciones afectadas o desconectarlas. En ambos casos, la guía útil es concreta porque el riesgo depende de la versión del software en uso.
La próxima corrección es el proceso de divulgación
Cosmos Labs dijo que ampliará la evaluación de vulnerabilidades más allá de la prueba de concepto del reportante, expandirá su red de contactos de seguridad y verificará que esos contactos sigan respondiendo. También planea estándares más claros para parches privados y silenciosos, incluido cuándo los mantenedores deberían recomendar una detención en lugar de una actualización coordinada. También está previsto un auditoría externa de sus prácticas de seguridad operativa.
Esos cambios abordan la parte del incidente que otro parche de código no puede resolver: cómo un grupo descentralizado de cadenas independientes recibe, entiende y actúa ante una advertencia sensible al tiempo. La primera evaluación redujo el alcance del fallo demasiado rápido. El proceso de publicación posterior ocultó la urgencia a algunas de las personas que debían instalar la corrección. El código estaba disponible antes del primer ataque. Lo que a varios operadores les faltó fue una advertencia de que esperar podía costar fondos a los usuarios.
El artículo tiene fines informativos únicamente y no constituye asesoramiento financiero, de inversión o de seguridad. Los operadores de redes deben consultar el aviso oficial de Cosmos EVM y verificar su versión desplegada.
Fuente: Coindoo