Project Glasswing: lo que nos enseñó Mythos
Ciudad de México, 19 de mayo de 2026- En los últimos meses, Cloudflare ha estado probando varios modelos de lenguaje de gran tamaño (LLM, por sus siglas en inglés) centrados en la seguridad en su propia infraestructura. Estos LLM ayudan a identificar posibles vulnerabilidades en los sistemas de la compañía para poder corregirlas, y también muestran lo que los ciberdelincuentes podrán hacer con los modelos más recientes.
Ninguno de estos LLM ha llamado tanto la atención como Mythos Preview, de Anthropic. Hace unas semanas, el equipo de Cloudflare fue invitado a usar Mythos Preview como parte de Project Glasswing. Enseguida se puso a prueba con más de cincuenta repositorios, para ver qué se encontraba y cómo funcionaba.
A continuación, compartimos un informe de lo que encontró el equipo de Cloudflare, con información detallada sobre lo que los modelos hicieron bien y lo que no, y cómo la arquitectura y el proceso a su alrededor necesitan cambiar para que puedan usarse a gran escala.
Qué cambió con Mythos Preview
Mythos Preview supone un auténtico paso adelante, y vale la pena dejarlo claro antes de entrar en otros detalles. Cloudflare lleva ya un tiempo probando modelos con su código, y el salto de lo que se podía hacer con los modelos Frontier de uso general anteriores a lo que ofrece hoy Mythos Preview, no es solo una mejora de lo que había antes.
Es una herramienta diferente que realiza un tipo de trabajo distinto, lo cual dificulta una comparación directa con modelos anteriores. Así que, en lugar de intentar comparar Mythos Preview con los modelos de vanguardia de uso general, resulta más útil describir lo que realmente puede hacer, y dos funciones que destacaron en el trabajo que se hizo con Mythos Preview:
- Creación de una cadena de vulnerabilidades: en un ataque real casi nunca se usa un solo fallo de seguridad. Se encadenan varias técnicas de ataque básicas para crear una vulnerabilidad que funcione. Por ejemplo, podría convertir un fallo de "uso tras liberación" en una primitiva de lectura y escritura arbitraria, secuestrar el flujo de control y utilizar cadenas de programación orientada a retornos (ROP) para hacerse con el control total del sistema. Mythos Preview puede tomar varias de estas primitivas y deducir cómo combinarlas para crear una prueba válida. El razonamiento que muestra a lo largo del camino parece el trabajo de un investigador sénior más que el resultado de un análisis automático.
- Generación de pruebas: encontrar un fallo y demostrar que se puede explotar son dos cosas diferentes, y Mythos Preview puede hacer ambas. Escribe código que provocaría el posible error, compila ese código en un entorno de prueba y lo ejecuta. Si el programa hace lo que esperaba el modelo, esa es la prueba. Si no lo hace, el modelo lee el error, ajusta su hipótesis y vuelve a intentarlo. El bucle es tan importante como los errores que detecta, porque un posible fallo sin una prueba funcional no es más que una especulación, y Mythos Preview cubre esa carencia por sí solo.
Algunas de las cosas que se describen no son exclusivas de Mythos Preview. Cuando probaron otros modelos de vanguardia con el mismo conjunto de pruebas, detectaron bastantes de los mismos errores subyacentes y, en algunos casos, llegaron más lejos de lo que se esperaba en cuanto al razonamiento. Donde se quedaron cortos fue a la hora de encajar todas las piezas. Un modelo identificaría un fallo interesante, escribiría una descripción detallada de por qué era importante y luego se detendría, dejando la cadena de pasos sin completar y la cuestión de si se podía explotar sin resolver. Lo que ha cambiado con Mythos Preview es que ahora un modelo puede tomar esos fallos de baja gravedad (que tradicionalmente se quedaban ocultos en la lista de tareas pendientes) y encadenarlos para crear una única vulnerabilidad más grave.
Ejemplos de respuestas de rechazo en la investigación legítima sobre vulnerabilidades
El modelo Mythos Preview proporcionado por Anthropic, como parte de Project Glasswing, no contaba con las medidas de seguridad adicionales que sí tienen los modelos disponibles para el público en general (como Opus 4.7 o GPT-5.5).
A pesar de ello, el modelo rechaza de forma espontánea ciertas solicitudes. Al igual que las capacidades cibernéticas que lo hacían útil para la búsqueda de vulnerabilidades, el modelo tiene sus propios mecanismos de protección emergentes que, en ocasiones, le llevan a rechazar solicitudes legítimas de investigación en materia de seguridad. Pero, como se ha descubierto, estos rechazos espontáneos no son consistentes. La misma tarea, planteada de forma diferente o presentada en un contexto distinto, podría dar lugar a resultados completamente diferentes, tal y como se ilustra en los siguientes ejemplos:
Por ejemplo, el modelo inicialmente se negó a realizar investigaciones de vulnerabilidad en un proyecto, luego aceptó realizar la misma investigación en el mismo código tras un cambio no relacionado en el entorno del proyecto. Nada sobre el código que se estaba analizando había cambiado. En otro caso, el modelo detectó y confirmó varios fallos graves de memoria en un código fuente, pero luego se negó a escribir una prueba de concepto. La misma solicitud, formulada de manera diferente, obtuvo una respuesta distinta, e incluso la misma solicitud puede producir diferentes resultados en distintas ejecuciones debido a la naturaleza probabilística del modelo. Las tareas semánticamente equivalentes pueden dar lugar a resultados opuestos dependiendo de cómo y cuándo se le presenten al modelo.
Esto es importante porque, aunque los mecanismos de rechazo y las barreras de seguridad del modelo son reales, no son lo suficientemente consistentes como para servir por sí solos de límite de seguridad completo. Precisamente por eso, cualquier modelo de ciberseguridad capaz que se ponga a disposición del público en general en el futuro debe incluir medidas de seguridad adicionales además de este comportamiento básico, para que sea adecuado para un uso más amplio fuera de un contexto de investigación controlado como Project Glasswing.
El problema de la relación señal-ruido
Una de las partes más difíciles a la hora de clasificar las vulnerabilidades de seguridad es decidir qué fallos son reales, cuáles se pueden explotar y cuáles hay que solucionar ya. Este era un problema difícil incluso en el mundo previo a la IA. Los programas de análisis de vulnerabilidades basados en la IA y el código generado por IA han empeorado la situación, y en Cloudflare han creado varias etapas de validación posterior para hacerle frente.
Hay dos factores que influyen en el nivel de ruido:
- El lenguaje de programación - C y C++ te permite controlar directamente la memoria y, con ello, aparecen errores como los desbordamientos de búfer o las lecturas y escrituras fuera de límites, que los lenguajes seguros en cuanto a la memoria, como Rust, eliminan en tiempo de compilación. Se observaron sistemáticamente más falsos positivos en proyectos escritos en lenguajes no seguros para la memoria.
- El sesgo del modelo: un buen investigador te cuenta lo que ha descubierto y qué grado de confianza tiene en sus resultados. Los modelos no. Pide a un modelo que encuentre errores y los encontrará, tenga el código o no. Las conclusiones vienen acompañadas de expresiones como "posiblemente", "potencialmente" o "en teoría", y estas conclusiones con matices superan con creces a las que son más sólidas. Es un sesgo razonable para una herramienta de exploración. Esto es desastroso para una cola de clasificación, donde cada hallazgo dudoso requiere atención humana y recursos para descartarlo, y ese coste se acumula con miles de hallazgos.
Mythos Preview supone una clara mejora en este sentido, sobre todo por su capacidad para encadenar vulnerabilidades básicas, es decir, combinar varias vulnerabilidades en una prueba de concepto funcional en lugar de notificarlas por separado. Un hallazgo que viene acompañado de una prueba de concepto es uno sobre el que puedes actuar, y eso significa que te ahorras mucho tiempo preguntándote "¿esto es siquiera real?".
Los entornos de prueba están configurados a propósito para generar más alertas de las necesarias, de modo que se detectaron más cosas (y se escaparon menos), aunque eso conlleva mucho más ruido. Pero a la hora de hacer la selección, los resultados de Mythos Preview son de una calidad notablemente superior: menos conclusiones ambiguas, pasos de reproducción más claros y menos trabajo para decidir si hay que arreglarlo o descartarlo.
Por qué no funciona apuntar un agente de codificación genérico a un repositorio
Cuando el año pasado Cloudflare empezó a investigar vulnerabilidades con ayuda de la IA, el primer instinto fue el más obvio: aplicar un agente de programación genérico a un repositorio cualquiera y pedirle que detectara vulnerabilidades. Este enfoque funciona, en el sentido de que el modelo generará resultados, pero no sirve para cubrir de forma significativa un código real ni para identificar resultados que tengan valor. Estas son las tres razones principales de esta tendencia:
- Contexto: los programadores se centran en una sola tarea concreta: desarrollar una función, corregir un error o reestructurar el código. Ingieren una gran cantidad de código fuente, mantienen una única hipótesis a la vez e iteran sobre ella. Esa es precisamente la forma menos adecuada para la investigación de vulnerabilidades, que es, por naturaleza, específica y paralela. Un investigador elige un aspecto concreto para analizarlo y lo investiga a fondo. Ese aspecto puede ser una función compleja concreta, los cruces de límites de seguridad o un tipo específico de vulnerabilidad, como las inyecciones de comandos, en las que la entrada del atacante acaba ejecutándose como un comando de shell. Luego lo hacen de nuevo, para una función diferente, límite de seguridad o clase de vulnerabilidad, miles de veces en toda la base de código. Una sola sesión de un agente (incluso con subagentes) sobre un repositorio de cien mil líneas puede cubrir, como mucho, una décima parte del uno por ciento de la superficie de forma útil antes de que se llene la ventana de contexto del modelo y se active la compactación, lo que podría llevar a descartar hallazgos anteriores que habrían sido importantes.
- Rendimiento: un agente de una sola secuencia hace una cosa a la vez, pero las bases de código reales necesitan muchas hipótesis contra muchos componentes a la vez, con la capacidad de expandirse aún más cuando surge algo interesante. Puedes exigirle más a un solo agente, pero llega un momento en que ya no te limita el modelo, sino la forma que toma la interacción en sí. Usar el modelo directamente en un agente de codificación resulta adecuado para la investigación manual cuando un investigador ya tiene una pista y quiere una segunda opinión. Sin embargo, no es la herramienta adecuada para conseguir una cobertura alta. Una vez que el equipo aceptó eso, dejó de intentar que Mythos Preview hiciera lo que no debía y empezó a desarrollar el entorno a su alrededor.
Lo que realmente soluciona un entorno de pruebas
Cuatro lecciones surgieron al ejecutar el trabajo a gran escala, y cada una apuntó a la necesidad de un entorno de pruebas que gestione la ejecución general:
- Un alcance más limitado da mejores resultados: si le dices al modelo "Encuentra vulnerabilidades en este repositorio", se dispersa. Si le dices: "Busca una inyección de comandos en esta función concreta, con este límite de confianza por encima; aquí tienes el documento de arquitectura y aquí la cobertura previa de esta área", hace que se acerque mucho más a lo que haría realmente un investigador.
- La revisión adversaria reduce el ruido: si añades un segundo agente entre el resultado inicial y la cola — uno con una indicación diferente, un modelo diferente y sin capacidad para generar sus propios resultados — se detecta gran parte del ruido que el primer agente pasaría por alto si solo revisara su propio trabajo. Resulta que hacer que dos agentes discrepen a propósito es mucho más eficaz que limitarse a decirle a uno de ellos que tenga cuidado.
- La división de la cadena entre los distintos agentes mejora el razonamiento: preguntar "¿Este código tiene errores?" y "¿Puede un atacante acceder realmente a este error desde fuera del sistema?" son dos cuestiones distintas, y el modelo funciona mejor con cada una de ellas cuando se plantean por separado, ya que cada pregunta es más concreta que la versión combinada.
- Las tareas paralelas específicas son mejores que un agente que lo abarca todo: la cobertura mejora cuando varios agentes se centran en preguntas bien delimitadas y luego eliminamos los resultados duplicados, en lugar de pedirle a un solo agente que lo haga todo.
Cada una de esas observaciones se refiere al comportamiento del modelo, y juntas describen algo que ya no es una interfaz de chat. Es un entorno de pruebas que te ayuda a lograr los resultados finales. Los primeros pasos para crear un entorno de pruebas son sencillos, ya que puedes pedir ayuda al modelo, que es lo que hizo el equipo. Utilizó Mythos Preview para desarrollar, personalizar y mejorar los entornos de pruebas originales de acuerdo con sus fortalezas. A continuación se describe un ejemplo de cómo es un entorno de pruebas en la práctica.
El entorno de pruebas de detección de vulnerabilidades
Así es como funciona el entorno de pruebas de detección de vulnerabilidades de Cloudflare, paso a paso. Lo usaron para analizar el código en producción en todo el entorno de ejecución, la ruta de datos en el perímetro, la pila de protocolos, el plano de control y los proyectos de código abierto de los que dependen.
Fase | ¿Qué hace? | Por qué es importante |
Reconocimiento | Un agente lee el repositorio de arriba abajo, se distribuye entre los subagentes responsables de cada subsistema y elabora un documento de arquitectura que incluye los comandos de compilación, los límites de confianza, los puntos de entrada y la superficie de ataque probable. También genera la cola inicial de tareas para la siguiente etapa. | Proporciona un contexto compartido a todos los agentes posteriores. Elimina el problema de la dispersión. |
Búsqueda | Cada tarea consiste en una clase de ataque combinada con una pista sobre el alcance. Los investigadores (los agentes que se encargan de buscar errores) se ejecutan simultáneamente, normalmente unos cincuenta a la vez, y cada uno de ellos se divide en varios subagentes de exploración. Cada investigador tiene acceso a herramientas que compilan y ejecutan código de prueba de concepto en un directorio temporal por tarea. | Aquí es donde ocurre la mayor parte del trabajo. Muchas tareas concretas en paralelo, no un único agente exhaustivo. |
Validación | Un agente independiente vuelve a leer el código e intenta refutar la conclusión original. Utiliza un conjunto de instrucciones diferente y no tiene la capacidad de generar nuevos hallazgos por sí mismo. | Detecta una parte importante de los errores que el investigador no detectaría al revisar su propio trabajo. |
Compensación | Los investigadores marcan las zonas en las que han estado pero que no han revisado a fondo. Esas áreas se vuelven a poner en cola para otra pasada. | Contrarresta la tendencia del modelo a decantarse por clases de ataque con las que ya ha tenido éxito. |
Eliminación de duplicados | Las incidencias que comparten la misma causa se agrupan en un único registro. | El análisis de variantes es una función, no una manera de inflar la cola con duplicados. |
Rastreo | Por cada fallo confirmado en una biblioteca compartida, se despliega un agente de rastreo (una instancia por cada repositorio de usuario), que utiliza un índice de símbolos entre repositorios y determina si la entrada controlada por el atacante llega realmente al fallo desde fuera del sistema. | Convierte "hay un fallo" en "hay una vulnerabilidad a la que se puede acceder". Esta es la etapa que más importa. |
Comentarios | Los rastreos localizables se convierten en nuevas tareas de búsqueda en los repositorios de los usuarios donde realmente se detecta el error. | Así se cierra el círculo. La canalización mejora a medida que se ejecuta. |
Informe | Un agente redacta un informe estructurado según un esquema predefinido, corrige cualquier error de validación en dicho esquema y envía el informe a una API de ingestión. | El resultado son datos que se pueden consultar, no un texto en prosa sin estructura. |
Qué significa esto para los equipos de seguridad
La reacción más destacada de otros responsables de seguridad ante el avance de Mythos ha girado en torno a la rapidez: analizar y aplicar revisiones más rápido, así como acortar el ciclo de respuesta. Más de un equipo con el que se ha hablado está trabajando ahora con un acuerdo de nivel de servicio (SLA) de dos horas desde la publicación del CVE hasta la aplicación de la revisión en producción. El razonamiento es comprensible: cuando el margen de tiempo del atacante se reduce, el del defensor tiene que reducirse también. Más rápido no va a ser suficiente, y creemos que muchos equipos están a punto de gastar mucho tiempo, esfuerzo y dinero aprendiendo eso por las malas.
Actualizar más rápido no cambia la naturaleza del proceso que genera la revisión. Si las pruebas de regresión tardan un día, no podrás cumplir un SLA de dos horas sin saltártelas, y los errores que acabas lanzando al mercado cuando te saltas las pruebas de regresión suelen ser peores que los que intentabas corregir. Algo parecido ocurrió cuando probaron dejar que el modelo generara sus propias revisiones y se observó cómo se publicaban algunas que, aunque solucionaban el error original, sin que se dieran cuenta estropeaban otra parte del código de la que dependía.
La pregunta más difícil es cómo debería ser la arquitectura en torno a la vulnerabilidad. La idea es que a un atacante le resulte más difícil aprovechar la vulnerabilidad, incluso si hay un fallo, para que el tiempo que pasa entre que se da a conocer la vulnerabilidad y que se corrige no sea tan importante. Eso significa que hay medidas de seguridad instaladas en la aplicación que impiden que se acceda al fallo. Significa diseñar la aplicación de manera que un fallo en una parte del código no pueda darle a un atacante acceso a otras partes. Significa poder implementar una solución en todos los lugares donde el código se está ejecutando al mismo tiempo, en lugar de esperar a que los equipos individuales lo implementen.
También hay que ser conscientes de que este tema tiene sus pros y sus contras. Las mismas capacidades que ayudaron a encontrar errores en el código de Cloudflare, en manos equivocadas, acelerarán los ataques contra todas las aplicaciones de Internet. Cloudflare protege millones de esas aplicaciones, y los principios de arquitectura descritos anteriormente son precisamente los que sus productos están diseñados para aplicar en nombre de los clientes.
El equipo compartirá más sobre lo que eso significa para los clientes en las próximas semanas.
Para conocer el reporte completo, da clic en este enlace hacia el blog de Cloudflare.
Cloudflare_May26_Project Glasswing_ lo que nos enseñó Mythos.pdf
PDF 465 KB
Elina Ambriz
