El incidente de seguridad de Binance ha llamado la atención no solo por la escala de la actividad sospechosa de la billetera, sino también por un detalle técnico visible poco antes de que los principales activos de Ethereum comenzaran a moverse: un lote de autorizaciones EIP-7702.
Ese detalle rápidamente empujó a EIP-7702 al centro de la discusión. El mecanismo de delegación de cuentas de Ethereum permite que una cuenta de propiedad externa normal, o EOA, ejecute temporalmente lógica de contrato inteligente. En el incidente de Binance, los investigadores de blockchain identificaron una delegación EIP-7702 poco antes de que los activos fueran transferidos desde una billetera caliente vinculada a Binance.
Pero hay una distinción importante.
La presencia de una autorización EIP-7702 no prueba por sí misma que EIP-7702 haya sido explotado.
La investigación inicial de Binance, en cambio, apunta hacia un compromiso de la infraestructura operativa. El exchange dijo que la laptop de un ingeniero de DevOps podría haber sido comprometida, permitiendo a un atacante acceder a un contenedor de servicio y enviar transacciones de retiro no autorizadas. Binance también dijo que no había encontrado evidencia de que las claves privadas de la billetera se hayan filtrado.
Eso hace que el incidente sea particularmente importante para comprender la seguridad moderna de las billeteras. Una clave privada puede permanecer dentro de una infraestructura protegida mientras un atacante abusa de otro sistema que tiene permiso para solicitar firmas legítimas.
Este artículo explica qué parece haber hecho EIP-7702 en el incidente, por qué los informes de múltiples autorizaciones atrajeron atención, y por qué importa la diferencia entre el robo de claves y el compromiso de la infraestructura de firma.
¿Qué ocurrió en el incidente de seguridad de Binance?
La actividad sospechosa que involucra billeteras calientes vinculadas a Binance comenzó a atraer atención el 30 de octubre de 2026.
Los investigadores on-chain observaron grandes transferencias desde billeteras asociadas con el exchange hacia direcciones recién creadas. Las estimaciones iniciales variaron considerablemente mientras los investigadores rastreaban transacciones en Ethereum, Bitcoin, Tron y otras redes.
Binance posteriormente reconoció un incidente de seguridad y comenzó a investigar el origen de las transacciones no autorizadas. El exchange suspendió temporalmente los depósitos y retiros mientras realizaba controles de seguridad.
En su actualización de seguridad del 30 de octubre, Binance dijo que su investigación inicial sugería que la laptop comprometida de un ingeniero de DevOps permitió a un atacante obtener acceso a un contenedor de servicio y enviar transacciones de retiro no autorizadas.
El exchange estimó el impacto general en aproximadamente 6.300 millones de dólares en esa etapa de la investigación y dijo que alrededor de 3.000 millones de dólares de los activos afectados habían sido congelados on-chain. Binance también declaró que cubriría las pérdidas utilizando su fondo SAFU y fondos de la empresa.
Lo más importante para la discusión técnica, Binance dijo:
No había encontrado evidencia de una filtración de clave privada de billetera.
Esa declaración cambia cómo debe interpretarse la actividad EIP-7702 reportada.
En lugar de preguntar solo si un atacante robó una clave privada de billetera caliente, la pregunta más relevante pasa a ser si un sistema interno comprometido pudo solicitar o facilitar una autorización válida desde la infraestructura de firma protegida.
¿Por qué EIP-7702 se convirtió en parte de la investigación?
EIP-7702 se introdujo con la actualización Pectra de Ethereum para dar a las cuentas de propiedad externa algunas de las capacidades normalmente asociadas con las billeteras de contrato inteligente.
Tradicionalmente, una EOA de Ethereum está controlada por una clave privada. Puede firmar transacciones, transferir activos e interactuar con contratos inteligentes, pero su propia cuenta no contiene lógica de ejecución programable.
EIP-7702 cambia esa relación.
Permite que una EOA autorice el código de otro contrato para que actúe como su lógica de ejecución mientras preserva la dirección original de Ethereum.
Esto habilita características útiles de abstracción de cuentas, como el agrupamiento de transacciones, el patrocinio de gas y sistemas de permisos más avanzados.
También significa que una autorización EIP-7702 merece sustancialmente más atención que una aprobación de token convencional.
Durante el análisis del incidente de Binance, los investigadores informaron que una dirección financiada a través de Tornado Cash envió múltiples autorizaciones EIP-7702 que involucraban una billetera caliente de Ethereum vinculada a Binance poco antes de que ocurrieran las principales transferencias de activos.
Según los informes, una autorización coincidió con el estado de la billetera y se volvió efectiva.
Aproximadamente tres minutos después, activos significativos comenzaron a salir de la billetera.
El momento hizo naturalmente que la autorización fuera una parte importante de la investigación.
Todavía no nos dice cómo se obtuvo la autorización válida.
¿Cómo funciona una autorización EIP-7702?
La forma más sencilla de entender el mecanismo es pensar en EIP-7702 como permitir que una cuenta Ethereum ordinaria diga temporalmente:
"Usa la lógica de ejecución de este contrato inteligente cuando mi cuenta reciba llamadas."
Un flujo simplificado se ve así:
Ethereum EOA
│
│ Firma una autorización EIP-7702
▼
Se asigna la delegación
│
▼
Contrato inteligente delegado
│
│ Proporciona lógica ejecutable
▼
El EOA original puede ejecutar
comportamiento estilo contrato inteligente
La cuenta original no desaparece.
Su dirección, saldos e historial en cadena existente permanecen intactos. Lo que cambia es el código que puede ejecutarse a través de esa cuenta.
EIP-7702 también incluye salvaguardas. Las autorizaciones están vinculadas al estado de la cuenta, incluido un nonce, y pueden ser reemplazadas o revocadas. Por lo tanto, no son instrucciones arbitrarias que cualquiera pueda adjuntar a la billetera de otra persona.
Una autorización válida aún requiere una autorización criptográfica legítima de la cuenta correspondiente.
Ese punto es central para entender el incidente de Binance.
Si un atacante instala con éxito lógica de delegación maliciosa, la pregunta de seguridad importante no es simplemente:
"¿Usó el atacante EIP-7702?"
Es:
"¿Cómo obtuvo el atacante la autoridad para crear una autorización EIP-7702 válida?"
¿Por qué se reportaron múltiples autorizaciones EIP-7702?
Los investigadores de seguridad que examinaron las transacciones informaron que el atacante envió un lote que contenía aproximadamente 50 autorizaciones asociadas con diferentes valores de nonce.
A primera vista, "50 autorizaciones" puede sonar como si 50 billeteras hubieran sido comprometidas.
Eso no es necesariamente lo que ocurrió.
Las cuentas Ethereum mantienen un nonce que cambia a medida que se ejecutan las transacciones. Una autorización EIP-7702 debe corresponder al estado apropiado de la cuenta.
Si un atacante sabe qué billetera quiere atacar pero no puede determinar de manera confiable qué nonce será válido cuando una transacción llegue a la red, puede preparar autorizaciones para varios valores de nonce posibles.
Solo la autorización que coincida con el estado válido de la billetera tendría éxito.
Esta técnica a veces se describe como nonce spraying.
La implicación importante es que la existencia de 50 entradas de autorización no significa necesariamente 50 permisos exitosos, 50 claves privadas comprometidas o 50 ataques separados a billeteras.
En cambio, el patrón puede haber sido diseñado para aumentar la probabilidad de que una autorización obtenida previamente coincidiera con el estado de la cuenta objetivo al ser enviada.
Eso genera otra pregunta:
¿Quién —o qué sistema interno— tenía la autoridad para crear la firma subyacente?
Aquí es donde los hallazgos preliminares de Binance se vuelven especialmente relevantes.
El robo de claves privadas y el compromiso de la infraestructura de firma son problemas diferentes
Muchas discusiones sobre seguridad de criptomonedas reducen la protección de billeteras a un principio:
Protege la clave privada.
Eso sigue siendo esencial, pero las billeteras institucionales son considerablemente más complicadas.
Un exchange puede usar módulos de seguridad de hardware, servicios de firma, motores de políticas, servicios de retiro, sistemas de control de acceso y otra infraestructura alrededor de la clave subyacente.
Por lo tanto, un atacante puede intentar comprometer el proceso que solicita una firma en lugar de extraer la clave privada en sí.
La investigación preliminar de Binance actualmente apunta mucho más hacia el segundo escenario.
El exchange dijo que una laptop de DevOps comprometida puede haber permitido el acceso a un contenedor de servicio capaz de enviar transacciones de retiro no autorizadas, mientras declaraba explícitamente que no había encontrado evidencia de filtración de claves privadas.
Esa distinción es significativa.
Una clave privada protegida por hardware puede permanecer técnicamente segura mientras la infraestructura circundante produce una firma para algo que nunca debió haber sido aprobado.
¿Causó EIP-7702 el hackeo de Binance?
Según la información actualmente disponible, no hay evidencia pública de que una vulnerabilidad en EIP-7702 en sí misma haya causado el incidente de seguridad de Binance.
Esta distinción es crítica.
Que un atacante utilice una característica legítima del protocolo no significa automáticamente que la característica estuviera rota.
Consideremos un ejemplo más simple.
Si un atacante obtiene credenciales legítimas para una cuenta bancaria e inicia una transferencia a través del sistema de pagos normal del banco, el hecho de que la infraestructura de transferencias del banco ejecutara el pago no prueba que el protocolo de transferencia en sí fuera defectuoso.
Aquí se aplica una distinción similar.
EIP-7702 puede haber proporcionado el mecanismo de ejecución mediante el cual una cuenta autorizada con éxito pudo delegar su comportamiento a código malicioso.
Pero EIP-7702 normalmente requiere una autorización válida.
La cuestión no resuelta es cómo esa autorización llegó a ser posible.
La explicación preliminar de Binance sugiere que los investigadores están examinando infraestructura operativa comprometida en lugar de un fallo del protocolo Ethereum.
Por lo tanto, la interpretación más precisa en esta etapa es:
EIP-7702 parece relevante para la ruta de ejecución que se está investigando, pero no se ha establecido como la vulnerabilidad raíz.
¿Qué se ha confirmado y qué sigue bajo investigación?
Debido a que los incidentes de seguridad grandes evolucionan rápidamente, distinguir los hallazgos confirmados del análisis a nivel de transacción es especialmente importante.
Esta distinción importa porque las transacciones de blockchain proporcionan una visibilidad excelente sobre lo que ocurrió on-chain, pero no revelan necesariamente cómo se comprometió un sistema de firma interno.
Los investigadores pueden observar delegaciones, transferencias e interacciones con contratos.
No pueden determinar solo a partir de los datos de blockchain si una firma se creó después de que se robara una clave privada, si un servicio interno la solicitó legítimamente, o si un flujo de trabajo comprometido provocó que un firmante protegido autorizara instrucciones maliciosas.
Eso requiere evidencia desde dentro de la infraestructura afectada.
Por qué la infraestructura de firma importa tanto como el almacenamiento de claves privadas
La seguridad institucional de criptomonedas consiste cada vez más en varias capas.
La primera es la seguridad de las claves.
¿Dónde se almacena la clave privada? ¿Se puede extraer? ¿Está protegida por un módulo de seguridad de hardware u otro sistema de custodia criptográfica?
La segunda es la seguridad de la firma.
¿Qué servicios tienen permitido solicitar firmas de la clave protegida? ¿Qué autenticación, políticas y mecanismos de aprobación deben cumplir esos servicios?
La tercera es la seguridad de la autorización.
Incluso si una solicitud es criptográficamente válida, ¿qué exactamente se le está pidiendo a la cuenta que autorice?
Esta tercera capa se vuelve cada vez más importante a medida que las cuentas inteligentes y la delegación de cuentas adquieren más capacidades.
Una transferencia de tokens convencional puede mover una cantidad fija de un activo.
Una delegación puede, en cambio, cambiar cómo una cuenta puede ejecutar instrucciones futuras.
Para los equipos de seguridad, la diferencia significa que la validación de la firma por sí sola ya no es suficiente.
También debe evaluarse el significado de la transacción.
Por qué EIP-7702 cambia las suposiciones de seguridad de las billeteras
EIP-7702 es potente precisamente porque amplía lo que puede hacer una cuenta Ethereum ordinaria.
Una billetera puede obtener características programables sin migrar activos a una billetera de contrato inteligente completamente nueva.
Para las billeteras de consumo, esto puede mejorar la usabilidad.
Para la infraestructura institucional sofisticada, puede admitir políticas de ejecución más avanzadas.
Pero la programabilidad adicional crea superficies de autorización adicionales.
Una aprobación maliciosa de ERC-20 normalmente otorga a otra dirección permiso sobre un token.
Una delegación maliciosa de EIP-7702 puede potencialmente influir en cómo una cuenta ejecuta clases mucho más amplias de acciones.
Eso no hace que EIP-7702 sea intrínsecamente inseguro.
Significa que las billeteras, los exchanges y los proveedores de custodia deberían tratar la autorización de delegación como una operación de seguridad de alto riesgo.
Una firma de EIP-7702 no debería evaluarse solo como criptográficamente válida.
Los sistemas de seguridad también deberían preguntar si el objetivo de la delegación es el esperado, si su bytecode ha sido revisado, si la autorización solicitada se ajusta al comportamiento normal de la cuenta y si la política interna permite que esa cuenta delegue la ejecución en absoluto.
¿Qué debería aclarar el análisis post-mortem de Binance?
Binance ha dicho que se publicará un análisis técnico detallado post-mortem una vez que su investigación esté completa.
Varias preguntas determinarán cómo la industria interpreta en última instancia el incidente.
Primero, ¿cómo obtuvo el atacante acceso a la ruta de firma?
La explicación preliminar de DevOps identifica una parte potencialmente comprometida de la infraestructura, pero la cadena completa desde ese acceso hasta una autorización válida en la blockchain sigue siendo importante.
Segundo, ¿qué papel exacto desempeñó EIP-7702?
Los investigadores necesitarán determinar si la delegación era necesaria para ejecutar las transferencias de Ethereum, cómo se preparó la autorización y por qué los controles internos lo permitieron.
Tercero, ¿estuvieron alguna vez expuestas las claves privadas?
Binance actualmente afirma que no hay evidencia de filtración de claves privadas. Un informe forense completo podría proporcionar más detalles sobre cómo se aislaron las claves de la infraestructura comprometida.
Finalmente, ¿qué control debería haber detenido la transacción?
Para los equipos de seguridad institucional, esta puede ser la pregunta más valiosa de todas.
Una firma técnicamente válida no debería significar automáticamente una transacción operativamente válida.
Los sistemas de custodia más sólidos separan la autorización criptográfica de la autorización empresarial.
¿Qué significa esto para los usuarios ordinarios de billeteras Ethereum?
El incidente de Binance involucra infraestructura institucional y no debería interpretarse automáticamente como evidencia de que las billeteras Ethereum ordinarias están expuestas a la misma ruta de ataque.
Una billetera personal de autocustodia y un sistema de billetera caliente de un exchange operan de manera muy diferente.
Sin embargo, EIP-7702 introduce una lección importante también para los usuarios individuales:
Una firma de delegación merece el mismo nivel de precaución que otros permisos poderosos de billetera.
Los usuarios deben verificar cuidadosamente qué les está pidiendo firmar una billetera, particularmente cuando un sitio web desconocido solicita una delegación de cuenta.
Una delegación maliciosa no debe confundirse con una firma de inicio de sesión ordinaria.
Los usuarios también deben confiar en interfaces de billetera establecidas que identifiquen claramente las solicitudes de delegación y señalen contratos sospechosos.
El principio de seguridad clave sigue siendo simple: no juzgues una firma solo por si transfiere fondos inmediatamente. Algunas firmas cambian lo que una cuenta tendrá permitido hacer más adelante.
La lección más grande: la seguridad de las billeteras está yendo más allá de las claves privadas
El incidente de seguridad de Binance destaca una evolución más amplia en la seguridad de la blockchain.
Durante años, la suposición dominante de la industria fue directa:
Protege la clave, protege la billetera.
Ese modelo se está volviendo incompleto.
Las billeteras institucionales modernas a menudo dependen de capas de infraestructura alrededor de la clave: API, servicios de firma, motores de retiro, sistemas de políticas, controles de acceso y entornos de ejecución automatizados.
Los mecanismos de abstracción de cuenta como EIP-7702 añaden otra capa al permitir que las billeteras deleguen lógica de ejecución.
Como resultado, la seguridad de las criptomonedas depende cada vez más de tres preguntas separadas:
¿Quién controla la clave?
¿Quién puede solicitar una firma?
¿Y qué autoridad concede realmente esa firma?
Un sistema puede tener éxito en la primera pregunta mientras falla en la segunda o la tercera.
Ese parece ser uno de los problemas más importantes planteados por la investigación de Binance hasta ahora.
Preguntas frecuentes
¿Fue EIP-7702 la causa del hackeo de Binance?
No confirmado. Los hallazgos preliminares de Binance apuntan a una infraestructura operativa comprometida, mientras que EIP-7702 parece haber sido parte de la ruta de autorización bajo investigación.
¿Fueron robadas las claves privadas de Binance?
Binance dijo que no encontró evidencia de filtración de claves privadas de billeteras en su investigación inicial.
¿Qué es EIP-7702?
EIP-7702 permite que una EOA de Ethereum delegue lógica de ejecución a código de contrato inteligente mientras mantiene la misma dirección de billetera.
¿Por qué se observaron múltiples autorizaciones EIP-7702?
Pueden haber sido preparadas con diferentes valores de nonce para coincidir con el estado de la cuenta objetivo. Esto no significa necesariamente que múltiples billeteras fueron comprometidas.
¿Están afectados los usuarios ordinarios de Ethereum?
No hay evidencia de un compromiso de billeteras Ethereum a nivel de red. Los usuarios aún deben ser cautelosos con solicitudes de delegación o firma desconocidas.
¿Es suficiente revocar las aprobaciones de tokens?
No siempre. Las aprobaciones ERC-20 y la delegación EIP-7702 son permisos separados, por lo que eliminar una aprobación de token no elimina automáticamente la delegación de cuenta.
Conclusión
La aparición de EIP-7702 en el incidente de Binance convierte a este mecanismo en una parte importante de la investigación técnica, pero la evidencia disponible no establece que EIP-7702 en sí mismo haya sido comprometido.
Los hallazgos preliminares de Binance, en cambio, sugieren que un atacante podría haber comprometido el portátil de un ingeniero de DevOps, obtenido acceso a un contenedor de servicio operativo y enviado transacciones de retiro no autorizadas. El exchange afirma que no ha encontrado evidencia de filtración de claves privadas de carteras.
La distinción importa.
Si se puede inducir a un sistema de firma protegido a autorizar instrucciones maliciosas, los atacantes podrían no necesitar robar la clave privada en absoluto.
EIP-7702 puede aumentar las consecuencias de dicha autorización porque permite que una cuenta de Ethereum delegue lógica de ejecución programable. Pero usar esa capacidad de forma maliciosa y encontrar una vulnerabilidad en el protocolo son dos cosas diferentes.
Hasta que Binance publique su análisis técnico completo posterior al incidente, lo mejor es entender EIP-7702 como un componente dentro de la ruta de ejecución reportada, no como la causa raíz confirmada del incidente.
Para los exchanges, los proveedores de custodia y los desarrolladores de carteras, la lección más amplia ya es clara: la seguridad moderna de las carteras debe proteger no solo las claves privadas, sino también los sistemas que solicitan firmas y los permisos que esas firmas crean.
Descargo de responsabilidad de riesgo: Este artículo tiene fines únicamente informativos y educativos. Los sistemas de criptomonedas y blockchain implican riesgos técnicos, operativos y de mercado. Los lectores deben verificar de forma independiente la información de seguridad y utilizar controles de riesgo adecuados al gestionar activos digitales.
