El hackeo de Binance, el 29 de octubre, fue el mayor robo de criptomonedas jamás registrado: cerca de US$ 6.300 millones salieron de las billeteras del exchange en pocas horas. Según lo que Binance ha informado hasta ahora, el ataque pudo haber empezado en la laptop comprometida de un ingeniero de DevOps, y no en una falla de criptografía. Si una empresa con un equipo de seguridad dedicado cae por la infraestructura del día a día, un sistema armado solo con vibe coding, sin nadie que entienda de infraestructura, programación y seguridad, es el blanco más fácil del mercado.
Respuesta rápida
- ¿Qué pasó? El 29 de octubre, billeteras de Binance en unas diez blockchains fueron vaciadas. Binance estima la pérdida en US$ 6.300 millones y suspendió los retiros en varias redes.
- ¿Cómo entraron? Según Binance, el atacante habría usado la laptop de un ingeniero para acceder a un servicio interno y enviar retiros no autorizados. La empresa dice que no se filtró ninguna clave privada. El análisis técnico completo aún no se publicó.
- ¿Quién fue? Empresas de rastreo de blockchain señalan al grupo norcoreano TraderTraitor (vinculado a Lazarus). Hasta ahora, ningún gobierno confirmó oficialmente la autoría.
- ¿Los clientes pierden dinero? Binance afirma que cubrirá todas las pérdidas con el fondo de emergencia SAFU y recursos propios. Los emisores de stablecoins congelaron cerca de US$ 3.000 millones vinculados al ataque.
- ¿Qué tiene que ver con tu empresa? Los atacantes actúan como una operación de Estado: ensayan, automatizan y buscan el eslabón más débil. Un sistema generado por IA sin revisión técnica suele traer justamente las fallas que este tipo de atacante busca primero.
Lo que se sabe del hackeo de Binance hasta ahora
La billetera del atacante recibió fondos un día antes, con pequeños retiros de un mezclador de criptomonedas. El día 29, el código del ataque se probó horas antes de ejecutarse. Alrededor de las 20 h (horario UTC), billeteras de Binance en el XRP Ledger enviaron 233 millones de XRP a una sola dirección. En la media hora siguiente se vaciaron las billeteras calientes de otras redes, incluida una sola transacción de US$ 2.500 millones en ether. Una segunda ola alcanzó Avalanche y Polygon al final de la noche.
La lectura de los registros en la blockchain sugiere que el invasor no robó las claves: logró dar órdenes a la propia infraestructura de firma del exchange. En otras palabras, el sistema firmó y envió las transferencias porque el pedido llegó desde adentro, por un camino que debía ser confiable.
La respuesta fue rápida en un frente: Tether bloqueó más de 1.000 millones de dólares en USDT en la billetera principal del atacante en menos de 40 minutos, y Circle congeló más de 800 millones en USDC. Aun así, más de US$ 3.000 millones siguen fuera del alcance de los emisores. Las cifras todavía son preliminares y varían entre las fuentes.
Es el segundo gran caso del mercado cripto en pocas semanas. En septiembre ya habíamos analizado lo que los hacks de septiembre revelan sobre riesgo y gobernanza.
No fue solo Binance: gobiernos también cayeron en octubre
En la misma semana, tres organismos públicos confirmaron incidentes graves:
- Moldavia: entre el 19 y el 23 de octubre se extrajeron de los servicios digitales del Estado datos vinculados a unos 750 mil números de identificación personal. El gobierno apagó 82 servicios públicos y más de 30 sistemas para contener el ataque. La agencia responsable dijo que había servicios accesibles sin autenticación.
- Estados Unidos (Departamento de Seguridad Nacional): un grupo publicó datos de más de 40 mil empleados y contratistas. El atacante dice que los registros salieron del sistema de inicio de sesión único que usa el organismo. El proveedor del inicio de sesión niega haber sido invadido, y no se aclaró cómo entraron.
- Florida (Departamento de Educación): el portal de ayuda financiera estudiantil sufrió un acceso no autorizado identificado el 19 de octubre, con posible exposición de datos de 4,9 millones de personas, incluidos números del Seguro Social.
El patrón se repite: credenciales, acceso y configuración. En ninguno de estos casos el problema confirmado fue una criptografía rota. Fue una puerta abierta o una llave con demasiada confianza.
Por qué es una alerta para quien contrata un sistema hecho con IA
Ataques como el de Binance los hacen equipos profesionales y financiados, que ensayan antes de actuar y lavan el dinero en minutos. Del otro lado, el mercado vive una ola de sistemas creados con vibe coding: la persona le describe a una IA lo que quiere, acepta el código generado y lo publica, sin leer, revisar ni entender lo que se entregó.
La IA escribe código rápido, y eso tiene valor. El problema está en quien contrata: muchas empresas están entregando el sistema que guarda clientes, pedidos, pagos y datos personales a proveedores o profesionales que no saben evaluar lo que escribió la IA. Sin base en infraestructura, programación, seguridad y arquitectura, nadie se da cuenta de que el sistema funciona en la demostración y está abierto para cualquiera en internet.
Y la misma tecnología que genera código en minutos también ayuda a rastrear código en minutos. El costo de encontrar una falla bajó para quien ataca. Una falla básica dejó de ser un riesgo teórico y se convirtió en blanco de escaneo automático.
Los casos de vibe coding que ya salieron mal este año
- Moltbook, en enero: una red social de agentes de IA, construida con herramientas de IA, expuso 1,5 millones de tokens de acceso a APIs y 35 mil correos pocos días después del lanzamiento. La causa fue una base de datos Supabase configurada sin reglas de seguridad por fila.
- Lovable, de marzo a abril: una falla de autorización en la plataforma permitía que un usuario gratuito leyera el código fuente, el perfil y las credenciales de base de datos de otros proyectos con pocas llamadas a la API. La falla siguió abierta 48 días después de reportada. La empresa lo cuestiona y dice que no hubo filtración.
- Vulnerabilidades catalogadas: investigadores de Georgia Tech contaron 35 vulnerabilidades oficiales (CVE) causadas por código generado por IA solo en marzo, frente a 6 en enero, y estiman que el número real es mucho mayor.
Las fallas más comunes en un sistema hecho solo con vibe coding
Son casi siempre las mismas, y todas son invisibles para quien solo prueba haciendo clic en las pantallas:
- Clave de API o contraseña de base de datos dentro del código del navegador, donde cualquier visitante puede leerla.
- Base de datos sin reglas de acceso: la pantalla muestra solo tus pedidos, pero la API devuelve los pedidos de todos.
- Autorización que verifica el login, pero no quién es el dueño del dato: basta cambiar un número en la URL para ver el registro de otro cliente.
- Webhooks de pago sin verificación de firma: alguien simula la confirmación de un pago que nunca existió.
- Secretos en el repositorio y servidor con todo expuesto: panel de administración, puerto de la base de datos y logs abiertos a internet.
- Sin logs, sin backup probado y sin plan de respuesta: cuando ocurre el incidente, nadie sabe qué salió ni desde cuándo.
Cada punto de esta lista involucra datos personales y, por lo tanto, las leyes de protección de datos. Una filtración por una falla básica no es mala suerte: es falta de cuidado que la ley cobra. Mira cómo preparar el sitio web de tu empresa para recopilar datos con seguridad.
Profesional que usa IA × vibe coding sin base técnica
| Punto | Profesional que usa IA | Vibe coding sin base técnica |
|---|---|---|
| Código generado | Leído, revisado y entendido antes de salir a producción | Aceptado porque "funcionó" |
| Arquitectura | Definida antes: qué queda en el servidor y qué en el navegador | Lo que la IA decidió en el momento |
| Acceso a datos | Reglas por usuario y por registro, probadas | Confía en la pantalla para esconder el dato |
| Secretos y claves | En el servidor, con rotación y permiso mínimo | En el código, en el repositorio, en el navegador |
| Infraestructura | Servidor cerrado, backup probado, monitoreo | Configuración por defecto de quien creó la cuenta |
| Cuando hay un problema | Sabe dónde mirar y qué apagar | Le pide a la IA que lo "arregle" y cruza los dedos |
La diferencia no es usar o no usar IA. Nosotros usamos IA todos los días. La diferencia es tener a alguien que asuma la responsabilidad técnica por lo que sale a producción.
7 preguntas para hacer antes de contratar un sistema
- ¿Quién revisa el código generado por IA antes de salir a producción, y con qué criterio?
- ¿Dónde quedan las claves de API, las contraseñas de base de datos y los tokens de pago?
- ¿Cómo garantiza el sistema que un cliente no vea los datos de otro?
- ¿En qué servidor corre el sistema, quién lo administra y quién aplica las actualizaciones de seguridad?
- ¿Hay backup automático? ¿Cuándo fue la última prueba de restauración?
- ¿Qué accesos quedan registrados en logs, y por cuánto tiempo?
- Si hay un incidente un viernes por la noche, ¿quién atiende y cuál es el primer paso?
Si las respuestas son vagas, el precio bajo te está cobrando la cuenta en otro lugar. Para comparar proveedores con criterio, mira software house, freelancer o equipo interno: cómo decidir con seguridad y cómo elegir una software house con criterio estratégico.
¿Ya tienes un sistema hecho así? Por dónde empezar
- Busca secretos expuestos: abre el sistema en el navegador, revisa el código cargado y el repositorio. Clave encontrada es clave que hay que cambiar de inmediato.
- Prueba el acceso entre usuarios: crea dos cuentas e intenta ver los datos de una desde la otra, cambiando identificadores en la URL y en las llamadas a la API.
- Revisa las reglas de la base de datos: en servicios como Supabase y Firebase, confirma que las reglas de acceso estén activas en todas las tablas.
- Cierra el servidor: solo los puertos necesarios abiertos, panel de administración protegido y actualizaciones al día.
- Activa logs y backup: y haz una prueba de restauración de verdad.
- Pide una revisión técnica independiente a alguien que no haya escrito el sistema.
Preguntas frecuentes
¿Binance fue hackeada por culpa del vibe coding?
No hay ninguna indicación de eso. Según lo divulgado hasta ahora, la entrada habría sido la laptop de un ingeniero y el abuso de un servicio interno. El punto es otro: si una empresa de ese tamaño cae por la infraestructura del día a día, un sistema sin ninguna revisión técnica está mucho más expuesto.
¿Los clientes de Binance van a perder dinero?
Binance afirma que los fondos de los usuarios están seguros y que cubrirá todas las pérdidas con el fondo SAFU y recursos propios. Los retiros se suspendieron temporalmente en algunas redes como precaución.
¿El vibe coding siempre es malo?
No. Para un prototipo, una prueba de idea o una herramienta interna sin datos sensibles, puede ser excelente. El riesgo aparece cuando el código sale a producción con datos de clientes, pagos o integraciones, sin que nadie con base técnica lo revise.
¿Cómo saber si mi proveedor usa IA sin revisión?
Haz las 7 preguntas de arriba. Quien revisa de verdad responde con nombres, herramientas y procesos. Quien no revisa responde que "el sistema es seguro" sin decir cómo.
¿Un sistema hecho con IA es seguro?
Puede serlo, siempre que alguien con conocimiento de seguridad, infraestructura y arquitectura defina la estructura, revise el código y mantenga el servidor. La seguridad viene del proceso, no de la herramienta que escribió el código.
Tecnología rápida, con responsabilidad técnica
Usamos IA para entregar más rápido, con código revisado, arquitectura definida antes de la primera línea y servidores administrados por quien responde por ellos. Así hacemos el desarrollo de sistemas web a medida y la gestión de servidores cloud de alto rendimiento. Si tu sistema se hizo con prisa y quieres saber el tamaño del riesgo, habla con nuestro equipo.
Fuentes
- Elliptic — The largest theft in history: North Korea likely behind the Binance hack
- TechCrunch — Binance pauses withdrawals as hackers suspected of stealing billions in crypto
- InfoMoney — Hackers desviam US$ 6,3 bi da Binance no maior roubo de criptomoedas da história
- Pasquale Pillitteri — Moldova cyberattack: 750,000 people's data stolen
- Pasquale Pillitteri — Ataque hacker ao DHS, dados de 40.000 funcionários roubados
- Nossa Gente — Ataque hacker atinge Departamento de Educação da Flórida
- The Next Web — Lovable security crisis and the structural failure of vibe coding security