60 millones en hacks cripto: detectar escala, parchear no

Entre el 19 y el 27 de julio de 2026 se robaron 60,45 millones de dólares en ocho hackeos a protocolos y empresas de cripto: el 80 % de lo que se robó en todo junio (75,87 millones en 40 incidentes, según la firma de seguridad PeckShield) concentrado en nueve días. La cifra importa menos que el patrón: casi ninguno de esos ataques necesitó un fallo nuevo. Verus cayó por la misma ruta de código que ya le habían explotado en mayo, Allbridge por una arquitectura de pools (fondos de liquidez compartidos) que su propio post-mortem de 2023 prometió eliminar, y Triple-A siguió aceptando depósitos que el atacante barría en tiempo real durante 31 horas. Encontrar vulnerabilidades ya escala como escala el software —con agentes automatizados en los dos bandos, con cifras públicas y fechadas—. Corregirlas sigue corriendo a velocidad de comité: auditoría, votación, firma múltiple, despliegue. Este artículo mide esa distancia con datos de ambos lados y marca con precisión dónde termina lo demostrable.

¿Qué protocolos cayeron entre el 19 y el 27 de julio de 2026?

Ocho incidentes con pérdida cuantificada y uno sin ella (la cuenta de X del consejero delegado de Robinhood, usada para promocionar un memecoin). La cuenta de análisis on-chain Lookonchain agrupó el pico del 22 al 23 de julio bajo la etiqueta «Hackers' Day» —dos puentes cross-chain reventados con seis horas de diferencia, marcados por la firma de seguridad Blockaid en tiempo real—. El detalle importa más que el agregado, porque el vector se repite: quórum de firmas, permisos de actualización y wallets calientes, con un solo caso de matemática de pool mal planteada.

Triple-A merece una nota aparte porque es una pasarela regulada en Singapur y no un protocolo anónimo: los fondos de clientes están en cuentas fiduciarias exigidas por la autoridad monetaria del país y no se tocaron. Lo drenado fue la tesorería propia de la empresa. Aun así, el ataque duró más de un día entero y las cuentas de depósito siguieron abiertas mientras ocurría.

¿Por qué Verus, Allbridge y Triple-A cayeron por fallos ya conocidos?

Los tres casos comparten la misma forma: el conocimiento del fallo existía antes del ataque y el remedio no llegó a producción a tiempo. Puestos en orden cronológico, la secuencia es difícil de leer como mala suerte.

1. Verus, dos meses y una recaída. En mayo de 2026 el puente perdió unos 11,5 millones de dólares por una ruta de importación que emitía pagos sin respaldo en el lado de Ethereum. El atacante devolvió 4.052,4 ETH quedándose una recompensa del 25 %. Los fondos recuperados se volvieron a depositar formalmente en el puente a comienzos de julio. Quince días después, el 23 de julio, un atacante distinto con una wallet nueva abusó de la misma clase de bug en el mismo contrato y se llevó 7,54 millones: dos meses entre la primera detección y la segunda pérdida, con el contrato intacto.
2. Allbridge, tres años y tres meses. Un ataque de flash loan (un préstamo que se pide y se devuelve dentro de la misma transacción) de abril de 2023 le costó unos 573.000 dólares. El post-mortem público prometía una medida concreta: un único pool de liquidez por blockchain, precisamente para que la manipulación no pudiera completarse en una sola transacción. El despliegue en Solana mantuvo USDC y USDT en la misma arquitectura de pool, que es exactamente el segundo token que el exploit necesita. La corrección estaba escrita, publicada y sin aplicar donde hacía falta.
3. Triple-A, 31 horas de ventana abierta. El investigador on-chain conocido como Specter detectó y publicó los movimientos anómalos el viernes 24 de julio, cuando ya iban 9,3 millones drenados. La empresa no confirmó públicamente la brecha hasta el lunes 27. Entretanto los depósitos nunca se desactivaron: el atacante siguió barriendo entradas nuevas hasta elevar el total a 11,8 millones.

El patrón es el que ya documentamos en los hacks de 2026 que atacan el perímetro y no el contrato: AFX, B² y Triple-A no cayeron por matemática financiera mal auditada, sino por claves, permisos y procesos operativos. La novedad de julio es la reincidencia documentada sobre el mismo código.

¿Por qué parchear un protocolo DeFi no escala como auditarlo?

Un análisis de código se puede lanzar sobre mil repositorios a la vez, sin permiso de nadie y sin coste si se equivoca; un parche en producción exige reproducir el fallo, auditar el arreglo, reunir firmas de una multisig, superar un timelock (un retardo obligatorio antes de que el cambio entre en vigor) y, si el contrato se actualiza por votación, pasar por gobernanza. Cada paso del segundo camino tiene latencia humana medida en días o semanas.

La parte incómoda de esa cadena es la firma múltiple. En el análisis sobre el multisig como teatro de seguridad el problema era que las firmas no protegen sin un modelo de custodia real. En julio apareció la cara opuesta del mismo mecanismo: los cinco validadores de AFX Trade tenían sus claves calientes, y el quórum que existe para frenar una retirada indebida se convirtió en la llave completa en cuanto el atacante reunió las cinco firmas. Un esquema que ralentiza la corrección legítima sin ralentizar al atacante ha invertido su función.

¿Cuántas vulnerabilidades encuentra hoy la IA y cuántas parchea?

Los dos lados de la asimetría entre encontrar fallos y corregirlos tienen cifras publicadas y fechadas, y comparadas en la misma tabla la distancia es de un orden de magnitud. Ninguno de estos sistemas se ha usado —que se sepa— contra un protocolo cripto; sirven para medir a qué velocidad avanza cada mitad del problema en el software en general.

Un solo agente envió más de mil informes en tres meses, con más de 400 ya resueltos o aceptados en triaje al momento del hito. El agente de corrección más avanzado que ha publicado métricas llevaba 72 arreglos aceptados en medio año (su última cifra pública, de octubre de 2025); desde el 22 de julio de 2026 está en preview pública para clientes empresariales de Google Cloud, mientras que su variante con el modelo especializado en ciberseguridad sigue restringida a gobiernos y socios de confianza. La proporción entre ambos ritmos ronda el 25 a 1 por unidad de tiempo, y la comparación es generosa con el lado corrector: esos 72 arreglos son parches en proyectos de código abierto, sin gobernanza on-chain, sin timelock y sin liquidez de usuarios bloqueada mientras se despliega.

El modelo especializado presentado el 22 de julio apunta en la dirección correcta —encuentra, valida y propone parche en la misma pasada, y los investigadores que lo probaron sacaron vulnerabilidades de ejecución remota en APIs públicas en dos horas—. Pero el cuello de botella de un puente cross-chain está aguas abajo de la escritura del parche: en que alguien con autoridad lo apruebe, lo firme y lo despliegue. Ningún modelo tiene esa autoridad, y dársela abre un problema de seguridad distinto.

La tabla siguiente cruza los incidentes y la cuantía robada por trimestre (DefiLlama, exploits de protocolo sin phishing; el pico de Q1-2025 es Bybit) con el modelo líder en LMArena en cada momento. Los scores son snapshots orientativos —el leaderboard recalibra retroactivamente— y la coincidencia temporal no implica causalidad: ningún hackeo de la serie tiene atribución pública a IA. La lógica de vigilar esa columna es corta: más superficie revisada sin fatiga y a coste marginal decreciente, más agujeros encontrados. El caso que apunta a que la franja de capacidad relevante ya se cruzó es el de Zcash: en mayo de 2026, con Claude Opus 4.8 recién publicado, un ingeniero de seguridad dirigió al modelo sobre el circuito Orchard y en unas 28 horas señaló el fallo que permitía falsificar ZEC y que llevaba cuatro años oculto a auditorías humanas.

¿Se puede atribuir a un agente de IA algún hackeo cripto de julio de 2026?

No. Y conviene decirlo con todas las letras, porque el tema se presta al titular fácil. A 2 de agosto de 2026 no existe ni un solo informe forense público —de SlowMist, PeckShield, Blockaid, CertiK o Chainalysis— que atribuya ninguno de los ocho incidentes de la semana a un agente autónomo de inteligencia artificial. Los vectores documentados son claves comprometidas, permisos mal configurados, una codificación de firma ambigua y un pool manipulable con flash loan. Todos ellos están al alcance de un atacante humano competente y todos ellos se han visto antes.

Lo que sí está documentado ocurre fuera del perímetro cripto y con fuentes que se pueden citar por fecha:

• Google Threat Intelligence Group, 11 de mayo de 2026: primer caso documentado de un exploit de día cero —un bypass de doble factor sobre una herramienta de administración de sistemas— desarrollado con ayuda de un modelo, detectado antes de su explotación masiva. El mismo informe describe al grupo de amenaza APT45 enviando miles de prompts (instrucciones de texto al modelo) repetitivos para analizar CVEs de forma recursiva y validar pruebas de concepto.
• Anthropic, 3 de junio de 2026: análisis de 832 cuentas bloqueadas por actividad maliciosa entre marzo de 2025 y marzo de 2026. El 67,3 % (560 cuentas) usaba el modelo para escribir malware; la proporción de actores clasificados como riesgo medio o superior pasó del 33 % en el primer semestre analizado al 56 % en el segundo.
• Anthropic, 13 de noviembre de 2025: la campaña GTG-1002, primera operación de ciberespionaje orquestada por IA que se ha reportado, contra unas 30 entidades, con el modelo ejecutando entre el 80 % y el 90 % de las tareas de forma autónoma tras ser engañado para creer que hacía pruebas defensivas.

De ahí se deduce que la capacidad existe y que ya se ha usado contra objetivos corporativos y gubernamentales. No se deduce que se haya usado contra un puente cross-chain. Cuando publicamos la alarma de OpenZeppelin sobre la superficie de ataque «superhumana» en DeFi, el recuento a 1 de junio era de cero hackeos cripto atribuidos a IA. Casi dos meses y sesenta millones de dólares después, ese recuento sigue en cero. Julio se explica sin necesidad de agentes: los protocolos cayeron por deuda de seguridad acumulada.

El lado defensivo sí tiene ya su precedente cripto verificado: el fallo del circuito Orchard de Zcash que permitía acuñar ZEC falsos, oculto durante cuatro años, lo encontró un modelo. En la mitad que corre rápido, cripto ya está dentro.

¿Qué registraron los logs de cleansky.io la semana del 20 de julio?

Tenemos una ventana pequeña pero propia sobre el ruido automatizado, y esa semana devolvió algo que merece contarse. Los logs de acceso de cleansky.io registraron unos 2.058 sondeos de vulnerabilidad entre el 20 y el 27 de julio: peticiones a rutas que en un sitio estático de contenido no existen ni pueden existir. Nada extraordinario en volumen para un dominio con tráfico moderado.

Lo llamativo fue una campaña procedente de cinco direcciones IP de Google Cloud que se presentaba con el user-agent del rastreador de Anthropic —las cadenas anthropic-ai y Claude-SearchBot— mientras pedía /config/secrets.yml, /terraform.tfstate y /ssl/server.key. Ninguna de esas rutas tiene sentido para un indexador de contenido; las tres son cosecha de credenciales de infraestructura. El rastreador real de Anthropic opera desde el bloque 216.73.216.x que la propia empresa publica como origen de sus crawlers, y esas cinco IPs no estaban en él. La cadena de user-agent es texto libre que cualquiera puede escribir.

La lectura útil es de segundo orden: hoy el escaneo masivo se disfraza de IA porque disfrazarse de IA funciona para atravesar filtros. Muchos operadores han metido en la lista blanca a los rastreadores de modelos para no perder visibilidad, y esa lista blanca se ha convertido en una puerta. Verificar por rango de IP y no por cadena declarada cuesta cinco minutos de configuración y ya no es opcional.

¿Por qué CertiK, SlowMist y TRM Labs no dan la misma cifra de 2026?

Cualquiera que intente medir si la corrección está ganando terreno se topa con que las tres firmas de referencia —las auditoras de seguridad CertiK y SlowMist y la firma de analítica forense on-chain TRM Labs— publican cifras distintas para el mismo semestre. No es un error de nadie: cada una cuenta un perímetro diferente y ninguna lo esconde.

La conclusión que sí comparten es la que da título al análisis de CertiK del 17 de julio: menos ataques, pero mucho más quirúrgicos. Casi el 44 % de las pérdidas del semestre salió de dos incidentes de abril —Kelp DAO y Drift Protocol—, ambos por fallos operativos y de infraestructura. El detalle completo del semestre está en el balance de los 207 hackeos del primer semestre, y el histórico largo, en la cronología de los mayores hackeos cripto.

La métrica que más dice sobre la velocidad de reacción no es la de pérdidas, sino la de recuperación. SlowMist contabiliza en el primer semestre de 2026 unos 118 millones de dólares congelados o devueltos en los 18 incidentes donde hubo intento de recuperación (que sumaban 389 millones robados): el 12,3 % de las pérdidas totales del semestre. En los ocho casos de la semana del 19 al 27 de julio, dos protocolos ofrecieron recompensa al atacante y ninguno había recuperado nada al cierre de estas cifras.

¿Qué señales de la brecha detección-corrección conviene vigilar hasta diciembre de 2026?

La señal que de verdad cambiaría este análisis es una sola: la primera atribución forense. Ninguna firma ha firmado todavía un informe que atribuya un exploit cripto a un agente autónomo, y cuando ocurra importará quién lo firma y con qué evidencia — la orquestación de un modelo deja rastro en los prompts y en los patrones de código, no en la blockchain. Las otras dos varas de medir ya están en las cifras de arriba: la tasa de recuperación (la línea base del 12,3 % mejora si el año cierra por encima del 20 %) y el recuento de protocolos que caen dos veces por la misma clase de bug, que la semana del 19 de julio dejó en dos.

Hasta entonces, la recomendación práctica para quien tiene fondos en un protocolo es la más aburrida y la más rentable: comprobar si el proyecto publicó post-mortem de su último incidente, si el arreglo prometido llegó a todos sus despliegues —no solo al de la cadena donde ocurrió el ataque— y cuánto tardó en pausar el contrato la última vez.

Fuentes y enlaces: CoinDesk (Allbridge Core, 20-jul) · CoinDesk (AFX Trade, claves del puente) · CryptoTimes (análisis técnico del fallo de firma de Wanchain) · crypto.news (Verus, segunda vez por la misma ruta) · CryptoTimes (Triple-A, 31 horas de drenaje) · TechTimes (el arreglo de 2023 que no llegó a Solana) · The Block (PeckShield, junio de 2026) · Forbes (CertiK: «menos pero más quirúrgicos») · SlowMist (informe semestral 2026) · Anthropic (832 cuentas mapeadas a MITRE ATT&CK, 3-jun-2026) · Anthropic (campaña GTG-1002, 13-nov-2025) · Google Threat Intelligence Group (11-may-2026) · Google DeepMind (CodeMender, 72 arreglos) · Help Net Security (modelo especializado en vulnerabilidades, 22-jul-2026) · XBOW (más de 1.000 informes enviados en HackerOne)