Project Glasswing: lo que mostró Mythos
(blog.cloudflare.com)- Mythos Preview fue más allá de detectar bugs individuales en más de 50 repositorios de Cloudflare y logró enlazar varios elementos primitivos para construir cadenas de explotación
- No se limitó a detectar bugs sospechosos: escribió código disparador, compiló y ejecutó pruebas temporales, y tras cada fallo ajustó sus hipótesis para producir una prueba de funcionamiento
- Incluso en investigación legítima de vulnerabilidades aparecieron rechazos espontáneos, pero variaban según el contexto y la redacción, por lo que carecían de la consistencia necesaria para usarlos como frontera de seguridad
- Los agentes de programación de propósito general tienen límites de cobertura en repositorios grandes y en exploración paralela, así que Cloudflare construyó un arnés para ejecutar tareas acotadas en paralelo
- Para los equipos de seguridad ya no basta con escanear y parchear más rápido; también importa la arquitectura que dificulta la explotación y el acceso incluso cuando existe un bug
Cómo Mythos Preview cambió la forma de investigar vulnerabilidades
- Durante los últimos meses, Cloudflare probó LLM enfocados en seguridad dentro de su propia infraestructura y recibió Mythos Preview de Anthropic como parte de Project Glasswing, aplicándolo a más de 50 repositorios propios
- Más que una simple mejora incremental sobre los modelos frontier de propósito general, Mythos Preview se pareció a una nueva herramienta capaz de ejecutar distintas etapas de la investigación de vulnerabilidades
- El cambio clave fue que no se quedó en enumerar bugs aislados, sino que combinó varios primitivos de ataque para construir una cadena de explotación
- En ataques reales, no suele usarse un solo bug: por ejemplo, un use-after-free puede convertirse en un primitivo de lectura/escritura arbitraria, luego en secuestro del flujo de control, y finalmente en una cadena ROP para obtener control del sistema
- Mythos Preview combinó este tipo de primitivos y los enlazó en pruebas funcionales, realizando un razonamiento más cercano al trabajo de un investigador experimentado que al de un escáner automático
- Otro cambio fue su capacidad para, después de encontrar un bug sospechoso, crear por sí mismo una prueba de funcionamiento
- Escribía código disparador, lo compilaba en un entorno temporal y luego lo ejecutaba
- Si funcionaba como se esperaba, eso servía como prueba; si fallaba, leía el resultado del fallo, ajustaba su hipótesis e intentaba de nuevo
- Un defecto sin prueba funcional sigue siendo una conjetura, pero Mythos Preview redujo por sí solo esa brecha
- En el mismo arnés, otros modelos frontier también encontraron algunos bugs base y en ocasiones razonaron más lejos de lo esperado, pero la diferencia apareció al momento de convertir múltiples piezas en una cadena real
- Mythos Preview pudo enlazar bugs que tradicionalmente habrían quedado en backlog como problemas de baja severidad y convertirlos en una explotación más grave
Rechazos del modelo incluso en investigación legítima de vulnerabilidades
- La versión de Mythos Preview proporcionada para Project Glasswing no incluía protecciones adicionales como las de modelos de disponibilidad general como Opus 4.7 o GPT-5.5
- Aun así, el modelo reaccionó con resistencia espontánea ante ciertas solicitudes, mostrando junto con su capacidad cibernética útil para detectar vulnerabilidades también guardrails emergentes
- Los rechazos espontáneos no fueron consistentes
- La misma tarea podía producir resultados completamente distintos según la redacción o el contexto
- En un proyecto, primero rechazó investigar vulnerabilidades y luego, tras un cambio irrelevante en el entorno del proyecto, aceptó la misma investigación sobre el mismo código
- También hubo casos en que encontró y confirmó varios bugs graves de memoria en un codebase, pero se negó a escribir un exploit de demostración
- La misma solicitud podía dar resultados distintos entre ejecuciones debido a la naturaleza probabilística del modelo
- Los rechazos espontáneos y los guardrails sí existían, pero por sí solos no fueron lo bastante consistentes como para constituir una frontera de seguridad completa
- Para ofrecer al público un modelo frontier cibernético capaz, hacen falta protecciones adicionales que permitan usarlo de forma adecuada fuera de entornos de investigación controlados como Project Glasswing
El problema de la señal y el ruido
- En el triage de vulnerabilidades de seguridad, la tarea más difícil es decidir qué bugs son reales, explotables y necesitan corregirse ahora
- Esto ya era difícil antes de la IA, y los escáneres de vulnerabilidades con IA junto con el código generado por IA lo empeoraron, por lo que Cloudflare construyó varias etapas de validación posterior
-
Lenguajes de programación
- C y C++ ofrecen control directo de memoria, lo que crea clases de bugs como buffer overflows y lecturas/escrituras fuera de rango
- Los lenguajes con seguridad de memoria como Rust eliminan esas clases en tiempo de compilación
- En proyectos escritos en lenguajes sin seguridad de memoria aparecieron sistemáticamente más falsos positivos
-
Sesgo del modelo
- Un buen investigador humano comunica qué encontró y cuánta confianza tiene, pero los modelos tienden a producir resultados haya o no un bug en el código
- Los resultados regresaban atenuados con expresiones como “possibly”, “potentially” o “could in theory”, y este tipo de resultados especulativos fue mucho más frecuente que los hallazgos firmes
- Como herramienta de exploración es un sesgo razonable, pero en una cola de triage cada resultado especulativo consume atención humana y tokens, y al acumularse por miles el costo crece mucho
- Mythos Preview mostró una mejora clara en su capacidad de encadenar primitivos al combinar varias vulnerabilidades en una PoC funcional, en lugar de reportarlas por separado
- Los resultados con PoC se acercaban mucho más a hallazgos accionables inmediatos y reducían de forma importante el tiempo necesario para confirmar si eran reales
- El arnés de Cloudflare estaba ajustado intencionalmente para reportar más y omitir menos, lo que generaba bastante ruido, pero las salidas de Mythos Preview usaban menos lenguaje atenuado y presentaban pasos de reproducción más claros, reduciendo el trabajo necesario para decidir si corregir o descartar
Límites de aplicar agentes de programación de propósito general directamente a repositorios
- En las primeras etapas de la investigación de vulnerabilidades asistida por IA, un punto de partida natural fue dar a un agente de programación de propósito general cualquier repositorio y pedirle que encontrara vulnerabilidades
- Ese enfoque producía resultados, pero no era adecuado para cubrir de forma significativa codebases reales ni para encontrar hallazgos valiosos
-
Contexto
- Los agentes de programación están diseñados para un flujo de trabajo enfocado en una sola tarea, como implementar funciones, corregir bugs o refactorizar
- La investigación de vulnerabilidades se parece más a examinar profundamente objetivos estrechos, como una función compleja, un cambio de frontera de seguridad o una inyección de comandos, y repetir eso miles de veces en todo el codebase como tareas acotadas y paralelas
- Incluso usando subagentes, una sola sesión sobre un repositorio de 100 mil líneas apenas puede cubrir de forma útil alrededor del 0.1% de la superficie antes de llenar la ventana de contexto del modelo y empezar la compresión
- En ese proceso de compresión también pueden descartarse resultados previos que eran importantes
-
Throughput
- Un agente de flujo único solo puede hacer una tarea a la vez
- En un codebase real hace falta aplicar muchas hipótesis sobre varios componentes al mismo tiempo y, cuando aparece algo interesante, bifurcarse más ampliamente
- Cuando un investigador ya tiene una pista y solo necesita una segunda revisión, los agentes de programación sí sirven para investigación manual
- Pero no son adecuados como herramienta para lograr alta cobertura, así que Cloudflare optó por construir un arnés alrededor de Mythos Preview
Lo que resolvió el arnés
- La experiencia ejecutándolo a gran escala llevó a la conclusión de que hacía falta un arnés para gestionar la ejecución completa
-
Un alcance estrecho produce mejores resultados
- Pedir “encuentra vulnerabilidades en este repositorio” hace que el modelo divague
- En cambio, solicitudes como “revisa inyección de comandos en esta función específica; aquí está esta frontera de confianza, este documento de arquitectura y la cobertura existente en esta zona” producen resultados mucho más parecidos al trabajo real de un investigador
-
La revisión adversarial reduce el ruido
- Colocar un segundo agente entre los resultados iniciales y la cola permite capturar mucho del ruido que el primer agente no detecta al revisarse a sí mismo
- El segundo agente usa prompts y un modelo distintos, y no tiene permiso para generar hallazgos propios
- Poner deliberadamente a dos agentes en desacuerdo fue mucho más efectivo que simplemente decirle a uno que fuera más cuidadoso
-
Dividir la cadena por agente mejora el razonamiento
- “¿Hay un bug en este código?” y “¿puede un atacante llegar realmente a ese bug desde fuera del sistema?” son preguntas distintas
- Al separarlas, cada pregunta se vuelve más acotada y el modelo rinde mejor en cada una
-
Muchas tareas paralelas y acotadas superan a un solo agente integral
- La cobertura mejora cuando muchos agentes resuelven preguntas estrechamente definidas y luego se eliminan duplicados
- Esto resultó más efectivo que pedirle exhaustividad a un solo agente
- Cloudflare usó Mythos Preview para ampliar, ajustar y mejorar su arnés existente de acuerdo con esas fortalezas
El arnés de Cloudflare para descubrir vulnerabilidades
- Este arnés se usa para escanear código real del runtime de Cloudflare, la ruta de datos edge, stacks de protocolo, el plano de control y proyectos open source de los que depende
-
Recon
- Un agente lee el repositorio de arriba abajo y se bifurca en subagentes encargados de cada subsistema
- Genera documentos de arquitectura con comandos de build, fronteras de confianza, puntos de entrada y superficie de ataque esperada
- También crea una cola inicial de tareas para la siguiente etapa y entrega contexto compartido a todos los agentes posteriores, reduciendo el problema de que el modelo divague
-
Hunt
- Cada tarea consiste en una clase de ataque y una pista sobre el alcance
- Los agentes hunter que buscan bugs reales suelen ejecutarse en paralelo en grupos de unas 50 instancias, y cada hunter vuelve a bifurcarse en algunos subagentes de exploración
- Cada hunter tiene acceso a herramientas para compilar y ejecutar código PoC en un directorio temporal por tarea
- La mayoría del trabajo ocurre como ejecución paralela de muchas tareas acotadas, no como un único agente integral
-
Validate
- Un agente independiente vuelve a leer el código e intenta refutar el hallazgo original
- Usa prompts distintos y no puede generar nuevos hallazgos por cuenta propia
- Captura una proporción significativa del ruido que el hunter deja pasar al revisar su propio trabajo
-
Gapfill
- Marca áreas que los hunters tocaron pero no cubrieron lo suficiente
- Esas áreas vuelven a la cola para otra pasada
- Esto compensa la tendencia del modelo a inclinarse hacia clases de ataque en las que ya tuvo éxito
-
Dedupe
- Combina en un solo registro los hallazgos que comparten la misma causa raíz
- El análisis de variantes es una capacidad útil, no una forma de inflar la cola con duplicados
-
Trace
- Para cada hallazgo confirmado en una librería compartida, un agente tracer se bifurca uno por repositorio consumidor
- Usa un índice de símbolos entre repositorios para decidir si una entrada controlada por el atacante realmente puede llegar al bug desde fuera del sistema
- Fue el paso más importante para pasar de “existe un defecto” a “existe una vulnerabilidad alcanzable”
-
Feedback
- Un resultado alcanzable de trace se convierte en una nueva tarea de hunt en el repositorio consumidor donde ese bug realmente queda expuesto
- Eso cierra un bucle en el que el pipeline mejora con cada ejecución
-
Report
- El agente redacta informes estructurados según un esquema predefinido
- Corrige por sí mismo errores de validación del esquema y los envía al ingest API
- La salida deja de ser prosa libre y se convierte en datos consultables
Qué significa para los equipos de seguridad
- Otros líderes de seguridad que vieron Mythos Preview intentaron comprimir su ciclo de respuesta escaneando y parchando más rápido
- Al menos uno de los equipos con los que habló Cloudflare operaba con un SLA de 2 horas desde la divulgación de un CVE hasta el parche en producción
- Si la línea de tiempo de los atacantes se acorta, la de los defensores también tiene que acortarse, pero la velocidad por sí sola no basta
- Parchear más rápido no cambia la forma del pipeline que produce esos parches
- Si las pruebas de regresión tardan un día, no se puede llegar a un SLA de 2 horas sin saltárselas
- Y un bug desplegado por saltarse las pruebas de regresión puede ser peor que el bug original que se quería corregir
- Cuando se hizo que el modelo escribiera los parches directamente, algunos llegaron a desplegarse corrigiendo el bug original pero rompiendo silenciosamente otras partes de las que dependía el código
- La pregunta más difícil es cómo diseñar la arquitectura alrededor de la vulnerabilidad
- Debe dificultarse la explotación por parte del atacante incluso si el bug existe
- Debe reducirse la importancia del intervalo entre la divulgación de la vulnerabilidad y el parche
- Hacen falta defensas que bloqueen el acceso al bug desde el frente de la aplicación
- La aplicación debe diseñarse para que un defecto en una parte del código no otorgue al atacante acceso a otras partes
- Debe ser posible desplegar correcciones simultáneamente en todos los lugares donde corre el código, sin esperar despliegues de cada equipo individual
- Esta misma capacidad tiene una doble cara
- La capacidad de encontrar bugs en código propio también puede acelerar ataques contra todas las aplicaciones de internet si cae en manos equivocadas
- Cloudflare señaló que está al frente de millones de aplicaciones y que los principios arquitectónicos anteriores son justamente los que sus productos están diseñados para aplicar en nombre de sus clientes
- La investigación con Mythos Preview se realizó en un entorno controlado y sobre código propio de Cloudflare; todas las vulnerabilidades encontradas fueron triadas y verificadas según el proceso oficial de gestión de vulnerabilidades de Cloudflare, y se corrigieron cuando fue necesario
2 comentarios
Pensé que era un informe analizando qué errores corrigieron, como
curl, pero al final es puro texto promocional, ¿no?Cloudflare también se subió al hype haciendo un paywall exclusivo para agentes de IA y un endpoint de resúmenes, y ya se descarrió.
Opiniones en Hacker News
No entiendo qué significa eso de que “es un tipo de herramienta distinto para un tipo de trabajo distinto, así que es difícil hacer una comparación limpia de manzanas con manzanas con modelos anteriores”
Dicen que es un tipo de herramienta distinto, pero al final explican su uso exactamente igual que el de otros modelos. Me pareció mucho peor que el blog promedio de Cloudflare, y se sintió mucho como una repetición del anuncio de Mythos, que señalaba el encadenamiento y la creación de ejemplos como puntos clave
Sí, todos lo usan con un harness, y la forma general de darle un harness a un modelo probablemente no cambie mucho en el futuro. Incluso los humanos a veces necesitan un harness para hacer cierto trabajo
Viéndolo de la mejor manera, quizá están siendo deliberadamente vagos sobre qué es exactamente distinto por temas de NDA
Últimamente casi todo lo que publica Cloudflare tiene un fuerte olor a IA
Sorprende que un modelo diseñado para investigación de seguridad y abierto solo a expertos rechace solicitudes legítimas
Esperaba cifras más concretas y resultados sorprendentes, pero parece más bien un texto promocional equilibrado y probablemente escrito con LLM
[1] https://xbow.com/blog/mythos-offensive-security-xbow-evaluat...
La verdadera pregunta es si esto lo escribió Mythos u Opus
Frases como “por qué importa” en realidad no importan. Los blogs corporativos rara vez han tenido una sola voz de autor, pero igual resulta interesante ver incluso a las organizaciones grandes subcontratando sus blogs a un LLM
Ya hasta me gustaría elevar “por qué importa” a “la salida de la IA pasa a formar parte de los datos de entrenamiento”. Algún día el estilo pulido y verboso de IA se volverá el estándar, y salvo que seas de generaciones anteriores será difícil distinguirlo. Se parece a extrañar ciertos aspectos de Usenet
Es como mirar por el cañón de un arma y bromear sobre en qué tipo de papel está impreso el anuncio del arma
Por eso parece que Claude Code tiene tantos bugs raros, y que el soporte dice haber procesado reembolsos cuando en realidad no pasa
Me dio risa eso de las “cuatro lecciones” que supuestamente salieron de ejecutar esto a gran escala. Tres de las cuatro eran básicamente lo mismo y demasiado obvias
En resumen, una solicitud específica y acotada funciona mejor que “encuentra vulnerabilidades”, lo cual es totalmente obvio. Aun así, la revisión adversarial no es nada nueva y se ha hablado mucho en HN, pero al menos me parece la parte interesante y diferenciadora. Voy a intentar meterla más en mi flujo de trabajo, y quizá también sirva para tareas que no sean de programación
https://blog.cloudflare.com/cyber-frontier-models/#what-a-ha...
Me llamó la atención esta parte: “la mayor reacción de los líderes de seguridad ante Mythos Preview fue la velocidad. Escanear más rápido, parchear más rápido y comprimir el ciclo de respuesta. Al menos dos de los equipos con los que hablamos ya operan con un SLA de 2 horas desde la divulgación del CVE hasta el parche en producción [...] si las pruebas de regresión toman un día, no se puede llegar a un SLA de 2 horas sin saltárselas, y si te saltas las pruebas de regresión, es fácil desplegar un bug peor que el que intentabas corregir”
Me pregunto si con el tiempo estos modelos podrán ejecutar pruebas de explotabilidad antes de fusionar código, para producir por defecto código más seguro
*aquí “ellos” se refiere a todos los proveedores de modelos base, porque OpenAI parece ir en la misma dirección
Está bien, pero me gustaría saber qué tan seria fue la vulnerabilidad más grave que encontraron
Seguramente no quieren divulgarlo, pero esa es realmente la parte más interesante e importante
Mucha gente ve Mythos como una campaña psicológica, pero no entiendo bien ese escepticismo. Parece venir sobre todo de la desconfianza general hacia algo que no se puede usar públicamente. Algunos empleados de Anthropic describieron Mythos como una mejora del modelo general, pero eso todavía no está ampliamente respaldado, así que sigo siendo escéptico en esa parte. En el ámbito de la investigación en seguridad, sí puedo aceptar esa narrativa
Visto así, cerrar vulnerabilidades no es lo mismo que encontrar un exploit. Más bien se trata de dejar menos huecos pequeños, haciendo cada vez más difícil ensamblar un exploit funcional
Así que, incluso si sus “hard skills” no mejoraron de forma abrumadora, sí puede combinarlas con más eficacia. Incluso hoy muchas de estas vulnerabilidades pueden identificarse con Opus, pero para convertirlas en un exploit complejo todavía hace falta una persona de por medio, y además una persona con experiencia. Si ya no hiciera falta intervención humana, sería mucho más fácil para una persona promedio encontrar y aprovechar exploits
https://security.paloaltonetworks.com
Está bien, pero no entiendo por qué no comparten datos sobre cuántas vulnerabilidades de seguridad encontraron realmente, cuántas eran verdaderas y cuántas fueron falsos positivos
Entiendo que quieran resolverlo antes de hacerlo público, pero cuando uno sigue viendo afirmaciones con casi nada de datos, no sé cómo esperan que la gente no sea escéptica. Los profesionales de seguridad, literalmente, cobran por ser escépticos
Me pregunto si lo compararon con otros modelos. Gran parte de este texto suena a alguien aplicando IA a seguridad por primera vez y sorprendiéndose por el rendimiento absurdo de una máquina de reconocimiento de patrones
Al final es una máquina que hace matching de patrones, así que es lógico
La parte donde se resiste es bastante graciosa. Cuando lo probé, antes de continuar me pidió pruebas de que yo tenía derecho legítimo de acceso a esa base de código
La frase “lo que cambió con Mythos Preview es que el modelo ahora puede encadenar bugs de baja gravedad que tradicionalmente permanecían invisibles en el backlog para convertirlos en un exploit más grave” parece coincidir en cierta medida con otras pruebas independientes de Mythos
Le fue muy bien en tareas agentivas largas, y probablemente entrenaron el modelo con ese objetivo. Para eso tiene que poder encontrar conexiones periféricas entre temas vagamente relacionados dentro de la ventana de contexto
[1] Me refiero principalmente a https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos...