Zero-day con IA: el caso de Google, sus marcadores y lo que no sabemos

El 11 de mayo de 2026, Google Threat Intelligence Group publicó un reporte sobre el uso de inteligencia artificial en operaciones ofensivas. Entre varios hallazgos —malware autónomo, ataques a infraestructura de IA, campañas de desinformación— uno acaparó los titulares: "por primera vez, identificamos un actor usando un exploit de día cero que creemos fue desarrollado con IA."

La evidencia presentada son marcadores estilísticos en el código: un CVSS score que no existe en ninguna base de datos CVE, docstrings con formato textbook característico de LLMs, y una vulnerabilidad de tipo semántico —un hardcoded trust exception— que Google señala como consistente con las capacidades actuales de los modelos de lenguaje.

Ninguno de esos marcadores distingue entre "un LLM descubrió la vulnerabilidad autónomamente" y "un humano usó un LLM para escribir el código." Esa distinción importa, y el reporte no la aborda.

---

La evidencia: tres marcadores

Google dijo tener "high confidence" de que una IA descubrió y armó el exploit. Su evidencia son tres marcadores en el código Python.

1. El CVSS que no existe

El script contenía una puntuación CVSS que no figura en ninguna base de datos CVE. Google argumenta que ningún atacante humano incluiría una métrica de severidad inventada en su propio exploit. Es cierto. Pero eso no prueba que la IA encontró la vulnerabilidad. Prueba que el código del exploit —o una parte— fue generado por un LLM. Son dos cosas distintas.

Un atacante pudo identificar manualmente el error lógico en el flujo de 2FA y luego pedirle a un LLM: "escribime un exploit para esto." El resultado tendría exactamente las mismas huellas: CVSS inventado, código limpio, comentarios explicativos. La evidencia de Google no distingue entre "la IA encontró la vuln" y "un humano usó IA para escribir el exploit."

Estos "hallucinated CVSS scores" son un comportamiento conocido en las respuestas de LLMs cuando se les pide generar código: tienden a incluir metadata que parece real pero no lo es. Su presencia indica que el código pasó por un LLM, pero no permite determinar si el modelo descubrió la vulnerabilidad o simplemente escribió el código que un humano le pidió.

2. Docstrings educativos y formato textbook

El exploit tenía comentarios excesivamente largos y estructura limpia. Google lo describe como "altamente característico de datos de entrenamiento de LLM". No hay ninguna diferencia entre "un atacante le pidió a una IA que genere el exploit" y "una IA descubrió la vulnerabilidad y generó el exploit" en términos del formato del código resultante. El output es el mismo.

Estas huellas pueden eliminarse con instrucciones adicionales al modelo —por ejemplo, solicitando código sin comentarios ni metadata— lo que sugiere que la ventana de detección basada en este tipo de marcadores es inherentemente limitada.

3. El "semantic logic flaw"

La vulnerabilidad no era un buffer overflow ni una SQL injection. Era un error de lógica semántica: el desarrollador hardcodeó una excepción de confianza en el flujo de 2FA. Google argumenta que los fuzzers y scanners estáticos no detectan este tipo de bugs.

Es cierto. Pero un humano con experiencia haciendo code review también detecta ese error. No es una capacidad exclusiva de la IA. Google señala que no sabe qué modelo se usó y que no fue Gemini ni Mythos.

---

No es la primera vez

Google presentó su hallazgo como "la primera vez." Existen antecedentes similares que conviene considerar.

Fecha	Reportado por	Titular	Qué ocurrió realmente	Fuente
Nov 2023	Check Point	"AI encontró un zero-day"	LLM usado como asistente de code review. Humanos confirmaron.	[2]
Ene 2026	Check Point	"Malware generado casi totalmente por IA"	Una persona usando IDE con IA. Nunca en producción.	[3]
Mar 2026	MAD Bugs	"Claude escribió un kernel RCE"	Claude exploitó CVE conocida. Laboratorio acotado.	[4]
May 2026	Google GTIG	"Primer zero-day con IA"	Código con marcas de LLM. Vendor parchó.	[1]

---

Una prueba concreta

El 17 de mayo de 2026, usando un modelo de 2 mil millones de parámetros (huihui-qwen3.5-2b) corriendo en un laptop, generamos el mismo estilo de código que Google usó como evidencia:

"""
CVSS Score: 9.7 - Critical
"""

class Hardcoded2FAExploit:
    def _hardcoded_trust_exception(self, user_input):
        """Implementa la excepción hardcoded.
        Permite acceso sin verificar el token OTP."""
        return True

El resultado incluye un CVSS inventado, docstrings educativos, y una estructura textbook —los mismos marcadores que Google utilizó en su análisis.

---

Google detectó este caso porque el código contenía marcadores estilísticos que delataban su origen en un LLM. Si Google, con su acceso y telemetría, identificó el exploit por estas huellas —¿qué no están viendo el resto de los equipos de CTI?