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.
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:
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.
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:
\nPor 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.
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:
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.
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:
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:
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.
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.
\n\n
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. \u200b
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.
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.
", "header": { "large": "https://cdn.uc.assets.prezly.com/2cafcab5-e92e-4296-8ba2-5f2a8cd2c475/-/format/auto/", "release": "https://cdn.uc.assets.prezly.com/2cafcab5-e92e-4296-8ba2-5f2a8cd2c475/-/format/auto/" }, "images": [ { "caption": "Ejemplo de c\u00f3mo Mythos Preview retrasa la creaci\u00f3n de una prueba de concepto funcional ", "original": "https://cdn.uc.assets.prezly.com/b6eb85f3-6911-4bef-a214-a71b32665d7e/", "medium": "https://cdn.uc.assets.prezly.com/b6eb85f3-6911-4bef-a214-a71b32665d7e/-/preview/500x500/-/format/auto/", "small": "https://cdn.uc.assets.prezly.com/b6eb85f3-6911-4bef-a214-a71b32665d7e/-/preview/200x200/-/format/auto/", "thumbnail": "https://cdn.uc.assets.prezly.com/b6eb85f3-6911-4bef-a214-a71b32665d7e/-/preview/100x100/-/format/auto/", "square": "https://cdn.uc.assets.prezly.com/b6eb85f3-6911-4bef-a214-a71b32665d7e/-/scale_crop/200x200/center/-/format/auto/", "squaresmall": "https://cdn.uc.assets.prezly.com/b6eb85f3-6911-4bef-a214-a71b32665d7e/-/scale_crop/58x58/center/-/format/auto/" }, { "caption": "", "original": "https://cdn.uc.assets.prezly.com/d269d4bf-5f86-4df1-87a7-1e9426133b4b/", "medium": "https://cdn.uc.assets.prezly.com/d269d4bf-5f86-4df1-87a7-1e9426133b4b/-/preview/500x500/-/format/auto/", "small": "https://cdn.uc.assets.prezly.com/d269d4bf-5f86-4df1-87a7-1e9426133b4b/-/preview/200x200/-/format/auto/", "thumbnail": "https://cdn.uc.assets.prezly.com/d269d4bf-5f86-4df1-87a7-1e9426133b4b/-/preview/100x100/-/format/auto/", "square": "https://cdn.uc.assets.prezly.com/d269d4bf-5f86-4df1-87a7-1e9426133b4b/-/scale_crop/200x200/center/-/format/auto/", "squaresmall": "https://cdn.uc.assets.prezly.com/d269d4bf-5f86-4df1-87a7-1e9426133b4b/-/scale_crop/58x58/center/-/format/auto/" } ], "attachments": [ { "description": "", "extension": "pdf", "url": "https://cdn.uc.assets.prezly.com/c51e81de-7b16-415a-837d-de4a9e2cac87/-/inline/no/cloudflaremay26project-glasswing-lo-que-nos-enseno-mythos.pdf" } ], "contacts": [ { "name": "Elina Ambriz", "company": "another", "description": "Account Executive Senior", "email": "elina.ambriz@another.co", "website": null, "address": null, "telephone": "4439399785", "mobile": null, "twitter": null, "facebook": null } ], "author": { "first_name": "Elina", "last_name": "Ambriz Valencia" }, "format_version": 5 }