Gnosis Pay: el bug ya estaba parcheado en GitHub

El bug que vació unos 265.000 dólares de Gnosis Pay el 1 de junio de 2026 ya estaba arreglado en el código fuente desde el 27 de febrero. El parche existía, estaba mergeado, era público y verificable en GitHub. Lo que falló no fue la detección del fallo, sino su propagación: el contrato desplegado en la cadena nunca recibió la corrección porque seguía compilado contra una dependencia antigua. Este artículo no es otro parte de hackeo de DeFi. Es un caso de estudio de un patrón estructural que casi nadie audita: el hueco entre «bug corregido en el repositorio» y «bug vivo on-chain». El módulo afectado, el Zodiac Delay Module (un módulo de gobernanza que impone un retardo obligatorio entre que se aprueba una transacción y se puede ejecutar, para dar margen a vetarla), es open-source, está auditado y lo usan decenas de protocolos. Y aun así, el código que protegía los fondos no era el código que corría en la blockchain. Vamos a reconstruir la cronología exacta, a explicar por qué «open-source y auditado» no implica «seguro en producción» y a dejar un checklist accionable para verificar que el contrato desplegado incorpora realmente los últimos parches.

¿Qué pasó exactamente el 1 de junio?

El 1 de junio de 2026, Gnosis Pay —la tarjeta de débito autocustodiada que gasta saldo directamente desde una Safe (wallet de contrato inteligente multifirma) del usuario— detectó un exploit activo contra el Zodiac Delay Module v1.1.0 desplegado en Gnosis Chain. El atacante drenó alrededor de 265.000 dólares repartidos entre varias víctimas antes de que el equipo coordinara con los validadores del bridge para pausar las operaciones y contener el movimiento de fondos.

La mecánica del módulo es, sobre el papel, una capa de protección. Cuando un usuario quiere mover fondos fuera del flujo normal de pago con tarjeta, la transacción se encola y debe esperar un periodo de enfriamiento (cooldown) antes de ejecutarse. Durante ese intervalo, una transacción maliciosa puede marcarse como inválida y vetarse. Es el equivalente a una transferencia bancaria programada que puedes cancelar dentro de una ventana de seguridad. El Delay Module convierte esa ventana en código.

El exploit no rompió la lógica del retardo de forma frontal. Atacó la verificación de firmas. El Delay Module —como buena parte del ecosistema Safe— valida ciertas operaciones mediante el estándar ERC-1271 (el mecanismo por el que un contrato inteligente, y no solo una clave privada, puede «firmar» y autorizar una acción). El fallo permitía que una llamada de contrato que había revertido (es decir, que había fallado) se interpretara igualmente como una firma válida. El atacante controlaba los datos devueltos por esa llamada fallida y, con ellos, fabricaba una autorización que el módulo aceptaba como legítima.

¿Por qué un fallo de 2023 detonó en 2026?

Aquí empieza lo interesante, y donde la cronología deja de ser un parte de incidente para convertirse en un caso de estudio. El bug no nació en junio de 2026. Según la reconstrucción forense de Verichains, la vulnerabilidad se introdujo el 28 de octubre de 2023, en el commit 9a9e380 del código de Zodiac.

Ese commit cambió la forma en que el contrato manejaba un staticcall (una llamada de solo lectura a otro contrato, que no debería modificar estado). En la modificación se descartó el valor success —el booleano que indica si la llamada tuvo éxito o revirtió— y se dejó únicamente la comprobación del «valor mágico» en los datos de retorno. Traducido: el contrato dejó de preguntar «¿esta llamada funcionó?» y pasó a preguntar solo «¿los datos que me devuelves tienen la forma correcta?». Como el atacante controlaba esos datos de retorno incluso en una llamada que revertía, podía construir una respuesta con la forma correcta partiendo de una operación que en realidad había fallado.

Durante dos años y medio, ese fallo estuvo latente. No se explotó porque no era trivial de encontrar y porque requería una combinación concreta de condiciones: una cuenta con el Delay Modifier v1.1.0 (o el Roles Modifier v2) habilitado, junto a una Safe que usara un fallback handler (el contrato que gestiona las llamadas no previstas explícitamente) vulnerable y asignado como módulo o como miembro de rol. Una configuración específica, pero exactamente la que tenía la infraestructura de Gnosis Pay.

¿Qué fue el «parche fantasma» de febrero?

El 27 de febrero de 2026 —tres meses antes del exploit— el equipo de Zodiac corrigió el fallo. El commit de fusión 11708ac en el repositorio gnosisguild/zodiac-core —la pull request #34, «Simplify Base Contracts», parte de la versión v4.0.0-alpha.0— reescribió los contratos base. Entre sus cambios, el sub-commit f06f07b ajustó la validación EIP-1271 «para comprobar el éxito del staticcall»: es decir, volvió a meter la pregunta que el commit de 2023 había eliminado, «¿esta llamada funcionó realmente?».

El parche era correcto. Era público. Estaba en GitHub, mergeado en la rama principal, accesible para cualquiera que quisiera leerlo. Y no sirvió de nada, porque el contrato que custodiaba el dinero de Gnosis Pay nunca lo recibió.

La razón es de fontanería de dependencias, no de criptografía. La línea de código nueva y parcheada vivía en el paquete zodiac-core. Pero las instancias del Delay Module en producción seguían compiladas contra el paquete antiguo, @gnosis.pm/zodiac, una dependencia legacy que nunca recibió el backport del arreglo. El ecosistema se había fragmentado en dos linajes de código: el nuevo, donde el bug estaba muerto, y el viejo, todavía en uso, donde seguía vivo. La pregunta forense que plantea Verichains es exactamente esa: ¿por qué las instancias de Gnosis Pay en producción seguían compiladas contra una dependencia obsoleta cuando existía una línea más nueva que ya había resuelto esta clase de bug?

¿Por qué un fix en el repositorio no es un fix en producción?

Este es el corazón del asunto y la parte que la cobertura más superficial se saltó al titular «Gnosis Pay fue hackeado». Un contrato inteligente no se actualiza solo cuando alguien mergea un pull request en GitHub. El bytecode que corre en la blockchain es una fotografía inmutable del código tal como estaba en el momento del despliegue. Mergear un arreglo upstream no toca ese bytecode. Para que el fix llegue a la cadena, alguien tiene que recompilar contra la versión parcheada y redesplegar el contrato (o, en arquitecturas actualizables, apuntar el proxy a una nueva implementación). Hasta que eso ocurre, el repositorio y la cadena divergen.

La analogía es la de cualquier despliegue de software moderno. Un equipo arregla un fallo de seguridad en una librería y publica una versión nueva. Tu servicio en producción no queda protegido por arte de magia: sigue ejecutando la imagen de contenedor que construiste hace meses, con la versión vieja de la librería empaquetada dentro, hasta que rehaces el build y redespliegas. La diferencia es que en la nube redesplegar es un comando rutinario; on-chain es una operación costosa, a veces irreversible, y que puede requerir gobernanza, migración de usuarios o pausar el sistema. El incentivo a no tocar lo que «funciona» es mucho más fuerte. Y por eso el gap entre repositorio y producción tiende a ensancharse con el tiempo, no a cerrarse.

Hay un agravante de transparencia que casi nadie comenta. Un parche público en un repositorio open-source es, para un atacante atento, un mapa. El commit que arregla un bug describe el bug. Cualquiera que vigile los repositorios de las librerías de seguridad más usadas puede leer un fix, deducir la vulnerabilidad que corrige y comprobar qué contratos en producción siguen sin aplicarlo. La transparencia que hace fiable al open-source es, en la ventana entre el fix y el redespliegue, exactamente la pista que necesita el adversario.

¿En qué se equivoca el modelo mental «open-source y auditado»?

El caso de Gnosis Pay desmonta varias creencias cómodas sobre por qué un sistema cripto «debería» ser seguro. Conviene ponerlas frente a la realidad operativa.

Ninguna de estas creencias es absurda. Todas son razonables como punto de partida. El problema es tratarlas como garantías en lugar de como condiciones necesarias pero insuficientes. «Auditado» reduce el riesgo; no lo elimina, y desde luego no cubre la divergencia posterior entre lo auditado y lo desplegado.

¿Cómo respondieron Gnosis, Zodiac y Safe?

La respuesta al incidente fue, en lo procedimental, rápida y razonablemente transparente. Gnosis pausó el bridge coordinándose con los validadores para frenar la salida de fondos. El cofundador Martin Köppelmann se comprometió a reembolsar íntegramente a los usuarios afectados: «Gnosis cubrirá todas las pérdidas de los usuarios», publicó en X.

El equipo de Zodiac comunicó que había estado trabajando directamente con las cuentas afectadas antes de la divulgación pública y que, para cuando se hizo público el aviso, más del 95 % de las cuentas afectadas identificables ya habían tomado medidas correctivas. Safe Labs, por su parte, se apresuró a aclarar el perímetro del fallo: los contratos inteligentes de Safe, la infraestructura y la interfaz de Safe{Wallet} y la recuperación de cuentas no estaban afectados. La vulnerabilidad estaba aislada en módulos de terceros de Zodiac —el Roles Modifier v2 y el Delay Modifier v1.1.0— y solo se activaba bajo la combinación concreta de condiciones descrita antes.

Esa distinción importa para no sobredimensionar el riesgo sistémico: no era un fallo en el núcleo de Safe, que sostiene una fracción enorme de los activos en contratos inteligentes del ecosistema. Pero tampoco conviene infradimensionarlo: los módulos de Zodiac los usan muchos protocolos para gobernanza y gestión de tesorería, y la lección sobre el linaje de dependencias aplica a todos ellos.

¿Cómo verificar que el contrato desplegado lleva los últimos parches?

El valor accionable de este caso es que el gap repo-versus-producción es auditable. No es una fatalidad invisible. Tanto un protocolo que integra módulos de terceros como un usuario avanzado que confía fondos a un contrato pueden comprobar buena parte de lo que aquí falló. Este es el checklist mínimo.

• Identifica la versión exacta desplegada, no la del repositorio. Lee en el explorador de bloques el código verificado del contrato en producción y anota contra qué versión de la librería está compilado. El número que importa es el del bytecode on-chain, no el del README de GitHub.
• Comprueba el linaje del paquete. Distingue si el contrato depende del paquete activo o de uno legacy. En este caso, la diferencia entre zodiac-core y @gnosis.pm/zodiac fue la diferencia entre estar protegido y no estarlo. Un paquete deprecado puede no recibir backports de seguridad.
• Sigue los commits de seguridad de las librerías que usas, no solo sus releases. Un fix puede llegar en una versión alpha o en un commit aislado meses antes de un release «oficial». Vigila el historial, no únicamente las etiquetas de versión.
• Trata cada parche upstream como una tarea de redespliegue, no como un evento ya resuelto. Mergear no es desplegar. Mantén un inventario de qué contratos en producción dependen de qué librerías y con qué versión, para saber qué hay que redesplegar cuando aparece un fix.
• Cuando aparezca un parche público en una librería que usas, asume que es información pública también para el atacante. La ventana entre el fix y tu redespliegue es una carrera. Priorízala como tal.
• Como usuario, minimiza el saldo en caliente. Si un producto custodia fondos en un contrato con módulos complejos, mantén on-chain solo lo que vas a usar a corto plazo y revisa qué módulos tienes habilitados sobre tu Safe.

Ninguno de estos pasos requiere ser auditor. Requieren tratar el despliegue como parte de la superficie de seguridad, y no solo el código.

¿Qué patrón deja este caso para el resto de DeFi?

El exploit de Gnosis Pay es la cara opuesta de los ataques a la cadena de suministro de software que han marcado 2026. En aquellos, código malicioso se cuela en una dependencia y se propaga hacia producción sin que nadie lo quiera. Aquí ocurrió lo inverso y, en cierto modo, más incómodo: código legítimo y correctivo existía, pero no se propagó. El fallo no fue de los desarrolladores que encontraron y arreglaron el bug. Fue de la cadena que debía llevar ese arreglo desde el repositorio hasta el bytecode que custodiaba el dinero.

La lección estructural es que la seguridad de un sistema cripto no se decide solo en el código ni solo en la auditoría. Se decide también, y quizá sobre todo, en la disciplina de despliegue: en saber qué versión corre en la cadena, contra qué dependencias está compilada y con qué retraso respecto a los parches conocidos. En un ecosistema que presume de transparencia, el dato más opaco suele ser precisamente ese: la distancia entre lo que dice el repositorio y lo que ejecuta el contrato. Quien la mida tendrá una ventaja de seguridad real sobre quien se conforme con el sello de «open-source y auditado».

Fuentes y enlaces: Verichains — post-mortem técnico · GitHub gnosisguild/zodiac-core · The Defiant · CryptoTimes