El primer zero-day generado con IA: lo que Google encontró esta semana

El Google Threat Intelligence Group (GTIG) publicó esta semana un informe que muchos llevábamos meses anticipando. La descripción es escueta, casi clínica. La implicación, no.

Por primera vez documentada, un actor de crimen cibernético desarrolló un exploit zero-day con ayuda de inteligencia artificial y lo metió en producción. La vulnerabilidad: un bypass de autenticación de dos factores en una popular herramienta de administración web open source. El plan: usarlo en un evento de explotación masiva. Google lo cortó antes de que ocurriera y coordinó la divulgación responsable con el vendor afectado.

El zero-day no era un fallo de memoria ni una entrada mal validada. Era un fallo de lógica de diseño: el desarrollador había dejado una suposición de confianza dentro del código que volvía la verificación 2FA esquivable bajo condiciones específicas. Justo el tipo de fallo que ningún scanner de código tradicional encuentra y que un LLM detecta porque lee la intención del desarrollador.

Hasta aquí la noticia. La parte que importa para un CISO es lo que viene después.

Esto cambia el escalón de amenazas — y lo hace esta semana

Durante los últimos dos años, todas las conversaciones serias sobre IA ofensiva terminaban en el mismo párrafo: "todavía no se ha visto un zero-day desarrollado con IA en producción". Esa frase ya no se puede usar.

John Hultquist, jefe de análisis de GTIG, lo dijo sin medias tintas:

"Está aquí. La era de la explotación de vulnerabilidades con IA ya está aquí."

No es teoría. Es una operación que iba a salir esta semana y que tuvo que ser frustrada activamente. Si no quieres mi opinión sobre por qué duele, vete al plan de acción al final. Si quieres entender por qué pasa esto ahora, sigue leyendo.

Anatomía del exploit: cómo se sabe que lo escribió una IA

GTIG no afirma a la ligera que un exploit fue generado por un LLM. Los indicadores son forenses, no especulativos. Lo describen así:

"Aunque no creemos que se haya usado Gemini, basándonos en la estructura y el contenido de estos exploits tenemos alta confianza de que el actor probablemente aprovechó un modelo de IA para apoyar el descubrimiento y weaponización de esta vulnerabilidad."

Los marcadores forenses son los típicos de un texto generado por un LLM:

• Docstrings demasiado bien escritos: cada función trivial venía documentada con ejemplos de uso y explicaciones pedagógicas. En el código real de un exploit, el atacante escribe lo mínimo para que funcione.
• Una puntuación CVSS inventada dentro del propio código: ningún humano mete eso en un exploit funcional. Los LLMs sí, porque ven ese patrón mil veces en los blogs de seguridad con los que se entrenan.
• Estilo "Python de manual": clases auxiliares bien nombradas, menús de ayuda elaborados, comentarios pedagógicos. Lectura como de un libro "Python para hackers", no como código de operación real.

Ninguno de estos indicadores es concluyente por sí solo. En conjunto producen una huella reconocible: una vez que sabes mirar, la ves.

Pero el detalle que me parece más interesante no es ese. Es la naturaleza de la vulnerabilidad.

Por qué tu scanner de código no va a ver esto

El zero-day no es un fallo de memoria ni una entrada mal saneada. Es lo que GTIG llama un "dormant logic error": un fallo de lógica que parece correcto desde fuera, pero está estratégicamente roto desde el punto de vista de seguridad.

Los scanners de código tradicionales buscan patrones conocidos: "esta función puede desbordar memoria, esta entrada no está validada". Un LLM, en cambio, lee la intención del desarrollador — y detecta cuando esa intención contradice lo que el código hace realmente. Es la diferencia entre "este código compila" y "este código asume que nadie llegará aquí con un token caducado, pero el caso existe".

Esto preocupa por dos razones. La evidente: las defensas que tenemos están construidas para una clase de fallos que ya no agota la superficie de ataque. La menos evidente: los LLMs van a encontrar fallos que ya están en tu código, esperando. No los están creando. Los están descubriendo. Y antes los descubrías tú (o nadie).

Trabajo en el sector nuclear — un entorno determinista, auditado, donde una suposición hardcodeada se considera un defecto. Esa cultura de revisión no existe en la mayoría del software empresarial. Y ese gap es precisamente el terreno fértil que los modelos están empezando a recolectar.

El zero-day no viene solo: el catálogo completo

El exploit es la pieza más visible del informe, pero no la única. GTIG documenta también cinco grupos estado-nación (China, Rusia, Corea del Norte) que ya usan IA en sus operaciones, y cinco familias de malware que llaman a un modelo en la nube durante la ejecución para decidir qué hacer a continuación.

El patrón que conecta a todos es el mismo: la barrera de entrada al uso ofensivo de IA está cayendo en vertical. Quien no puede pagar 200 euros al mes por developer automatiza el registro de cuentas premium nuevas. Quien sí puede pagarlas, las agrega en pools compartidos para escalar. Quien tiene infraestructura monta agentes que se conectan solos contra entornos vulnerables. Cada grupo encuentra el escalón que se puede permitir.

Y hay un detalle que conviene fijar: existe un repositorio público con más de 85.000 casos reales de vulnerabilidades documentadas (proviene del bug bounty chino WooYun, periodo 2010–2016) que actores ofensivos están integrando como plugin de Claude Code. Es decir: cualquier atacante con un asistente de programación puede ahora preguntarle "¿qué fallos de este catálogo aplicarían a este código?" y recibir respuestas accionables. Suena a ciencia ficción. Está documentado.

El caso de malware que más conviene tener en la cabeza es PROMPTSPY: un backdoor de Android que, antes de actuar, envía la pantalla del móvil infectado a Gemini, recibe coordenadas "toca aquí, desliza allá" y simula los gestos. Captura PINs y patrones biométricos repitiendo la secuencia. Si intentas desinstalarlo, dibuja una capa invisible sobre el botón "Desinstalar" e intercepta los toques. Léelo otra vez: un malware que pregunta a un modelo dónde tocar tu pantalla. Esa es la nueva normalidad.

Y conviene tener presente la otra mitad del problema: mientras la IA descubre fallos a velocidad máquina, la IA también los está introduciendo en código nuevo a la misma velocidad. Lo analizo con datos verificables en los riesgos del vibe coding y el triángulo que rompió el modelo AppSec — caso Sicarii incluido. El ciclo es perfecto y se cierra solo.

Y el supply chain detrás de todo

En marzo de 2026, un grupo de amenaza comprometió cuatro proyectos open source ampliamente usados en infraestructura IA — entre ellos LiteLLM, la pasarela que muchas organizaciones usan para integrar Claude, GPT y Gemini detrás de una sola API. El método: paquetes envenenados en PyPI y pull requests maliciosos. El objetivo: robar claves de AWS y tokens de GitHub de los entornos de compilación. Las credenciales acaban revendiéndose a grupos de ransomware.

El mensaje práctico es directo: si tu equipo de plataforma instaló cualquiera de esos paquetes antes de marzo y no rotó credenciales, asume que tus claves de IA están en mercado. Lo explico con más detalle en el contexto del vector OAuth de Shadow AI que tu inventario no ve — es exactamente cómo Vercel acabó con su base de datos a la venta por 2 millones de dólares.

Big Sleep y CodeMender: Google jugando en el mismo campo

La parte menos contada del informe es que Google también está en el otro lado del tablero. Big Sleep, agente IA conjunto de DeepMind y Project Zero, ya encontró su primera vulnerabilidad real en producción y, según GTIG, ayudó a cortar otra que estaba a punto de ser explotada por actores de amenaza.

CodeMender, también de Google, va un paso más allá: agente experimental que parchea automáticamente vulnerabilidades críticas usando Gemini, sin intervención humana en el bucle inmediato.

El subtexto estratégico es claro: si los atacantes usan LLMs para descubrir fallos a velocidad máquina, los defensores tienen que jugar al mismo juego o quedarse atrás de forma estructural. No es un upgrade opcional. Es un cambio de régimen.

Y mientras pasa esto, en Europa el Digital Omnibus aplazó las obligaciones de alto riesgo del EU AI Act hasta 2027. La ventana de adaptación regulatoria existe. La ventana de adaptación de amenazas, no.

Mi opinión como CISO — lo que cambia desde hoy

Tres cosas para sentarse a pensar.

Primera: lo que más asusta del informe no es el exploit, es lo del catálogo WooYun. Cuando un atacante con un asistente de programación y un repositorio de 85.000 vulnerabilidades enchufado puede preguntar "¿qué fallos aplicarían a este código?", la asimetría histórica entre atacante (paciente, especializado) y defensor (ocupado, generalista) deja de existir. La barrera se derrumba.

Segunda: el exploit tiene patrones reconocibles, pero el flujo del actor que lo usa, no. Un grupo criminal con acceso a un modelo, un puñado de cuentas premium compartidas y suficiente paciencia puede generar, validar y desplegar exploits contra tu organización sin que tu equipo de SOC vea nada anómalo en la red. El tráfico que sale es una llamada a la API de Gemini. Hoy por hoy, en la mayoría de tus reglas, eso no se diferencia del compañero de marketing pidiéndole a ChatGPT que le escriba un email.

Tercera, y la más incómoda: yo tampoco tengo resuelto cómo distinguir al developer cumplidor que pide a Gemini que le refactorice una función del developer comprometido (o el insider) que pide a Gemini que le encuentre vulnerabilidades en el código corporativo. Es exactamente la misma llamada API. Lo único que las distingue es el contenido del prompt, y registrar contenido de prompts en una empresa con empleados en la UE es abrir un problema GDPR de proporciones bíblicas.

Ese gap entre "tengo política" y "tengo medición" es el agujero por el que va a pasar todo en los próximos 18 meses.

Plan de acción — 7 cosas para hacer esta semana

Si me preguntase otro CISO por dónde empezar esta semana, le pasaría estos siete puntos. Ni más ni menos.

1. Saber qué IA usan los developers — de verdad

Encuesta directa: ¿qué herramientas de IA usas para escribir, revisar o refactorizar código corporativo? Cruzar con los logs del proxy corporativo hacia los servicios de Gemini, Claude y OpenAI. La diferencia entre lo declarado y lo medido es tu superficie de ataque oculta. Sin ese cruce, todo lo demás es opinión.

2. Auditar las dependencias open source de tu plataforma IA

Inventario completo de las librerías que tu equipo de plataforma usa para integrar IA. Foco especial en las que actúan como pasarela a múltiples modelos (LiteLLM, BerriAI) y en las que reciben código fuente entero (Trivy, Checkmarx) — las cuatro fueron comprometidas en marzo. Si tu equipo instaló alguna antes de la rotación de credenciales y no rotó claves, asume que tus tokens de IA están en venta.

3. Parchear los frameworks que dan herramientas a un LLM

Microsoft publicó la semana pasada dos vulnerabilidades críticas en Semantic Kernel donde un único prompt malicioso ejecuta código arbitrario en el servidor. Actualizar las versiones afectadas y revisar los demás frameworks agénticos del entorno (LangChain, AutoGen, CrewAI, Pydantic AI) por superficies similares. El framework es la superficie de ataque, no el modelo.

4. Marcar el código sospechoso de venir de un LLM

Reglas de revisión (señalización, no bloqueo) que marquen pull requests con docstrings excesivamente educativos, comentarios estilo tutorial o puntuaciones CVSS hardcodeadas dentro del código. No es una defensa final — es un canario. Pero si salta, alguien debería mirar dos veces.

5. Cuentas corporativas de IA con vigilancia real

Inventario de las cuentas de Gemini, Claude y OpenAI que paga la empresa. Activar el registro de actividad y alertas por uso anómalo — el patrón típico de un actor automatizado son miles de prompts en una ventana corta. Si tu equipo de seguridad no puede contestar "¿quién usa qué IA para qué?", ese es el primer agujero.

6. Bloquear las pasarelas que sirven para saltarse la política

El informe de Google nombra varias herramientas (CLIProxyAPI, Claude-Relay-Service y similares) que existen exclusivamente para anonimizar el acceso a modelos comerciales y compartir cuentas premium entre múltiples usuarios. Añadirlas a la lista de bloqueo del proxy corporativo. Si aparece tráfico saliente hacia ellas, alguien dentro está intentando esquivar la política.

7. Revisar los permisos OAuth a aplicaciones SaaS de IA

Cualquier app SaaS de IA con permisos OAuth sobre tu Google Workspace o Microsoft 365 es un vector de supply chain. Lista todas las concesiones activas, compáralas con las aprobadas oficialmente y aplica política de allowlist sobre el resto. El paso a paso completo lo desarrollé en el artículo sobre Shadow AI 2.0 y los OAuth scopes.

Para cerrar

Hultquist (GTIG) lo dijo así:

"Está aquí. La era de la explotación de vulnerabilidades con IA ya está aquí."

Es una de esas frases que tiene la mala costumbre de ser cierta.

La parte importante no es que pasó. La parte importante es que el actor lo iba a usar en un evento de explotación masiva. No era un experimento académico, no era un PoC de papers. Era ofensa lista para escalar a miles de objetivos a la vez. Google lo cortó esta vez. La próxima no la va a cortar Google.

La pregunta para tu próximo comité de seguridad: ¿cuántas integraciones IA tienes ahora mismo en producción de las que no sabes quién las usa, qué dependencias tienen y qué clave API gobierna su acceso? Si la respuesta es "no lo sé", ya tienes la primera tarea del lunes.

Yo tampoco la tengo del todo resuelta. Pero la diferencia entre tenerlo resuelto y no tenerlo resuelto va a marcar quién explica un incidente con dignidad y quién lo explica con un comunicado raro a las tres de la mañana.

Fuentes

• Google Cloud · GTIG Report — AI vulnerability exploitation initial access (informe primario, mayo 2026).
• The Hacker News — Hackers used AI to develop first known zero-day exploit.
• CNBC — Google thwarts hacker group's AI mass exploitation event.
• ESET Research — PROMPTSPY ushers in era of Android threats using GenAI (primer descubrimiento del backdoor Android).
• Microsoft Security Blog — Prompts become shells: RCE vulnerabilities in AI agent frameworks (CVE-2026-26030 / CVE-2026-25592).