# Así fue el hackeo a Binance y estas son sus consecuencias > La firma filtrada de Binance 14, 50 autorizaciones EIP-7702 y 5.600 millones fuera. Cronología, errores y el efecto en el mercado. > Por José Maldonado · Ciberseguridad · 2026-10-30 A las 20:20:59 UTC del 29 de octubre, una cartera caliente de Binance recibió una transacción que llevaba dentro cincuenta firmas. Cuatro minutos después, 167.464 ether, 1.615 millones de USDT y sesenta tokens más habían salido de ella hacia una dirección recién creada. La cartera, etiquetada como Binance 14, se quedó con un ether de saldo. El total no se conoce todavía con total certeza. Las estimaciones on-chain han ido de 5.570 a 5.800 millones de dólares entre Ethereum, Bitcoin y Tron, más de tres veces lo que se llevaron de Bybit en febrero de 2025. Binance no ha publicado la cifra de la pérdida, pero sí dos compromisos: que cubrirá todas las pérdidas del hackeo y que publicará un informe técnico cuando termine la investigación. Su primera cifra oficial es otra: 2.540 millones congelados por emisores de stablecoins y socios. Lo interesante no es el importe, que cambia cada hora, sino cómo salió el dinero. Alguien consiguió que una cartera caliente firmara un permiso que no debía existir, y ese permiso resistió hasta que Binance lo revocó. La pregunta que deja el caso no es cuánto se perdió, sino qué mira un sistema de control de firmas cuando la orden llega con la clave correcta. ## La víspera, tres retiradas de Tornado Cash y un ensayo de seis dólares El trabajo previo empezó el 28 de octubre. La dirección que actuaría como operadora, \`0x7C86…5CA0\`, se financió con tres retiradas de Tornado Cash, según la reconstrucción on-chain que recoge el [análisis de Int Cyber Digest](https://x.com/IntCyberDigest/status/2115947714353480160). El mezclador sigue siendo la puerta de entrada estándar del capital inicial. Al día siguiente, el operador ensayó la jugada completa. Lo hizo sobre tres carteras que controlaba él mismo, con importes de entre dos y seis dólares, para comprobar que el contrato hacía lo que esperaba. A las 15:59 UTC desplegó el contrato definitivo, \`0x63e8…6fAe\`, sin verificar y con una particularidad que explica media historia: solo la dirección del operador puede llamarlo. Cualquier otra dirección que intente usarlo se queda fuera. Ese contrato tenía dos funciones. Una barre todos los tokens y el ether de la cuenta hacia un destinatario. La otra permite que la cuenta delegada llame a otros contratos en su nombre. Quien controlara la cartera de Binance solo necesitaba que ejecutara ese código. ## Cincuenta firmas para acertar un nonce El mecanismo es la parte técnica que más conviene entender, porque ayer circuló una versión simplificada que no se sostiene. No hubo una vulnerabilidad de Ethereum. Lo que hubo, según la revisión de [Yan at Swan](https://x.com/skwp/status/2115974916088500713), es acceso a la infraestructura de firma de Binance a escala: alguien pudo obtener firmas válidas de la clave de Binance 14, o del sistema que la custodia, y usarlas. La función que lo convirtió en catástrofe es EIP-7702, una pieza de la actualización Pectra de Ethereum que entró en vigor este año. Permite que una cartera normal, de las de toda la vida, delegue su control en un contrato inteligente. La autorización es un mensaje firmado que nombra un contrato, y una vez que una transacción la incluye en un bloque, cualquier llamada a la cartera ejecuta el código de ese contrato con acceso completo a sus saldos. El detalle que salvó al atacante de necesitar más firmas: la autorización va atada al número de transacción de la cartera, su nonce. Binance 14 seguía operando y pagando retiradas, así que ese número se movía. Quien firmó no sabía cuál estaría activo en el momento del golpe. La solución fue empaquetar cincuenta autorizaciones en una sola transacción, una por cada nonce entre 18.914.775 y 18.914.824. Cuarenta y nueve no valían nada. Una coincidió. A las 20:20:59 esa transacción entró en un bloque. La delegación quedó activa sobre Binance 14 mientras la cartera seguía operando con normalidad. Es el punto que Blockaid subraya: una firma normal se gasta una vez; esta dejó código instalado hasta que Binance lo reemplazara. ## El barrido que dejó un ether en la cartera Tres minutos y veinticuatro segundos más tarde, el operador llamó a la función de barrido. En una sola transacción salieron 167.464 ETH, 1.615 millones de USDT y alrededor de sesenta tokens hacia \`0x5227…2f8c\`, una dirección sin historial previo. A los precios de esa hora, unos 2.500 millones de dólares. Etherscan etiquetó el destino como «Binance Hot Wallet Exploiter 2» y Binance 14 quedó con un ether. Veinticuatro segundos después llegó el segundo golpe. Binance 16 envió a la misma dirección 28.005 ETH junto a cinco tokens menores entre los que había 55 millones en USDT. Aquí se ve por qué la delegación era más peligrosa que una firma suelta: una vez activa, el atacante heredó los derechos de operador de Binance 14 sobre otras carteras, incluida la extracción de 780 millones en USDC desde Hot Wallet 34. La primera alarma pública la dio el analista Spreek, antes de que ningún medio tuviera la historia. PeckShield marcó las salidas a las 20:55 UTC. Entre esas dos horas, la cuenta oficial de Binance [dijo que investigaba](https://observatorioblockchain.com/ciberseguridad/cz-apunta-a-un-hackeo-de-binance-congelan-2-367-millones/) y que no había confirmado impacto en fondos de usuarios. Su fundado, CZ, fue más lejos a las 21:15: [parecía un hackeo](https://x.com/cz_binance/status/2115915423174853077) y esperaba que los fondos quedaran cubiertos. ![CZ advierte en X de un hackeo en Binance](https://content.observatorioblockchain.com/wp-content/uploads/2026/10/cz-hackeo-binance.webp) *CZ advierte en X de un hackeo en Binance* ## Doce minutos, diez carteras y cuatro cadenas El alcance no se quedó en Ethereum. En los doce minutos siguientes al primer barrido, diez carteras calientes más repartieron salidas hacia la misma dirección. Binance 55 en Optimism envió 44,2 millones de OP y cuatro carteras en Arbitrum movieron 74,6 millones de ARB. Otras cuatro carteras en Avalanche sacaron 1,81 millones de AVAX junto a otros tokens. Tron y Bitcoin completaron el mapa con 630 y 1.440 millones respectivamente, y para ninguna de esas redes hizo falta una firma nueva. Ese patrón es la firma de un ataque con acceso a la capa de firma y no a una cartera concreta. Diez sistemas distintos no se comprometen por casualidad en doce minutos: se comprometen porque comparten la infraestructura que autoriza las salidas. Una hipótesis que circuló anoche, y que [philarekt](https://x.com/philarekt/status/2115934331260575811) planteó, es que parte de los movimientos en Tron fueran de la propia Binance. El exchange no lo ha aclarado, así que queda como pregunta abierta. ## Los cuatro errores que convirtieron un fallo en una catástrofe El primero es de arquitectura. Una cartera caliente que atiende retiradas no debería poder ejecutar código arbitrario sobre sí misma con una sola firma. La delegación de EIP-7702 estaba pensada para carteras de usuario final, donde el titular es también quien firma. En una cartera operativa con saldos de cinco cifras de millones, convierte cualquier firma filtrada en control persistente. El segundo es de política. Los sistemas que aprueban una transferencia tienen algo que revisar: a quién va el dinero, cuánto sale, qué token se mueve y qué límites por hora se aplican. Una autorización de EIP-7702 no ofrece casi nada de eso, apenas identificador de cadena, dirección de contrato y nonce. Para un motor de reglas, esa firma es opaca. Blockaid lo resume igual: no había nada útil que inspeccionar. El tercero es de rotación. El nonce spray funcionó porque la cartera seguía emitiendo transacciones mientras el atacante disparaba cincuenta firmas a ciegas. Cuarenta y nueve cayeron en saco roto, y bastó una. Cambiar claves en caliente, con una cartera produciendo actividad, es una carrera que el defensor pierde si el atacante ya tiene las firmas. El cuarto es de alcance. La delegación no se limitó a la cartera comprometida: heredó sus permisos sobre otras. Ahí está la diferencia entre perder una caja fuerte y perder la llave maestra del pasillo. ## El marcador, con las cifras que Binance ha aceptado El recuento por activo que publicó [Watcher.Guru](https://x.com/WatcherGuru/status/2115922259739349132) a las 21:42 UTC es el desglose más completo que circula, y coincide con las tenencias que Arkham sigue en 55 direcciones etiquetadas como parte del ataque. Esta es la composición: * 1.450 millones en bitcoin, 18.270 unidades * 1.570 millones en USDT * 875 millones en ether * 823 millones en USDC * 234 millones en TRX * 88,5 millones en RLUSD * 75 millones en wBETH y 50 millones en XAUT * 447,5 millones en otros tokens ![Watcher.Guru habla del hackeo a Binance y da cantidades](https://content.observatorioblockchain.com/wp-content/uploads/2026/10/watcher-guru-cantidades-hackeo-binance.webp) *Watcher.Guru habla del hackeo a Binance y da cantidades* En las congelaciones, la cifra que vale es la oficial. Binance corrigió a las 23:22 UTC los 1.800 millones que circulaban y fijó 2.540 millones verificados, con aviso de que subiría. Tether aportó 1.567 millones de USDT, Circle 823 millones de USDC, Ripple unos 200 millones de RLUSD según la co-consejera delegada Yi He, y World Liberty Financial 27 millones en USD1. [Decrypt](https://decrypt.co/382194/binance-hack-exit-ramps-defi-exchange-ethereum) advierte de algo que se olvida con facilidad: congelar no es recuperar, y esos procesos tardan semanas. La cuenta que importa es la resta. Con 2.540 millones bloqueados frente a más de 5.600 fuera, el hueco supera los 3.000 millones. El primer respaldo es el SAFU, el fondo que Binance convirtió el año pasado en 15.000 bitcoins, unos 1.000 millones al precio actual. Para el escenario bajo alcanzaría; para el alto, no. ## Lo que el mercado descuenta esta madrugada El precio se movió antes de que hubiera confirmación. Bitcoin perdió el umbral de los 80.000 dólares y [cotiza por debajo de 78.000](https://www.cnbc.com/2026/10/30/bitcoin-ether-price-binance-security-scare-rattles-crypto-markets.html), con más del 4% de caída en un día. Ether cede cerca del 5% hasta 2.247 dólares y BNB se deja un 7,7% hasta 694; AAVE, expuesta por el uso de sus mercados como salida, bajó un 8%. Hay dos lecturas que conviene no mezclar. La primera es de confianza: el castigo a BNB es el mercado descontando que el exchange más grande del mundo puede tener un agujero de miles de millones sin haber dicho cuánto. La segunda es de refugio: Hyperliquid sube un 9,7% y Monero avanzó un 6% la noche anterior, dos activos que se benefician de que el dinero busque manos fuera del sistema comprometido. Y está el dato que menos se está citando. Según las reservas que recogía [CoinDesk](https://www.coindesk.com/business/2026/10/30/binance-hack-drained-wallets-backing-customer-assets-reserve-data-shows), el 1 de octubre Binance tenía exactamente el 100% del ether de sus clientes y el 108% de sus USDC. Los cerca de 204.500 ETH sustraídos equivalen al 5,6% de sus reservas de ether, lo que deja el respaldo en torno al 94%. En ENA, UNI, PEPE y AAVE, las posiciones del atacante representan entre el 7% y el 15% de lo que el exchange declaraba tener de cada uno. ## Las próximas 72 horas Lo primero es reabrir. Binance suspendió depósitos y retiradas a las 00:04 UTC, después de haber cortado solo retiradas a las 22:15 y las operaciones de Binance Alpha a las 23:06. La secuencia es la de quien rota claves y limpia delegaciones antes de dejar que algo se mueva, y explica por qué no hay hora de reapertura: cada cadena necesita que sus carteras estén reautorizadas. Que la reapertura ocurra sin un segundo incidente es la única prueba real de que el acceso está cortado. Un comunicado diciendo que todo está bajo control no vale gran cosa si la primera retirada de prueba reactiva una delegación que seguía viva. Lo segundo es el informe. La promesa de un post-mortem completo es más exigente de lo que parece, porque obliga a explicar cómo se obtuvieron cincuenta firmas válidas. Si la respuesta es un sistema interno comprometido, el problema deja de ser de Binance: cualquier exchange que use la misma infraestructura de custodia y firma tiene que revisar sus permisos de delegación antes de que alguien repita la jugada. ### ¿Filtración o infiltración? Si la respuesta es una clave filtrada, el sector tiene un problema de gestión de secretos que lleva años aplazando. Y no se arregla con un comunicado, sino con inventario de claves, rotación programada y límites de firma que se puedan verificar desde fuera. Lo tercero es el regulador. Un robo de este tamaño en la jurisdicción que aloja al mayor exchange del mundo abre la puerta a exigencias concretas: auditorías de reservas más frecuentes que las trimestrales, límites de exposición por cartera caliente y protocolos de bloqueo coordinados con los emisores. MiCA ya obliga a separar fondos de clientes. Lo que este caso demuestra es que tener los fondos separados no sirve de nada si la firma que los mueve está en el mismo sitio que el resto. Lo cuarto es el dinero que queda libre. Los más de 3.000 millones no congelados están en bitcoin, ether y stablecoins que ya saltaron a direcciones posteriores. La ruta parece la de siempre: stablecoins a ether en Uniswap, ether prestado contra colateral en Aave, y de ahí a mezcladores o puentes. Aave congeló sus mercados V3 en Ethereum y Kamino pausó los suyos en Solana. Son dos decisiones defensivas, y las dos indican lo mismo: los protocolos asumen que el atacante sigue buscando salidas y que la ventana no se ha cerrado. ## Un permiso que sigue concedido La parte incómoda del caso es que el vector no fue exótico. Ni un contrato con un error sutil, ni un puente mal diseñado, ni un oráculo manipulado. Fue una firma. La industria lleva una década fortaleciendo la cadena de bloques y muy poco tiempo fortaleciendo la cadena de autorización que hay detrás, la que decide qué puede firmar una máquina y qué no. EIP-7702 llegó para dar comodidad a carteras de usuario, con agregación de transacciones y pago de gas por terceros. En una cartera caliente se convirtió en un permiso permanente que nadie supervisaba. El siguiente paso lógico es que los sistemas de firma aprendan a inspeccionar ese tipo de autorización y a rechazarla cuando llega desde una cartera operativa, y que las carteras de exchange dejen de poder delegar código en sí mismas. Hasta que eso ocurra, la promesa de cubrir todas las pérdidas resuelve el problema de los clientes de Binance y deja intacto el del resto. Cualquier exchange con carteras calientes, permisos amplios y una política de firma que no entiende las autorizaciones de nuevo tipo tiene el mismo agujero, con o sin hackeo de por medio.