Según informes, GLM 5.3 creó cadenas de exploits autónomas contra Firefox antes de que los parches llegaran a los usuarios
Investigadores de Epoch AI afirman que el modelo de pesos abiertos GLM 5.3 creó de forma autónoma cadenas de exploits contra Firefox, poniendo de manifiesto los riesgos de las brechas entre parches para navegadores y proveedores de software.
Un modelo de IA de pesos abiertos habría creado cadenas de exploits funcionales contra seis versiones de Firefox antes de que los usuarios recibieran las actualizaciones de seguridad correspondientes, según una investigación de Epoch AI recogida por The Decoder. Las pruebas sugieren que un modelo capaz puede convertir cambios de código visibles públicamente en ataques durante el breve periodo entre el momento en que un arreglo puede descubrirse y aquel en que el parche llega a la mayoría de los usuarios.
El modelo, GLM 5.3, operó sin intervención humana después de que los investigadores le proporcionaran una versión objetivo de Firefox, herramientas básicas e información pública en un entorno desconectado. Según los informes, los ataques resultantes podían leer archivos locales cuando la víctima cargaba una página web especialmente preparada. Epoch AI estimó en unos 1.000 dólares el coste de API de cada prueba exitosa contra una versión de Firefox.
Los hallazgos trascienden un solo navegador. Indican que los modelos de pesos abiertos podrían permitir a los atacantes automatizar la investigación de vulnerabilidades y el desarrollo de exploits sin depender de la aprobación ni de los controles de seguridad de un gran proveedor de IA.
La prueba de Firefox y sus evidencias
Los investigadores de Epoch AI diseñaron el ejercicio en torno a la “brecha del parche”: el intervalo en el que una corrección de seguridad es visible en el código fuente u otro material público, pero todavía no se ha entregado a los usuarios. Firefox disimula los cambios relacionados con la seguridad entre mejoras rutinarias del código, pero los investigadores dijeron que GLM 5.3 identificó las correcciones pertinentes y las utilizó para investigar vulnerabilidades.
Después, el modelo seleccionó errores, desarrolló fases del exploit e intentó eludir las defensas de Firefox. En un caso señalado, encontró un fallo de seguridad de memoria, lo utilizó para interactuar con la memoria del navegador y añadió nuevas fases después de que Firefox bloqueara el acceso directo al archivo objetivo. El intento exitoso más rápido tardó 12 horas; los investigadores permitieron hasta 48 horas para cada ejecución.
Según el informe, el modelo redescubrió de forma independiente una vulnerabilidad adicional desconocida hasta entonces durante cada ataque exitoso. Ese fallo permitió que la cadena de exploits eludiera el sandbox del navegador y accediera a archivos del ordenador. Epoch AI comunicó el problema a Mozilla, que lo corrigió en Firefox 159.0, publicado el 27 de octubre de 2026. Los investigadores no han establecido hasta qué punto las mismas técnicas serían eficaces contra esa versión.
El impacto comunicado habría sido grave si la cadena se hubiera desplegado contra usuarios normales. Una página web maliciosa podría haber accedido potencialmente a contraseñas guardadas, cookies de autenticación y documentos privados, aunque la investigación no afirma que estos ataques se utilizaran en la práctica. Según las cifras citadas en el informe, Firefox tiene más de 200 millones de usuarios activos, lo que aumenta la posible escala de exposición.
Lo que muestran las pruebas —y lo que no muestran
Las afirmaciones de rendimiento más contundentes proceden del ejercicio de investigación de Epoch AI, según lo informó The Decoder, no de una prueba pública independiente ni de una campaña delictiva confirmada. El experimento muestra lo que GLM 5.3 logró bajo la configuración de los investigadores, pero no demuestra que cualquier atacante pudiera reproducir los resultados con el mismo coste o rapidez.
Los investigadores también probaron Chrome y gastaron unos 100.000 dólares en tarifas de API sin producir un exploit equivalente. Ese resultado no debe interpretarse como prueba de que Chrome sea inmune. Epoch AI advirtió que distintas instrucciones, herramientas o un modelo más capaz podrían cambiar el resultado. La prueba tampoco ofrece una comparación directa con Kimi K3.1 Pro, que los investigadores citaron como posible modelo más fuerte para tareas cibernéticas ofensivas basándose en información limitada de benchmarks.
La ausencia de negativas es otro hallazgo importante, pero requiere una interpretación cuidadosa. Epoch AI dijo que ni Z.ai ni los demás proveedores de API probados bloquearon las solicitudes ni activaron barreras de seguridad. Los investigadores presentaron el trabajo como un ejercicio de seguridad, aunque reconocieron que la configuración era operativamente similar a un ataque contra usuarios reales. Las políticas de los proveedores, las versiones de los modelos y los controles de acceso pueden cambiar tras la divulgación.
El incidente tampoco demuestra que GLM 5.3 pueda comprometer de forma fiable cualquier software. Demuestra un resultado reproducible contra un objetivo específico y durante una ventana concreta de publicación. Esta distinción es importante para los equipos de seguridad que evalúan la adopción de sistemas autónomos de programación o investigación de vulnerabilidades.
Por qué las brechas entre parches importan más allá de Firefox
La debilidad estructural está en el momento de la divulgación y la distribución, no únicamente en Firefox. Una vez que un parche revela qué código cambió, los atacantes suelen poder inferir el defecto subyacente. Un sistema de IA puede acelerar ese proceso comparando revisiones, probando hipótesis, escribiendo código de prueba de concepto y encadenando distintas debilidades.
Epoch AI afirmó que existe una exposición similar en navegadores, sistemas operativos móviles, firmware de routers y otros programas. Los proyectos de código abierto facilitan la inspección del código fuente, pero los productos de código cerrado no están protegidos automáticamente. Los investigadores señalaron trabajos anteriores con Claude Mythos de Anthropic, que supuestamente explotó una brecha de parche de Windows sin acceso al código fuente, y la mejora de las capacidades de los modelos para descompilar software compilado.
Los productos con ciclos de actualización lentos podrían afrontar el mayor peligro. Los usuarios de firmware de routers y sistemas operativos móviles pueden permanecer sin parches durante periodos prolongados, mientras que el software empresarial quizá solo se actualice durante ventanas de mantenimiento programadas. Una vulnerabilidad difícil de explotar manualmente podría resultar más atractiva cuando un sistema de IA puede trabajar de forma continua y barata después de publicarse una corrección.
El informe también plantea preguntas sobre la divulgación coordinada. Publicar una corrección es necesario para los defensores, pero divulgar cambios de código detallados antes de que los parches estén instalados de forma generalizada puede proporcionar a los atacantes una hoja de ruta. Firefox y Chrome han avanzado hacia actualizaciones semanales, pero la velocidad de actualización por sí sola no resuelve el problema en dispositivos que los usuarios rara vez reinician o que los proveedores ya no mantienen activamente.
Implicaciones para desarrolladores y empresas
Los equipos de productos de IA deberían considerar la capacidad cibernética autónoma una cuestión de despliegue y control de acceso, no solo de calidad del modelo. Los sistemas capaces de inspeccionar repositorios, ejecutar código y consultar servicios externos deberían estar aislados, registrados y limitados en frecuencia. Un asistente general de programación puede convertirse en una herramienta de investigación de vulnerabilidades cuando recibe el objetivo, las herramientas y el presupuesto de tiempo adecuados.
Los proveedores de software pueden reducir la exposición coordinando la publicación de parches con su disponibilidad generalizada, minimizando detalles innecesarios en los cambios previos al lanzamiento y revisando si varias correcciones pueden encadenarse. Estas medidas implican compromisos: los defensores necesitan información suficiente para validar una corrección, mientras que el secreto resulta más difícil cuando un cambio entra en un repositorio público.
Los compradores empresariales deberían preguntar a los proveedores con qué rapidez llegan los parches a las versiones compatibles, si las actualizaciones son automáticas y cuánto tiempo siguen expuestos los dispositivos después de divulgarse una vulnerabilidad. Los equipos de seguridad también deberían tener en cuenta el coste de la explotación asistida por IA al priorizar las ventanas de parcheo. Los 1.000 dólares por intento contra Firefox no son un precio universal, pero ilustran que el desarrollo de exploits podría resultar asequible para grupos con recursos limitados.
Para los proveedores de IA, el episodio pone de relieve los límites de confiar únicamente en las negativas. Los modelos de pesos abiertos pueden descargarse y ejecutarse fuera del control de un guardián central. La supervisión del proveedor sigue siendo importante para los sistemas alojados, pero los defensores también necesitan controles de red, sandboxing, parcheo rápido y detección de actividades de desarrollo de exploits.
Qué observar a continuación
La primera señal será si investigadores independientes reproducen los resultados de Firefox contra versiones posteriores, incluida Firefox 159.0, y si Mozilla informa de pruebas de explotación fuera del entorno de prueba. La segunda será si otros equipos demuestran ataques comparables basados en brechas de parches contra Chrome, sistemas operativos móviles o firmware de routers.
Las evaluaciones de modelos también deberán superar los benchmarks cibernéticos estáticos. Las mediciones útiles deberían incluir el tiempo hasta el exploit, la intervención humana, los requisitos de herramientas, el coste total, la fiabilidad entre versiones y la capacidad de encadenar vulnerabilidades. Los resultados con Kimi K3.1 Pro o con modelos de pesos abiertos más recientes ayudarían a determinar si GLM 5.3 representa una capacidad aislada o parte de una tendencia más amplia.
Por último, los proveedores y laboratorios de IA podrían cambiar sus políticas de acceso, prácticas de publicación o salvaguardas tras la divulgación. Esos cambios mostrarán si la industria responde principalmente restringiendo los modelos o acortando el periodo en que las correcciones públicas se adelantan a la protección de los usuarios.
La perspectiva de Creati.ai
La noticia importante no es simplemente que GLM 5.3 encontrara un exploit de Firefox. Es que, según los informes, un sistema de pesos abiertos completó una tarea de seguridad de varias fases dentro de un plazo y un coste realistas, utilizando información que quedó disponible mediante actividades normales de parcheo. Esto desplaza la atención de si los modelos pueden escribir código de exploits a la rapidez con la que pueden convertir el mantenimiento rutinario del software en un riesgo operativo.
Para desarrolladores y compradores empresariales, la lección práctica es evaluar los sistemas de IA junto con los entornos y permisos que los rodean. Una distribución más rápida de los parches, un acceso controlado a las herramientas y salvaguardas medibles serán tan importantes como la capacidad del modelo. El caso de Firefox sigue siendo un resultado de investigación, no una prueba de explotación generalizada, pero constituye una advertencia creíble de que la brecha del parche se está convirtiendo en un problema de automatización.
