El fallo de ZetaChain fue reportado por un "white hat", desestimado como "esperado" y luego provocó una explotación de $334K
El fallo de ZetaChain fue reportado por un "white hat", desestimado como "esperado" y luego provocó una explotación de $334K
A finales de abril de 2026, la infraestructura entre cadenas demostró una vez más cómo simples suposiciones de diseño pueden convertirse en un riesgo desmesurado. ZetaChain confirmó que un atacante sustrajo aproximadamente $334,000 de billeteras controladas por el protocolo a través de una serie de debilidades encadenadas que abarcan el inicio de mensajes, las reglas de ejecución en la cadena de destino y las autorizaciones ERC-20 de larga duración. Los fondos de los usuarios no se vieron afectados, pero el incidente sigue siendo un agudo recordatorio: en los sistemas entre cadenas, los componentes de "bajo riesgo" rara vez permanecen de bajo riesgo cuando interactúan.
Lo que hace que este caso sea especialmente instructivo es el fallo del proceso que subyace al fallo técnico. ZetaChain reconoció que el problema central había sido reportado anteriormente a través de su canal de recompensas por errores (bug bounty), pero inicialmente se trató como un comportamiento intencionado en lugar de algo que requiriera mitigación o restricciones más estrictas. La cobertura de la divulgación y los detalles posteriores al incidente se pueden encontrar en informes como el resumen de Cointelegraph sobre el informe desestimado y la posterior explotación: ZetaChain desestimó un informe de error que podría haber evitado la explotación.
A continuación, se presenta un desglose fácil de entender para operarios sobre lo que sucedió, por qué la vía de explotación funcionó, qué cambió ZetaChain y qué deberían aprender los constructores y usuarios en 2026, cuando la actividad entre cadenas es más amplia que nunca y los manuales de los atacantes son cada vez más "multivectoriales por defecto".
Resumen del incidente: la deuda de diseño entre cadenas se vence
Las acciones del atacante resultaron finalmente en 9 transacciones que abarcaron Ethereum, Arbitrum, Base y BNB Smart Chain, con activos robados originándose en billeteras controladas por ZetaChain en lugar de usuarios finales. ZetaChain pausó las operaciones entre cadenas mientras se contenía el problema; la interrupción inicial fue ampliamente reportada cuando el incidente salió a la luz públicamente (ver: Informe de The Block sobre la pausa y mitigación).
Si bien la cantidad en dólares no fue a escala de "mega hack de puentes", el patrón es lo que importa: una pasarela entre cadenas que puede ser influenciada para producir llamadas firmadas por el protocolo en cadenas externas es un objetivo de alta influencia, incluso cuando el conjunto inmediato de víctimas es limitado.
La lección incómoda: "comportamiento esperado" puede ser comportamiento explotable
Los programas de recompensas por errores (bug bounty) están destinados a convertir la curiosidad adversarial en mejora defensiva, pero solo si la clasificación (triage) está diseñada para reconocer el riesgo de composibilidad.
ZetaChain lanzó previamente su programa de recompensas en asociación con Immunefi (antecedentes: Anuncio del programa de recompensas por errores de ZetaChain). Sin embargo, este incidente destaca un desafío recurrente en la industria: un informe puede ser "correcto" incluso si cada componente individual parece no ser crítico de forma aislada. Immunefi enfatiza que el impacto en el mundo real y las definiciones de alcance son importantes (ver: Orientación de Immunefi sobre las reglas del programa y el impacto).
Para los protocolos entre cadenas, el listón debería ser más alto: si una característica permite cualquier camino hacia "el protocolo puede ser engañado para firmar algo que no debería", entonces merece una defensa en profundidad, incluso si la característica funciona técnicamente según lo diseñado.
Cómo tres "pequeños" problemas se encadenaron en una gran explotación
Los investigadores independientes publicaron un análisis técnico detallado del flujo de llamadas y el comportamiento del contrato; uno de los análisis paso a paso más claros es: Análisis del hack del Gateway de ZetaChain.
Desde la perspectiva del diseño de seguridad, la cadena de explotación se puede resumir en tres eslabones:
1) Inicio de instrucciones entre cadenas sin permisos en la capa del gateway
Un problema central fue que se podía invocar una ruta del lado del gateway de una manera que permitía a un atacante inyectar intenciones entre cadenas (es decir, "enviar este mensaje/llamada a la cadena de destino") sin que el sistema impusiera el límite de confianza esperado para quién tiene permitido originar tales instrucciones.
En los sistemas entre cadenas, quién puede emitir una señal de "esto debe ejecutarse de forma remota" es la primera y más importante línea de defensa.
2) Reglas de ejecución de destino demasiado permisivas (y demasiado dependientes de una lista de bloqueo limitada)
En el lado receptor, la vía de ejecución permitió llamadas que eran efectivamente de naturaleza "arbitraria", con restricciones que no eran lo suficientemente amplias como para bloquear operaciones peligrosas de tokens. Una lista negra que solo bloquea un par de selectores rara vez es suficiente cuando la superficie de ataque de EVM es enorme, y cuando los atacantes solo necesitan un primitivo permitido (como transferFrom) para monetizar.
Este es un modo de fallo común: las listas de bloqueo envejecen mal en entornos adversarios.
3) Autorizaciones ERC-20 obsoletas convirtieron la "ejecución" en "movimiento de activos"
El eslabón final fue operativo en lugar de puramente de código: algunas billeteras mantenían aprobaciones ilimitadas (o autorizaciones excesivas) para el contrato del gateway y no las eliminaban después de que ya no fueran necesarias.
En ERC-20, una autorización es efectivamente un permiso permanente. Una vez que un contrato obtiene la capacidad de realizar una llamada de token como propio, cualquier autorización restante se convierte en un arma cargada. Como contexto sobre cómo funcionan las aprobaciones a nivel estándar, consulte: Documentación ERC-20 de OpenZeppelin.
La investigación también ha demostrado cuán extendidas están las aprobaciones ilimitadas y por qué crean riesgo sistémico, mucho más allá de cualquier protocolo individual (ver: Estudio sobre el riesgo de aprobaciones "Penny Wise and Pound Foolish").
Oficio del atacante: no oportunista, sino planeado
ZetaChain describió la explotación como si mostrara claras señales de planificación, incluyendo:
- Pre-financiación a través de Tornado Cash días antes
- Despliegue de un contrato dedicado de "drenaje"
- Ejecución de una campaña de envenenamiento de direcciones
El envenenamiento de direcciones merece especial atención porque se está integrando cada vez más en operaciones de explotación más amplias, no solo como una estafa minorista, sino también como una forma de crear confusión durante la respuesta a incidentes. Si desea una descripción general rigurosa de la técnica y por qué funciona con tanta frecuencia, los investigadores de Carnegie Mellon mantienen un recurso dedicado aquí: Descripción general del envenenamiento de direcciones de blockchain.
Lo que cambió ZetaChain: eliminando "pieguns" (errores fáciles de cometer), no solo corrigiendo fallos
Las correcciones posteriores al incidente importan más cuando reducen el riesgo de clase en lugar de solo bloquear una carga útil observada. Según la dirección de remediación divulgada por ZetaChain (resumida en informes públicos y análisis técnicos), los cambios clave incluyen:
- Despliegue de parches en la infraestructura de mainnet para cerrar la vía de explotación.
- Desactivación permanente de la capacidad de llamada arbitraria que hizo posible el resultado de "ejecutar cualquier calldata que el protocolo firme".
- Reemplazo de los patrones de aprobación ilimitada en los flujos de depósito con aprobaciones de cantidad exacta, para que una sola aprobación no pueda permanecer utilizable silenciosamente meses después.
El tema más importante es el cambio de "generalidad poderosa pero peligrosa" hacia "intención estrecha y verificable". Los protocolos entre cadenas que deseen escalar de manera segura en 2026 necesitarán cada vez más usar por defecto destinos permitidos (allow-listed), mensajes tipificados y ejecución con capacidades limitadas.
Lecciones para constructores: la seguridad entre cadenas en 2026 trata sobre composición, no componentes
Incluso fuera de ZetaChain, los sistemas entre cadenas siguen siendo atacados porque se encuentran en la intersección de:
- Máquinas de estado complejas,
- Firma/validación distribuidas,
- E interfaces de tokens altamente monetizables.
Los informes de pérdidas de la industria continúan mostrando que la gravedad de las explotaciones sigue siendo alta y los eventos de riesgo extremo dominan los resultados (ver un ejemplo de seguimiento agregado de la industria en: Informe de pérdidas de criptomonedas de Immunefi en el primer trimestre de 2025 (PDF)).
Si está diseñando o integrando mensajería entre cadenas, considere estas salvaguardias prácticas:
- Haga que el origen del mensaje sea explícito y autenticado: "Cualquiera puede solicitar una llamada entre cadenas" nunca debe ser equivalente a "el protocolo la firmará y ejecutará".
- Evite las listas de bloqueo para los sumideros de ejecución: prefiera las listas de permitidos y las interfaces mínimas.
- Trate las autorizaciones como parte de su modelo de amenaza: las billeteras del tesoro/operador deben tener políticas de aprobación estrictas, monitoreo y limpieza periódica.
- Planifique la coordinación de emergencia: las redes de respuesta a incidentes como SEAL 911 existen porque los minutos cuentan cuando se trata de firmas y ejecución entre cadenas.
Lista de verificación para usuarios: qué hacer después de cualquier incidente entre cadenas (incluso si "los usuarios no se vieron afectados")
Incluso cuando un protocolo dice que los fondos de los usuarios no se vieron afectados, es razonable tomarse 10 minutos para reducir su radio de explosión personal, especialmente si alguna vez ha interactuado con los contratos del gateway afectados.
1) Revoque las autorizaciones que no necesite activamente
Dos opciones fiables:
- Utilice una herramienta de gestión de autorizaciones como la guía de autorizaciones de tokens de Revoke.cash
- O utilice el comprobador integrado de un explorador de bloques como el Comprobador de Autorizaciones de Tokens de Etherscan
2) Defiéndase contra el envenenamiento de direcciones en el comportamiento diario
- No copie destinatarios del historial de transacciones.
- Utilice agendas de direcciones / contactos de confianza siempre que sea posible.
- Verifique más que los primeros/últimos caracteres: los ataques de envenenamiento están diseñados para coincidir con lo que las interfaces de las billeteras truncan.
3) Utilice la verificación de direcciones basada en hardware para transferencias de alto valor
Una billetera de hardware no puede detener un error de contrato inteligente en un protocolo que no controla, pero puede reducir la posibilidad de que usted autorice personalmente al destinatario incorrecto durante un escenario de envenenamiento de direcciones o de manipulación del portapapeles.
Aquí es donde OneKey encaja de forma natural: al mantener la firma aislada y enfatizar la verificación en el dispositivo, ayuda a que "lo que firma" se acerque a "lo que pretende", especialmente durante momentos de estrés en los que los atacantes intentan explotar la confusión.
Reflexiones finales
La explotación de ZetaChain es un caso de estudio compacto de la realidad de la seguridad de las criptomonedas modernas:
- Un problema previamente reportado,
- Desestimado debido a una suposición de "según diseño",
- Combinado con una ejecución permisiva y autorizaciones sobrantes,
- Ejecutado por un atacante que preparó financiación, herramientas y ruido en la capa social de antemano.
Si 2025-2026 ha enseñado algo a la industria, es que los sistemas entre cadenas deben diseñarse para la composición adversarial. La característica más segura es aquella que no puede convertir accidentalmente en un oráculo de firma, incluso cuando todo está "funcionando según lo esperado".
