- Agentes basados en Opus 4.5 y GPT-5.2 generaron más de 40 exploits en 6 escenarios usando una vulnerabilidad zero-day en QuickJS
- GPT-5.2 resolvió todas las tareas, y Opus 4.5 resolvió todas excepto dos, mostrando capacidad autónoma de análisis de código, depuración y construcción de cadenas de exploit
- Los resultados del experimento sugieren que el desarrollo de exploits podría estar limitado por el rendimiento de tokens y no por la cantidad de hackers humanos
- La detección de vulnerabilidades y la generación de exploits ya llegaron a una etapa en la que el rendimiento aumenta en proporción a la cantidad de tokens invertidos
- Se enfatiza la necesidad futura de automatizar los ciberataques y rediseñar los sistemas de evaluación de seguridad
Resumen del experimento
- Se realizó un experimento de generación de exploits usando Opus 4.5 y GPT-5.2 sobre una vulnerabilidad zero-day en el intérprete de JavaScript QuickJS
- Se aplicaron diversas técnicas de mitigación de exploits (ASLR, NX, RELRO, CFI, shadow stack, seccomp, etc.)
- Los agentes lograron varios objetivos, como obtener una shell, escribir archivos y conectar con C2
- GPT-5.2 resolvió todos los escenarios, y Opus 4.5 resolvió todas las tareas excepto dos
- Cada ejecución tuvo un límite de hasta 30 millones de tokens, con un costo aproximado de 30 dólares
- En la tarea más difícil, la solución requirió 50 millones de tokens, unas 3 horas y 50 dólares
- GPT-5.2 completó un exploit de escritura de archivos en un entorno con sandbox seccomp y shadow stack habilitados mediante una llamada funcional en 7 etapas usando la cadena de handlers de salida de glibc
Limitaciones del experimento
- QuickJS es mucho más pequeño y menos complejo que un motor de navegador real, por lo que hay límites para generalizar los resultados
- Los exploits generados no descubrieron nuevas vulnerabilidades en las propias mitigaciones, sino que aprovecharon puntos débiles de despliegue ya conocidos
- La vulnerabilidad de QuickJS sí fue descubierta recientemente, y la forma en que GPT-5.2 la resolvió se evalúa como una nueva construcción de cadena no documentada previamente
La industrialización de la intrusión
- “Industrialización” se refiere a un estado en el que la capacidad ofensiva de una organización está determinada no por su personal, sino por el rendimiento de tokens
- Para ello se requieren dos condiciones
- Que los agentes basados en LLM puedan explorar de forma autónoma dentro del entorno
- Que exista un sistema de verificación preciso y rápido
- El desarrollo de exploits es un caso ideal que cumple estas condiciones
- Es fácil montar el entorno, y el proceso de verificación es claro
- Ejemplo: en un exploit para obtener una shell, se puede verificar el éxito de la conexión mediante un port listener
- En cambio, la intrusión, la escalada de privilegios, el mantenimiento de acceso persistente y la exfiltración de datos que requieren interacción en tiempo real son más difíciles de industrializar
- Porque un comportamiento incorrecto en un entorno real puede llevar a la detección
Etapa actual
- La detección de vulnerabilidades y el desarrollo de exploits ya muestran un rendimiento que crece en proporción a la inversión de tokens
- En el proyecto Aardvark de OpenAI se observó la misma tendencia
- En el experimento, el límite fue el presupuesto, no el desempeño del modelo
- La automatización del hackeo dentro de redes reales sigue siendo incierta
- Según un informe de Anthropic, hubo un caso de un grupo de hackers chino que intentó ataques usando la API
- Sin embargo, no existen casos comercializados de agentes totalmente automatizados de SRE (ingeniería de confiabilidad del sitio)
- Si la automatización de SRE tiene éxito, es muy probable que también sea posible el hackeo automatizado dentro de redes adversarias
Conclusión y recomendaciones
- Este experimento cambia la percepción sobre el alcance y el momento de la automatización posible en el ámbito cibernético
- Los métodos actuales de evaluación de modelos (CTF, vulnerabilidades antiguas, datos sintéticos) son inadecuados para medir la capacidad real de ataques zero-day
- Los laboratorios frontier y las instituciones de seguridad de IA deberían realizar evaluaciones sobre objetivos zero-day reales (por ejemplo, Linux kernel, Firefox)
- Se necesitan reportes públicos del tipo: “se usaron X cientos de millones de tokens para generar Y exploits”
- También se necesitan evaluaciones sobre equipos reales, como firmware de IoT
- Se plantea la posibilidad de que agentes basados en Opus 4.5 o GPT-5.2 puedan generar exploits prácticos en el plazo de una semana
- Se recomienda a investigadores e ingenieros realizar experimentos directamente y publicar los resultados
- El código y los datos del experimento están disponibles en un repositorio de GitHub
1 comentarios
Opiniones en Hacker News
Le pidieron a GPT‑5.2 como tarea más difícil que encontrara cómo escribir una cadena en una ruta específica del disco
Era un entorno QuickJS con todas las protecciones activadas: ASLR, memoria no ejecutable, full RELRO, CFI fino, hardware shadow‑stack y sandbox seccomp
GPT‑5.2 resolvió el problema usando la cadena de exit handlers de glibc con una llamada de funciones de 7 pasos. Fue un resultado realmente sorprendente
La mayoría de los exploits reales avanzan en este orden: primero “encontrar la vulnerabilidad (difícil)” y luego “atravesar varias capas de mitigaciones inútiles (molesto pero posible)”
Las mitigaciones probabilísticas funcionan contra ataques probabilísticos, pero los atacantes encuentran debilidades de forma intencional
En el futuro probablemente nos arrepentiremos de no habernos pasado antes a WASM
Hasta entonces seguiremos pegando mitigaciones de hardware por todos lados mientras tratamos de contener el viejo problema del overwrite del stack
Lo sé bien porque es mi trabajo, y cada vez siento más impotencia
Por ejemplo, filtrando punteros de libc con un Use‑After‑Free
En Rust sería mucho más difícil, aunque si hay muchas llamadas a libc sigue siendo complicado defenderse por completo
El exploit de GPT‑5.2 no rompió nuevas mitigaciones, sino que aprovechó huecos de implementación ya conocidos
Los hackers humanos tampoco suelen romper mitigaciones completamente nuevas
Aun así, en CTF ya es cada vez más común que los LLM resuelvan retos pwn de un solo intento
Gracias a este avance, probablemente colapsen las implementaciones incompletas de mitigaciones y se impulse la investigación en modelado formal de exploits
Visto desde la investigación en seguridad, la API de primitivas de lectura/escritura creada por el LLM no pasa de una simple recombinación de APIs existentes
Más que una técnica nueva, se parece a un binario de juguete para CTF
Eso sí, como los modelos recientes de OpenAI tienden a evitar generar código de exploit real, me da curiosidad si aquí se usó algún bypass de prompt
El autor señaló puntos interesantes, pero yo no estoy demasiado preocupado
Este tipo de herramientas también puede usarse de forma simétrica por parte de los defensores
Se podría agregar testing de seguridad automatizado en CI, por ejemplo ejecutando un “LLM Red Team”
El atacante solo tiene que acertar una vez, y el defensor tiene que acertar siempre
Los modelos actuales tienen un rendimiento pass@x entre 20% y 30% superior a maj@x
Aun así, si haces correr un loop de Red vs Blue, el nivel de seguridad debería mejorar
El atacante solo necesita encontrar un fallo, mientras que el defensor tiene que bloquearlo todo
Ejemplo: el proyecto Big Sleep de Google Project Zero
La lista de vulnerabilidades relacionadas puede verse aquí
El atacante puede armar algo explotable con un solo bug, pero el defensor tiene que encontrar todos los bugs
Es una asimetría del tipo “any vs all”
Al final, las empresas de LLM serán las verdaderas ganadoras, vendiendo tokens a ambos lados
Es interesante que Codex 5.2 haya encontrado el exploit más complejo
Yo también uso sobre todo Opus 4.5, pero el modo Extra High thinking de Codex 5.2 definitivamente es potente
No me creo eso de que el progreso de los LLM se haya frenado. Más bien, las tareas se volvieron tan difíciles que ya se nota menos
El log puede verse en este repositorio
Cada uno tiene su propio estilo
No se publican hasta que pierden valor comercial
QuickJS en realidad es un proyecto de juguete con muchas vulnerabilidades sin parchear
Sería más interesante ver un exploit en un objetivo real como curl
Conviven dos afirmaciones: que los LLM escriben grandes exploits y que también generan reportes de bugs inútiles
¿Pueden ser ciertas ambas cosas?
La calidad de un LLM depende del prompt del usuario y de su capacidad de interpretación
Si un experto lo usa de forma selectiva, puede obtener resultados excelentes
Los reportes generados automáticamente son una carga grande para los maintainers
Si solo le dices “encuentra vulnerabilidades en este programa”, va a decir muchas tonterías, pero
si le das un loop de pruebas y un entorno, mejora de forma iterativa hasta producir algo que de verdad funciona
En cambio, los reportes de bugs son ambiguos y difíciles de evaluar
Por ejemplo, si entre $100 tienes un problema real de $50 y 5000 reportes falsos de $0.01,
se vuelve difícil encontrar el diamante real
La explicación del sandbox era vaga, así que al principio me pareció sospechoso
Al ver el repositorio del autor, resultó que la meta era “escribir la cadena ‘PWNED’ en /tmp/pwned”
O sea, no era un escape del sandbox, sino una simple restricción de escritura de archivos
Incluso hacer que construyera una API de primitivas OOB R/W no fue más que reutilizar miles de ejemplos ya existentes en GitHub
Me impactó la frase: “en adelante, la capacidad de hackeo de un Estado u organización no estará determinada por la cantidad de hackers, sino por el throughput de tokens”
Que bajen al mismo tiempo las barreras de entrada para crear software y para hackear es una combinación explosiva
Ahora se necesita una nueva plataforma con guardrails de seguridad y verificabilidad
Es riesgoso depender de código hecho por personas no expertas