La historia detrás de reforzar Firefox con Claude Mythos Preview

• Mozilla construyó un pipeline para encontrar bugs de seguridad reales a gran escala en Firefox, aumentando la señal y reduciendo el ruido de los reportes de seguridad generados por IA mediante mejoras en el rendimiento del modelo y en el harness
• En Firefox 150 release se corrigieron 271 bugs identificados por Claude Mythos Preview, y 149.0.2, 150.0.1, 150.0.2 también incluyeron correcciones relacionadas
• Entre los bugs representativos publicados se incluyen una primitive de objeto falso causada por la eliminación de inicialización de structs de WebAssembly GC en el JIT, un UAF en el proceso padre mediante una condición de carrera de IPC, un problema de deserialización de NaN, un bug de rehash de XSLT con 20 años de antigüedad y un overflow de bitfield de layout de 16 bits usando rowspan=0
• Una parte importante de los bugs publicados corresponde a escapes de sandbox, y la IA pudo cubrir con más amplitud una superficie de ataque difícil de encontrar solo con fuzzing, ya que asume un proceso de contenido comprometido que eleva privilegios hacia el proceso padre con privilegios
• Mozilla montó un harness agéntico sobre su infraestructura de fuzzing existente para descartar conjeturas no reproducibles y validar hipótesis con casos de prueba, y planea integrarlo en integración continua para escanear los parches cuando entren al tree

---

El cambio en los bugs de seguridad de Firefox revelado por modelos de IA

• Hasta hace unos meses, los reportes de bugs de seguridad generados por IA que llegaban a proyectos open source solían parecer plausibles pero ser incorrectos, creando un costo asimétrico para quienes mantienen el proyecto
• En Firefox la situación cambió mucho en poco tiempo, y la razón principal fue la mejora en el rendimiento de los modelos y en las técnicas para dirigir, extender y combinar modelos con un harness para aumentar la señal y filtrar el ruido
• Mozilla normalmente mantiene en privado los reportes detallados de bugs durante varios meses incluso después de publicar avisos de seguridad y distribuir correcciones, pero esta vez decidió divulgar algunos reportes considerando la urgencia y el interés en todo el ecosistema
• Los reportes publicados fueron elegidos entre varios subsistemas del navegador; la selección es algo arbitraria, pero la profundidad y diversidad de los reportes muestran por qué los defensores necesitan aplicar esta técnica

Bugs representativos publicados

• 2024918
  • Debido a una verificación de equivalencia incorrecta, el JIT eliminó por optimización la inicialización de un struct vivo de WebAssembly GC, lo que permitió crear una primitive de objeto falso conectable con lecturas y escrituras arbitrarias potenciales en código que ya había pasado por amplio fuzzing interno y externo
• 2024437
  • Un bug de 15 años en el elemento <legend>, activado mediante una combinación refinada de casos límite en áreas alejadas entre sí del navegador, como el límite de profundidad de pila recursiva, propiedades expando y cycle collection
• 2021894
  • Al explotar de forma confiable una condición de carrera de IPC, un proceso de contenido comprometido podía manipular el conteo de referencias de IndexedDB en el proceso padre, provocando UAF y un posible escape de sandbox
• 2022034
  • Un NaN sin procesar podía cruzar el límite de IPC y parecer un puntero etiquetado a objeto JS, por lo que la deserialización de un double podía llevar a una primitive de objeto falso en el proceso padre y a un escape de sandbox
• 2024653
  • Un caso de prueba complejo que combinó loops de eventos anidados, un listener pagehide y recolección de basura provocó un UAF en el setter de un atributo del elemento <object>
• 2022733
  • Al inyectar miles de hashes de certificados en WebTransport, se amplió una condición de carrera en un loop de copia con mucho conteo de referencias, provocando un UAF en el padre mediante IPC desde un proceso de contenido comprometido
• 2023958
  • Al interceptar llamadas a funciones DNS de glibc para simular un servidor DNS malicioso y reproducir un caso límite de fallback de UDP a TCP, se provocó una lectura fuera de límites del búfer y una filtración de memoria de stack del proceso padre durante el parsing de HTTPS RR y ECH
• 2025977
  • Era un bug de XSLT con 20 años de antigüedad en el que una llamada reentrante a key() provocaba un rehash de la tabla hash que liberaba el backing store, pero el puntero crudo a la entrada seguía usándose; fue uno de varios problemas sec-high de XSLT corregidos
• 2027298
  • Tras parchear el selector de color para simular una selección de usuario difícil de automatizar, se ejecutó un loop de eventos anidado con eventos de entrada síncronos para reentrar en el teardown del actor y hacer que un callback fuera liberado mientras se estaba liberando, provocando un UAF en el proceso de contenido
• 2023817
  • Un proceso de contenido comprometido podía enviar al proceso padre una imagen de fondo de pantalla arbitraria para que la decodificara, y en combinación con una vulnerabilidad hipotética en el decodificador de imágenes podía llevar a un escape de sandbox
  • Requería razonar en el proceso padre sobre el nivel de confianza de la entrada, algo difícil de automatizar
• 2029813
  • En RLBox, la tecnología de sandboxing granular de Firefox 95, se evadió el sandbox aprovechando una brecha en la lógica de validación al copiar valores del lado no confiable al lado confiable
• 2026305
  • Con un caso de prueba muy pequeño que aprovechaba la semántica especial de rowspan=0 en tablas HTML, se agregaron más de 65535 filas para eludir el clamping y desbordar un bitfield de layout de 16 bits, algo que los fuzzers no detectaron durante años

Escapes de sandbox y capas de defensa

• Una parte importante de los bugs publicados son escapes de sandbox, y para terminar en una cadena de compromiso completa de Firefox tendrían que combinarse con otros exploits
• Estos reportes parten de que el proceso sandbox que renderiza el contenido de sitios ya fue comprometido por otro bug y que código máquina controlado por el atacante intenta escalar privilegios al proceso padre con privilegios
• Al crear escapes de sandbox, el modelo puede parchear el código fuente de Firefox siempre que el código modificado se ejecute solo dentro del proceso sandbox
• Este tipo de bug es difícil de encontrar con fuzzing, y Mozilla ha desarrollado técnicas como el fuzzing de IPC con snapshots, pero el análisis con IA pudo cubrir esta superficie crítica de manera mucho más amplia
• Lo que el modelo no encontró también fue importante
  • En los últimos años, investigadores de seguridad enviaron varios reportes que causaban prototype pollution en el proceso padre con privilegios para escapar del sandbox del proceso
  • En lugar de corregir cada problema uno por uno, Mozilla aplicó un cambio arquitectónico para congelar los prototypes por defecto
  • En los logs del harness hubo muchas señales de intentos de usar esa ruta de escape que quedaron bloqueados por el diseño, confirmando el efecto directo del trabajo previo de hardening

Construcción de un pipeline de endurecimiento de seguridad con harnesses

• Mozilla llevó a cabo internamente durante los últimos años experimentos de auditoría de código con LLM para análisis estático de código de alto riesgo, usando modelos como GPT 4 o Sonnet 3.5
• Los experimentos iniciales mostraban potencial, pero la tasa de falsos positivos era demasiado alta para escalar
• La situación cambió con la llegada de harnesses agénticos capaces de detectar problemas de seguridad de forma más confiable
  • Pueden encontrar bugs reales
  • Pueden descartar conjeturas no reproducibles
  • Con interfaces e instrucciones adecuadas, pueden crear y ejecutar casos de prueba reproducibles para validar dinámicamente hipótesis sobre bugs en el código
• Después de corregir los issues iniciales enviados por Anthropic en febrero, Mozilla construyó su propio harness sobre su infraestructura de fuzzing existente
• Al principio comenzaron con un experimento pequeño usando Claude Opus 4.6 para buscar escapes de sandbox
  • Incluso solo con este modelo identificaron una cantidad considerable de vulnerabilidades antes desconocidas que requerían razonamiento complejo sobre código de un motor de navegador multiproceso
  • Al principio observaban directamente el proceso en la terminal, ajustando en tiempo real los prompts y la lógica
  • Cuando el funcionamiento se estabilizó, paralelizaron el trabajo con varias VM efímeras, donde cada VM buscaba bugs en archivos objetivo específicos y luego registraba los resultados en un bucket
• El subsistema de descubrimiento por sí solo no era suficiente
  • Había que integrarlo con todo el ciclo de vida del bug de seguridad, incluyendo qué buscar, dónde mirar y cómo procesar los resultados
  • Eso incluye eliminar duplicados con issues existentes, seguimiento de bugs, triage y distribución de correcciones
  • El modelo es el bloque primitivo central que mueve el harness, pero para que sea útil a escala se necesita todo el pipeline
• El harness puede reutilizarse entre proyectos, pero el pipeline cambia según el significado del codebase, las herramientas y los procesos de cada proyecto
• Hizo falta bastante trabajo iterativo y un loop de retroalimentación muy cercano con la manera en que los ingenieros de Firefox procesan los bugs entrantes

Claude Mythos Preview y el efecto de cambiar de modelo

• Una vez que el pipeline end-to-end está listo, cambiar a otro modelo cuando sale uno nuevo se vuelve sencillo
• Mozilla encontró varios bugs graves incluso con modelos públicos, y gracias a este pipeline pudo aprovechar de inmediato la oportunidad de evaluar Claude Mythos Preview
• La mejora de modelo elevó la eficacia de todo el pipeline
  • Encuentra mejor los bugs potenciales
  • Construye mejor los casos de prueba de prueba de concepto que demuestran el bug
  • Resume mejor las patologías y el impacto
• Además de corregir 271 bugs identificados por Claude Mythos Preview en Firefox 150 release, también se incluyeron correcciones relacionadas en 149.0.2, 150.0.1 y 150.0.2
• Internamente siguen encontrando bugs por otras vías, y al igual que otros proyectos también aumentaron mucho los reportes externos en los últimos meses
• Todos los bugs requirieron atención cuidadosa para corregirse bien, y durante los últimos meses hubo mucho trabajo y jornadas largas para ponerse al día con una escala sin precedentes
• Más de 100 personas participaron aportando código para lanzar la versión más segura posible de Firefox; además de escribir y revisar parches, también trabajaron en construir y expandir el pipeline, hacer triage, probar correcciones y gestionar el proceso de release de cada bug

Lecciones clave

• Cualquiera que haga software hoy puede usar modelos modernos y harnesses para encontrar bugs y endurecer su código
• Se puede empezar con prompts simples, observar y repetir
  • El prompt inicial no era muy distinto del enfoque mostrado en este video
  • Con la iteración se añadieron muchas herramientas y orquestación para optimizar y escalar el pipeline, pero el núcleo del loop interno seguía siendo: “hay un bug en esta parte del código, encuéntralo y crea un caso de prueba”
• Firefox no está en un estado donde ya se hayan agotado todos los bugs potenciales, pero están satisfechos con la trayectoria actual
• En este momento el escaneo se enfoca principalmente en áreas específicas de código, es decir, archivos y funciones seleccionados mediante una mezcla de juicio humano y señales automáticas
• En el futuro cercano planean integrar este análisis en el sistema de integración continua para escanear los parches cuando entren al tree
• Los modelos se adaptan con flexibilidad al formato de contexto que se les da, y esperan que el escaneo basado en parches funcione igual de bien o mejor que el escaneo basado en archivos
• El momento actual es riesgoso, pero también ofrece una gran oportunidad, y hay que actuar juntos para hacer internet más seguro

Preguntas frecuentes

• Por qué “271 bugs” y el número de avisos de seguridad no coinciden

  • La página web de avisos de seguridad agrupa varios bugs reportados internamente en CVE de tipo “rollup”, donde múltiples bugs quedan reunidos bajo uno solo
  • La página se genera a partir del yaml del repositorio foundation-security-advisories, que es la ubicación formal para la asignación de CVE
  • Algunos navegadores no crean identificadores CVE para issues encontrados internamente, pero Mozilla los divulga para ofrecer la mayor transparencia posible
  • Firefox 150 tuvo 3 rollups internos
    • CVE-2026-6784: 154 bugs
    • CVE-2026-6785: 55 bugs
    • CVE-2026-6786: 107 bugs
  • La suma de los tres rollups internos es 316, más que los 271 bugs que se anunció haber encontrado con Claude Mythos Preview
  • La razón es que el equipo de seguridad de Mozilla ataca Firefox todos los días para encontrar nuevos bugs, usando una combinación de sistemas de fuzzing, revisión manual y el nuevo pipeline agéntico con varios modelos
  • En la release de abril se corrigieron 423 bugs de seguridad en total
    • Los 271 bugs anunciados hace dos semanas
    • 41 bugs reportados externamente
    • Los 111 restantes fueron hallazgos internos y se dividen aproximadamente en tres grupos
      • Bugs encontrados con este pipeline usando Claude Mythos Preview, pero corregidos en una release distinta de Firefox 150
      • Bugs encontrados con este pipeline usando otros modelos
      • Bugs encontrados con otras técnicas, como fuzzing
  • Anthropic recibió crédito directo por 3 CVE aparte de este trabajo más reciente
    • CVE-2026-6746
    • CVE-2026-6757
    • CVE-2026-6758
  • Se trata de correcciones de bugs enviados hace meses a Mozilla por el Anthropic Frontier Red Team, y a cada uno se le asignó un CVE único según el procedimiento habitual

• Qué significan las calificaciones de severidad de seguridad

  • Mozilla aplica security severity ratings desde critical hasta low para indicar la urgencia de un bug
  • sec-critical y sec-high se asignan a vulnerabilidades que pueden activarse con acciones normales de un usuario, como visitar una página web
  • No hay una diferencia técnica entre sec-critical y sec-high, pero sec-critical se usa solo para issues que ya fueron divulgados públicamente o se sabe que fueron explotados en ataques reales
  • sec-moderate se asigna a vulnerabilidades que de otro modo serían sec-high, pero que requieren pasos anómalos y complejos por parte de la víctima
  • sec-low se asigna a bugs molestos pero lejanos de causar daño al usuario, como un crash seguro
  • Las calificaciones de los 271 bugs anunciados en Firefox 150 fueron las siguientes
    • 180 sec-high
    • 80 sec-moderate
    • 11 sec-low
  • Mozilla considera critical/high como lo más importante, pero también suele priorizar bugs de seguridad moderate y low para corregir problemas de exactitud y reforzar la defensa en profundidad

• La diferencia entre sec-high o sec-critical y un exploit real

  • Que un bug sea sec-high o sec-critical no significa automáticamente que exista un exploit práctico
  • En la mayoría de los casos, un solo bug critical/high no basta por sí mismo para comprometer Firefox
  • Firefox tiene una arquitectura de defensa en profundidad, así que por ejemplo explotar un bug del JIT solo da ejecución remota de código dentro de un proceso sandboxeado y aislado por sitio
  • En un ataque real, normalmente el atacante debe encadenar varios exploits para elevar privilegios a través de una o más capas de sandboxing y mitigaciones a nivel del sistema operativo como ASLR
  • Mozilla por lo general no desarrolla exploits para confirmar si un bug sería utilizable por atacantes reales
  • La clasificación sec-high se basa en síntomas de crash predecibles, como use-after-free o problemas de memoria out-of-bounds reportados por AddressSanitizer
  • El modelo de amenazas asume que con suficiente esfuerzo este tipo de bugs podría llegar a ser explotable
  • Este enfoque reduce el riesgo de falsos negativos en el análisis de explotabilidad y permite concentrar recursos en encontrar y corregir más vulnerabilidades

[GN⁺]

Opiniones en Lobste.rs

• Ojalá también publicaran los prompts y otras funciones que usaron en este trabajo
  Estaría bien incluir los prompts en los reportes de bugs o en el historial de soluciones para que se pueda reproducir
  Como también mencionaron modelos que no son Mythos, parece que parte de este trabajo podría ser útil de inmediato para otras personas

  • En la mayoría de los proyectos, la barrera de entrada es realmente baja
    Básicamente, basta con decir “revisa este proyecto desde la perspectiva de problemas de seguridad, empezando por (archivo), y enumera todas las rutas posibles”, y luego continuar con cada punto: “verifica este reporte y crea una prueba de concepto”
    En este momento, usando Opus, es más difícil no encontrar algo con este método
  • ¿De verdad creen que el prompt fue algo más que “encuentra vulnerabilidades de seguridad en este codebase”?

• Digan lo que digan, esto es realmente impresionante
  Encontraron 271 problemas de seguridad con Mythos y 423 en total
  De esos, 180 eran de alta severidad, y algunos problemas de seguridad tenían 20 años de antigüedad

  • No está del todo claro qué tan justa fue la comparación entre Opus 4.6 y Mythos
    Se sugiere algo como que Mythos encontró “271 bugs” en código que ya había sido escaneado antes de la misma manera con 4.6, pero el texto no dice exactamente eso
    Me pregunto si el harness de investigación también cambió al mismo tiempo

• La parte de “uno de los varios problemas sec-high que corregimos estaba relacionado con XSLT” parece estar ahí por la controversia sobre eliminar XSLT

• Lo que más curiosidad me da aquí es cuántos falsos positivos también se reportaron
  Me pregunto si el modelo reportó aproximadamente el doble de vulnerabilidades potenciales y si las que aparecen aquí son las confirmadas
  Tampoco sé si el modelo llega a reproducirlas antes de reportarlas
  En los issues públicos se ven comentarios que parecen intentar reproducirlas, aunque también podría ser un bot que ya existía
  No sé bien cómo Firefox manejaba este tipo de cosas originalmente ni cómo lo hace ahora con IA, así que una explicación más detallada sería muy interesante