Google GTIG identificó el primer zero-day desarrollado por IA in the wild. Y el código dejó la firma. Según el reporte publicado el 11 de mayo, actores criminales usaron IA para descubrir y armar una vulnerabilidad en una herramienta popular de administración de sistemas open-source. El exploit era un bypass de 2FA vía script Python. La causa raíz: una falla semántica de lógica (hardcoded trust assumption), el tipo de vulnerabilidad que los LLMs encuentran bien y los fuzzers tradicionales no. Seguimos esta evolución de cerca y el escenario es claro: la superficie de ataque acaba de expandirse a clases enteras que nuestras herramientas tradicionales no cubren.
La firma de IA en el código de exploit
Google GTIG determinó que el exploit fue desarrollado con apoyo de IA por cuatro marcadores inequívocos. Primero, docstrings educacionales en abundancia: ningún atacante humano escribe comentarios didácticos en exploit code. Segundo, CVSS alucinado: el script contenía un score de severidad fabricado que no existe en ninguna base de datos. El modelo inventó el número. Tercero, formato Pythonic estructurado y de manual: código limpio, anotado, estilo de datos de entrenamiento de LLM. Cuarto, menús de ayuda detallados y clase ANSI colorida pulida: código de exploit excesivamente refinado para el propósito criminal.
Google declaró tener "alta confianza de que el actor usó un modelo de IA para apoyar el descubrimiento y armamento de esta vulnerabilidad". No fue Gemini. No fue Mythos. Modelo comercial no identificado. El plan era uso masivo: Google lo descubrió proactivamente antes de la campaña de explotación a gran escala. El vendor corrigió. Errores en la implementación del exploit probablemente interfirieron con el éxito de los criminales. Pero el hecho de que el ataque no haya alcanzado escala no disminuye el hito: la IA ya está descubriendo y armando vulnerabilidades que humanos y herramientas tradicionales no encuentran.
La clase de vulnerabilidad que cambia el juego
Aquí está el punto que importa para quien defiende infraestructura: el tipo de bug que la IA encuentra es diferente del que encuentran los fuzzers. El espejo es esclarecedor. En octubre de 2024, Big Sleep (Project Zero + DeepMind) encontró un zero-day en SQLite: IA defensiva encontrando vulnerabilidades para corregir. Ahora, según Google GTIG, IA ofensiva encontrando vulnerabilidades para explotar. Misma capacidad, intención opuesta.
Pero la diferencia de clase de vulnerabilidad importa. Big Sleep encontró un bug de seguridad de memoria, un stack buffer underflow en SQLite. El zero-day criminal es una falla semántica de lógica. Los LLMs razonan sobre la intención del desarrollador. Los fuzzers no. Esto expande la superficie de ataque a clases enteras que las herramientas tradicionales no cubren. Un fuzzer prueba límites de memoria y entradas malformadas. Un LLM lee el código, entiende lo que el desarrollador quiso hacer, y encuentra dónde se rompió la lógica. Es una categoría de vulnerabilidad fundamentalmente diferente.
Para nosotros, que operamos seguridad ofensiva a diario, esta distinción es práctica, no teórica. Cuando auditamos una aplicación, las fallas semánticas de lógica, bypass de autorización, trust assumptions incorrectos y flujos de autenticación rotos son exactamente las que exigen razonamiento humano. Hasta ahora, eran las más difíciles de encontrar automáticamente. Ahora, un LLM con acceso al código fuente puede identificarlas en minutos.
La compresión del tiempo y el contexto APT
Los números de Cogent Research (27 de mayo) son contundentes: el tiempo de CVE disclosure a exploit funcional cayó de 125,3 días (enero 2025) a 0,5 días (abril 2026). 62% de las CVEs críticas tenían exploits antes de la detección por scanners. Eso son vulnerabilidades conocidas. El zero-day de Google GTIG es el próximo nivel: IA encontrando vulnerabilidades desconocidas.
Y el contexto del mismo reporte muestra que la adopción de IA por los APTs es amplia. Según Google GTIG, APT45 (Corea del Norte) envía miles de prompts para analizar CVEs y validar PoCs. UNC2814 (China) usa jailbreaks con persona para investigación de vulnerabilidades en dispositivos embebidos. APT27 (China) usa Gemini para la gestión de red ORB. PROMPTFLUX/HONESTCUE usa API de Gemini para ofuscación dinámica. No es un actor aislado, es un ecosistema.
Según John Hultquist, analista jefe del GTIG: "Hay una concepción equivocada de que la carrera de vulnerabilidades por IA es inminente. La realidad es que ya comenzó."
Vemos esta compresión del tiempo en la práctica. Un cliente nuestro tuvo una CVE crítica explotada en menos de 24 horas tras el disclosure este año. Cuando la ventana de tiempo se mide en horas, el proceso manual de evaluación, priorización y patching no acompaña. La automatización ya no es aspiracional: es requisito de supervivencia.
Qué significa esto para la defensa corporativa
La carrera ya no es si los zero-days de IA se volverán comunes. Es qué tan rápido. Y la respuesta ya no es fuzzing, es análisis semántico. Operamos seguridad ofensiva para clientes corporativos y lo que vemos en el campo confirma: las herramientas que protegían infraestructura ayer no cubren las clases de vulnerabilidad que la IA descubre hoy.
Las herramientas de análisis estático tradicionales buscan patrones conocidos. Los fuzzers prueban límites de memoria. Ninguna de las dos modela la intención del desarrollador. Cuando un LLM lee un código de autenticación e identifica que el desarrollador asumió confianza hardcoded (hardcoded trust assumption) en lugar de validar explícitamente, eso es razonamiento sobre semántica, no sobre sintaxis.
En Tech86, nuestra práctica de seguridad ofensiva simula exactamente este tipo de razonamiento. No dependemos solo de fuzzers y scanners: nuestro proceso de pentest incluye análisis semántico de lógica de autorización, trust assumptions embebidos en el código (hardcoded) e inconsistencias de modelo de amenaza (threat model). Cuando el atacante usa IA para encontrar fallas de lógica, la defensa necesita usar la misma clase de razonamiento para anticiparlas.