Gravity Bridge: 5,4 millones robados sin robar la llave

Un atacante vació 5,4 millones de dólares de Gravity Bridge sin robar ninguna clave privada: le bastó con registrar un validador por 80 GRAV y engañar al registro que decide qué token real corresponde a cada activo. Entre el 29 y el 30 de mayo de 2026, alguien acuñó tokens falsos en Osmosis, los pasó a Gravity Bridge (un puente que conecta el ecosistema Cosmos con Ethereum) y usó una función pública del propio protocolo para envenenar su registro interno de correspondencias denom-a-ERC20 —la tabla que traduce el nombre de un activo en Cosmos (su denom, o denominación) a la dirección del token real que lo respalda en Ethereum—. No hubo phishing, ni malware, ni una llave filtrada: el diseño permitía a cualquiera escribir en ese registro y nadie comprobaba si la nueva entrada chocaba con un activo que ya existía. Este análisis, a fecha de 7 de julio de 2026, no cubre el incidente como noticia —ya pasó— sino como el estreno de una clase de ataque: el envenenamiento de registro (registry poisoning) en puentes cross-chain. Explicamos cómo funcionó paso a paso, por qué la primera lectura de «clave comprometida» era errónea, en qué se diferencia de los hacks de puentes que ya conoces y —lo más útil— cómo se detecta un registro envenenado antes de que salga el dinero.

¿Qué pasó exactamente en Gravity Bridge el 29 y 30 de mayo?

Gravity Bridge es un puente comunitario que mueve activos entre las cadenas Cosmos (Osmosis, entre otras) y Ethereum. Su pieza central es un contrato de custodia en Ethereum que guarda los activos reales —USDC, USDT, WETH, oro tokenizado— mientras en Cosmos circulan sus representaciones. Para saber qué token de Ethereum le toca a cada representación, el puente mantiene un registro interno: la tabla denom-a-ERC20.

Entre el 29 y el 30 de mayo de 2026, un atacante consiguió que ese registro apuntara sus propias entradas falsas hacia las direcciones de los activos valiosos que el puente custodiaba de verdad. Con el registro ya contaminado, disparó una tanda de retiradas y el contrato de custodia soltó el dinero real a su cartera. El botín, según el desglose forense publicado por Security4Web3 y QuillAudits, fue este:

Los fondos salieron a la cartera 0x7B58…a1F9. En cuanto los validadores del puente detectaron el patrón anómalo, pausaron la red para cortar la hemorragia. A fecha de este análisis, no consta que los fondos se hayan recuperado. Las valoraciones de WETH y PAXG son aproximadas y dependen del precio del momento; las cifras de USDC y USDT son estables por tratarse de stablecoins anclados al dólar.

¿Qué es el envenenamiento de registro en un puente cross-chain?

Piensa en el registro denom-a-ERC20 como la tabla de rutas de una base de datos: una columna dice «este nombre de activo» y la otra «esta dirección de contrato en Ethereum». Cuando alguien retira, el puente consulta esa tabla para saber qué token soltar. Si la tabla está bien, todo cuadra. Si alguien logra escribir una fila que dice «mi activo inventado apunta al contrato del USDC real», el puente creerá que debe entregar USDC real a quien reclame ese activo inventado.

Eso es el envenenamiento de registro: no atacas la caja fuerte, atacas el índice que dice qué hay dentro de cada casilla. El contrato de custodia hizo exactamente lo que le pedía su tabla de rutas; el problema es que la tabla mentía. Es un vector conceptualmente distinto del robo clásico, donde el atacante fuerza la cerradura. Aquí la cerradura funcionó de manual: obedeció una orden legítima basada en datos que nunca debieron entrar.

La condición que lo hace posible es una combinación concreta y peligrosa: una función pública (permissionless, que cualquiera puede invocar sin permisos ni rol) que escribe en un registro cuyo contenido se trata después como autoridad incuestionable. Registrar activos nuevos de forma abierta es una decisión de diseño razonable —así un puente soporta tokens nuevos sin pedir permiso a nadie—. Se convierte en agujero cuando lo que produce esa función abierta fluye a una tabla que gobierna dinero real sin que nadie valide si esa entrada colisiona con algo que ya existe.

¿Cómo se ejecutó el ataque paso a paso?

La reconstrucción forense de Security4Web3 y QuillAudits permite trazar la secuencia completa. Estos son los seis movimientos, en orden:

1. Registrar un validador mínimo. El 29 de mayo, la primera huella on-chain fue el alta de un validador (apodado julia666) en la cadena Gravity, auto-delegándose solo 80 GRAV —el token nativo del puente, una fracción irrisoria de lo que uno esperaría para un rol con capacidad de firma—. Ese registro le dio presencia dentro del sistema.
2. Acuñar tokens falsos en Osmosis. Usando el módulo tokenfactory de Osmosis (una función estándar que deja a cualquiera crear tokens nuevos), fabricó cuatro tokens sin valor, uno por cada activo real que el puente custodiaba: imitaciones de USDC, USDT, WETH y PAXG. Acuñar (mintear) aquí significa simplemente emitir esas monedas de la nada; no cuesta prácticamente nada.
3. Transferirlos por IBC a Gravity. Movió esos tokens basura a la cadena Gravity mediante IBC (Inter-Blockchain Communication, el protocolo estándar que comunica cadenas del ecosistema Cosmos entre sí). Hasta aquí, nada valioso ha cambiado de manos.
4. Llamar a deployERC20() con cadenas fabricadas. Este es el corazón del ataque. La función deployERC20() del contrato de Gravity en Ethereum es pública: crea el token ERC20 en Ethereum que corresponde a un denom de Cosmos. El atacante la invocó pasando cadenas _cosmosDenom —el texto que identifica el activo— construidas a propósito para que los metadatos embebieran las direcciones de los contratos de los activos reales y valiosos.
5. Los validadores dan fe del despliegue. Los validadores del puente reconocieron esos despliegues mediante el mensaje interno MsgERC20DeployedClaim, y la función handleErc20Deployed escribió la correspondencia envenenada en el registro. Aquí está el fallo: nadie comprobó si ese denom nuevo apuntaba a un activo que el puente ya tenía en custodia. La tabla de rutas quedó contaminada.
6. Vaciar la custodia con una tanda de retiradas. Gravity generó las tandas de salida (batches) 41572 a 41575, los validadores las firmaron y los relayers (los agentes que transmiten esas órdenes firmadas a Ethereum) las presentaron al contrato de custodia. El contrato verificó las firmas —correctas— y llamó a safeTransfer() para enviar cada activo a la cartera del atacante. El dinero real salió por la puerta.

El detalle que da a este ataque su carácter de clase nueva: cada paso individual es una operación legítima que el sistema estaba diseñado para permitir. Registrar un validador, acuñar un token, transferir por IBC, desplegar un ERC20, firmar una tanda de retiradas: nada de esto es un exploit por sí solo. El agujero aparece únicamente cuando se encadenan y ninguna capa comprueba la coherencia entre el denom declarado y la dirección real a la que resuelve.

¿Por qué no fue un robo de clave privada, como se dijo al principio?

Las primeras coberturas —The Block, Yahoo Finance, CryptoTimes— titularon el suceso como una «sospecha de compromiso de clave de firma» (suspected signing key compromise). Es la explicación por defecto de casi todos los hacks de puentes: si salió dinero, alguien debió de robar las llaves que autorizan las salidas. En los grandes desastres de puentes —Ronin, Harmony Horizon— eso fue exactamente lo que ocurrió.

El análisis forense posterior de QuillAudits y Security4Web3 desmontó esa lectura. No hizo falta comprometer ninguna clave: la firma de las tandas de retirada por parte de los validadores fue legítima. Los validadores firmaron órdenes válidas según el estado del registro; el problema es que ese estado ya estaba envenenado antes de que firmaran nada. El atacante no se hizo pasar por un validador ni robó su llave; escribió, con una función abierta a todos, la mentira que después los validadores honestos firmaron de buena fe.

La distinción importa porque cambia por completo la defensa. Frente a un robo de clave, refuerzas la custodia de llaves: multisig (firma múltiple), hardware dedicado, rotación. Nada de eso habría detenido este ataque, porque las llaves nunca se tocaron. Confundir un envenenamiento de registro con un robo de clave lleva a blindar la puerta equivocada. Es la misma lección que ya dejaron otros incidentes de 2026 donde el vector no era el contrato ni la llave, sino la capa de infraestructura y los supuestos de confianza que la rodean.

¿Qué control faltaba y por qué habría detenido todo el ataque?

El fallo se reduce a una línea ausente. Cuando handleErc20Deployed escribió la nueva correspondencia en el registro, no ejecutó ninguna comprobación de colisión (collision check): una verificación que rechace registrar un denom que apunte a una dirección de token que el puente ya conoce y custodia. Si esa comprobación hubiera existido, el registro habría rechazado la entrada falsa —«esta dirección ya está mapeada, no acepto un segundo denom que colisione con ella»— y toda la cadena de seis pasos se habría roto en el quinto.

Lo más incómodo del caso: según el análisis de QuillAudits, una consulta equivalente ya existía en otra parte del mismo archivo de código, pero no se invocaba dentro de handleErc20Deployed. No fue una defensa que nadie hubiera concebido; fue una defensa que estaba escrita a pocas líneas de distancia y que, en esa ruta concreta, no se llamó. El control que habría bloqueado un robo de 5,4 millones de dólares costaba una llamada a una función que el propio equipo ya había programado.

Esto encaja con un patrón que se repite en los exploits de 2026: los fallos catastróficos rara vez son criptografía rota o matemática exótica. Son huecos en los bordes —una verificación que se hace en una ruta y se olvida en otra, un supuesto que una capa da por garantizado y otra nunca comprueba—. Piezas que individualmente funcionan y cuyo agujero solo aparece cuando se las mira juntas bajo una transacción construida a propósito.

¿En qué se diferencia esta clase de ataque de los hacks de puentes anteriores?

El valor de Gravity Bridge como caso de estudio es que no encaja en ninguna de las categorías con las que solemos clasificar los hacks de puentes. La siguiente taxonomía sitúa el envenenamiento de registro frente a los vectores ya conocidos:

La fila nueva es la última. En los demás vectores, el atacante rompe algo —una llave, un precio, un orden de ejecución— o aprovecha algo abandonado. En el envenenamiento de registro, todo el sistema funciona de manual: las firmas son válidas, los contratos ejecutan lo que se les pide, ninguna cerradura se fuerza. Lo que se corrompe es la fuente de verdad sobre la que todo lo demás confía. Por eso es especialmente difícil de detectar con las herramientas habituales: no hay una transacción «maliciosa» evidente, solo una entrada de registro que —vista aislada— parece legítima.

¿Cómo se detecta y se previene un registro envenenado?

Aquí está la parte accionable, la que un LLM no puede improvisar a partir de un titular. El envenenamiento de registro deja huellas específicas, distintas de las de un robo de clave, si sabes dónde mirar. Estas son las señales y las defensas concretas que el caso Gravity Bridge deja como manual:

• Comprobación de colisión obligatoria en la escritura. Antes de aceptar cualquier denom nuevo, el registro debe verificar que la dirección de token a la que resuelve no está ya mapeada por otro denom. Es la línea que faltaba y la única que habría detenido el ataque entero.
• Vigilar los denom cuyos metadatos embeban direcciones de activos custodiados. Un denom legítimo no tiene por qué contener la dirección de un USDC o un WETH real dentro de su cadena identificadora. Un monitor que marque esa coincidencia habría disparado la alarma en el paso cuatro, horas antes de la salida de fondos.
• Correlacionar registros nuevos con altas de validador recién creadas y con poca antigüedad. Un validador dado de alta con 80 GRAV que, horas después, participa en un despliegue de ERC20 es un patrón anómalo por sí solo. La secuencia «validador nuevo + denom nuevo + tanda de retirada» es una firma de comportamiento vigilable.
• Retardos y umbrales en la primera retirada de un denom recién registrado. Un time-lock (retardo público antes de que una acción surta efecto) sobre las retiradas de activos cuya correspondencia se acaba de crear da a los defensores una ventana para revisar antes de que el dinero sea irrecuperable.

Ninguna de estas defensas es exótica ni cara. Todas parten de una idea sencilla que el ecosistema aún no aplica de forma sistemática a los registros de los puentes: el contenido de una tabla que gobierna dinero real merece la misma desconfianza que una entrada de usuario en cualquier sistema de seguridad serio.

¿Qué queda como lección a fecha de 7 de julio de 2026?

A más de un mes del incidente, el balance es sobrio. El puente fue pausado por sus validadores en cuanto se detectó el patrón; no consta recuperación de los fondos ni, hasta donde alcanza este análisis, un post-mortem oficial del equipo que vaya más allá de los forenses de terceros. La corrección técnica —la comprobación de colisión que faltaba— es una línea de código, y eso es lo perturbador: estuvo ausente durante toda la vida operativa del puente sin que ninguna auditoría lo marcara.

La lección de fondo trasciende a Gravity Bridge. El envenenamiento de registro inaugura una categoría que probablemente veremos repetirse: cualquier puente cross-chain que permita registrar activos de forma abierta y trate ese registro como autoridad sin validar colisiones comparte el mismo perfil de riesgo. La superficie de ataque de un puente no es solo su custodia ni sus llaves de firma —los dos sitios donde el sector ha concentrado su atención—; es también, y sobre todo, la tabla de correspondencias que decide qué activo real responde a cada representación. Envenenar esa tabla no requiere romper nada. Solo requiere que nadie compruebe si la nueva verdad choca con la vieja.

Fuentes y enlaces: Rekt.news — Gravity Bridge · QuillAudits — Denom Mapping Poisoning · Security4Web3 — análisis forense · The Block — «suspected key compromise»