Cosmos Labs advirtió sobre una falla crítica en el módulo Cosmos EVM que permitió el robo de fondos en seis blockchains entre el 20 y 25 de agosto. El error, relacionado con el manejo de balances en cuentas de vesting, fue corregido en las versiones v0.6.2 y v0.7.2. Se insta a los operadores a actualizar sus redes inmediatamente o detener la producción de bloques para evitar pérdidas.







Cosmos Labs ha advertido que un fallo crítico en el manejo de saldos en el módulo compartido de Cosmos EVM fue explotado para drenar fondos de seis blockchains entre el 20 y el 25 de agosto de 2026.

La vulnerabilidad, designada 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 < 0.6.2 y >= 0.7.0 < 0.7.2, y la corrección se lanzó en v0.6.2 y v0.7.2 el 19 de agosto. Se indica a los operadores de las cadenas que actualicen a una de esas versiones o posterior, un cambio que rompe el estado y requiere una actualización coordinada de la red.

A los operadores que no puedan actualizar inmediatamente se les indica que detengan la cadena en lugar de intentar una actualización coordinada de gobernanza.

En un análisis post-mortem publicado el 28 de agosto aquí, Cosmos Labs señaló que el fallo fue reportado a través de su programa de recompensas por errores el 25 de abril y que, en aquel momento, se evaluó que no representaba ningún riesgo para los fondos en redes activas.

"No pudimos reproducir la vulnerabilidad en redes de 18 decimales y concluimos incorrectamente que solo afectaba a redes que no tenían 18 decimales", afirmó Cosmos Labs en el post-mortem.

El equipo confirmó el 13 de agosto que todas las cadenas Cosmos EVM estaban afectadas, independientemente de la configuración de decimales. La corrección se gestionó entonces a través del mismo proceso de parche público silencioso que la empresa reserva para problemas que no causan pérdida de fondos en cadenas de producción.

"En este punto, para una vulnerabilidad que se sabe que amenaza los fondos de los usuarios en redes de producción, el equipo normalmente utilizaría canales seguros para distribuir un parche de forma privada a las redes afectadas. Debido a que el parche ya estaba disponible públicamente en la rama principal sin una explotación conocida, el equipo concluyó que sería seguro proceder con el proceso de parche silencioso", explicó Cosmos Labs.

La propia política de parche silencioso publicada por la empresa aquí establece un camino diferente para un fallo de esa clase.

"Cuando un problema presenta un riesgo inmediato o para toda la red, Cosmos Labs iniciará mitigaciones de emergencia, distribución de correcciones privadas o actualizaciones coordinadas antes de que se produzca cualquier divulgación pública", indicó Cosmos Labs en su política de bug bounty, sincronizada por última vez el 27 de julio.

El fallo reside en el código que concilia el estado de la Máquina Virtual de Ethereum (EVM) con el módulo x/bank del SDK de Cosmos. El StateDB de la EVM solo rastrea el saldo gastable de una cuenta, mientras que las cuentas de vesting en el estado del SDK mantienen tanto un saldo gastable como uno bloqueado, y tanto x/staking como el precompile de staking permiten que la parte bloqueada sea delegada.

Cuando una cuenta de vesting delega más de su saldo gastable, el proceso de escritura posterior a la delegación resta el monto total delegado de la cifra gastable menor. La resta no se verifica y el saldo se desborda (wrap) hasta aproximadamente 2^256.

La conciliación entonces acuña (mint) sobre un delta positivo y quema (burn) sobre uno negativo. El atacante puede mover una cantidad finita fuera de la cuenta desbordada, o enviar a una cuenta víctima 2^256 menos su saldo para que la conciliación queme las tenencias reales de la víctima.

Las cadenas en 0.6.x acuñan y queman en el libro mayor del SDK subyacente, por lo que un acuñado masivo causa un desbordamiento de suministro que detiene la cadena. Las cadenas que ejecutan 0.7.x establecen los saldos directamente en x/bank y aceptan cambios que sobreviven a una conversión de uint256 a int256.

Ambas mitades se ejecutan dentro de una sola transacción con un cambio neto de suministro de cero, desde un contrato desplegado en una dirección precomputada que primero se convirtió en una cuenta de vesting. La explotación requiere que la cadena permita la creación de cuentas de vesting sin permisos.

Pasos recomendados para operadores

A los operadores que ejecutan Cosmos EVM se les aconseja 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 ya que el cambio rompe el estado.
* Detener en lugar de votar. A las cadenas que no puedan actualizarse a la vez se les indica que detengan la producción de bloques en lugar de ejecutar una actualización coordinada de gobernanza. El aviso indica que no hay mitigación solo de configuración, y que deshabilitar el precompile de staking elimina la ruta de activación principal pero no sustituye al parche.
* Cerrar la precondición. Rechazar MsgCreateVestingAccount, MsgCreatePermanentLockedAccount y MsgCreatePeriodicVestingAccount en el ante handler. Las cuentas de vesting definidas en el génesis no se ven afectadas.
* Verificar la ruta de código en vivo en un fork. Un cherry-pick que solo parchee el asistente exportado puede dejar una copia no exportada duplicada en su lugar mientras todas las pruebas siguen pasando.
* Aplicar las dos correcciones que el aviso omite. La instantánea del saldo bloqueado y el guardián de la cuenta del módulo son cambios separados, y el guardián de la cuenta del módulo rechaza las cuentas de módulo incondicionalmente, lo que rompe las llamadas de EVM realizadas desde una cuenta de módulo.
* Registrar un contacto de seguridad con Cosmos Labs, ya que se enteraron de once despliegues de Cosmos EVM durante el incidente que nunca se habían registrado en sus canales de seguridad.

El aviso documenta un cambio upstream aquí, el guardián de underflow de SubBalance fusionado a la rama principal el 15 de mayo como pull request #1176 aquí y retroportado el 13 de agosto. Dos correcciones de saldo adicionales se encuentran en el mismo repositorio y no se mencionan en ninguna parte.

El pull request #1187 aquí, fusionado el 20 de mayo, realiza una instantánea del saldo bloqueado de una cuenta para que el saldo del banco se reconstruya correctamente después de que un precompile lo cambie. Los retroports de #1187 a ambas líneas de lanzamiento se abrieron el mismo día y se fusionaron en veinticuatro horas, mientras que el retroport de #1176, un cambio igualmente disruptivo para el estado, llegó unos noventa días después.

El commit 3524ebc aquí, titulado "Merge commit from fork", rechaza cualquier intento de establecer el saldo de una cuenta de módulo.

morde08, colaborador de ZetaChain, señaló en un port de las tres correcciones aquí publicado el 21 de agosto, que el parche cherry-picked dejó la ruta en vivo del fork sin parchear, porque el fork tenía asistentes no exportados duplicados mientras que el cambio upstream solo afectó al exportado.

Warden Protocol tomó la otra ruta dos días después y bloqueó por completo la creación de cuentas de vesting.

"Las cuentas de vesting son la única fuente de saldos bloqueados en Warden y nada depende de que los usuarios puedan crearlas, por lo que eliminar esa ruta cierra la precondición en lugar de confiar en que la reconstrucción sea correcta", dijo el colaborador de Warden Protocol jlehtimaki en un mensaje de commit.

Un pull request público en el fork de Push Chain de Cosmos EVM describió la vulnerabilidad y su ruta de explotación en detalle a las 07:16 UTC del 20 de agosto, ocho horas y quince minutos después de que salieran los lanzamientos.

El primer ataque, contra MANTRA, comenzó once horas y cincuenta minutos después, a las 19:06 UTC. Cosmos Labs envió su primera notificación privada por correo electrónico seguro a las 03:36 UTC del 21 de agosto, aproximadamente dos horas después de que MANTRA reportara que había sido explotada.

"Cosmos Labs ha lanzado parches para 37 vulnerabilidades silenciosamente en los últimos 13 meses sin que los desarrolladores downstream describieran precisamente las rutas de explotación en público", afirmó Cosmos Labs en el post-mortem.

Las notas de lanzamiento de v0.6.2 aquí y v0.7.2 aquí indican que la versión contiene correcciones de seguridad importantes y debe aplicarse lo antes posible, y ambas omiten el retroport de seguridad en sus registros de cambios. The Hacker News confirmó el 29 de agosto que ninguna de las dos versiones enumera los pull requests que lo contienen.

Cosmos Labs dijo que tiene conocimiento de seis cadenas en las que se aprovechó el exploit.

Los atacantes vendieron aproximadamente 2.87 millones de USD en activos afectados en exchanges descentralizados basados en los precios del 19 de agosto, una cifra que la empresa dijo que fue proporcionada por las cadenas afectadas y no ha sido auditada independientemente. Otros 2.85 millones de USD fueron vendidos en exchanges centralizados, una estimación de Cosmos Labs basada en datos de volumen disponibles públicamente.

El ecosistema de Cosmos abarca más de 115 blockchains públicas conocidas, y la empresa dijo que no posee un registro completo de las redes que ejecutan su software, el mismo vacío que dejó que los proveedores downstream tuvieran que parchear fallos de sistemas de archivos empaquetados en julio.

The Hacker News ha contactado a Cosmos Labs para que comente por qué el parche no se distribuyó de forma privada después de que el equipo confirmara que todas las cadenas estaban afectadas, y actualizará esta historia con cualquier respuesta.

Fuente:
THN