El modelo abierto GLM 5.3 creó por sí solo exploits para Firefox: $1000 por versión

Los investigadores de Epoch AI, que miden las capacidades de la IA, han demostrado que el modelo chino de pesos abiertos GLM 5.3 (desarrollado por Z.ai) puede construir por sí solo, sin ayuda humana, una cadena de ataque completa contra Firefox.

Le lleva entre 12 y 48 horas, y cada ataque exitoso cuesta alrededor de $1000 en uso de API. El modelo explota la «brecha de parches»: la ventana en la que la corrección de una vulnerabilidad ya se ha publicado en el código abierto, pero la actualización aún no ha llegado a los usuarios. El ataque final funciona así: una persona entra en una página preparada a propósito, y esta lee los archivos de su ordenador y los envía al servidor del atacante.

Cómo el modelo localizó las vulnerabilidades a partir de correcciones ajenas

Las condiciones del experimento se mantuvieron modestas a propósito. Los investigadores querían estimar de qué es capaz un atacante con poca cualificación y un presupuesto limitado. Al modelo se le proporcionó:

• la versión necesaria de Firefox; • herramientas básicas; • información pública; • un entorno aislado sin acceso a internet; • una breve instrucción para estudiar la brecha de parches.

Después, el modelo trabajó solo. Buscó en el código las futuras correcciones de seguridad, eligió vulnerabilidades y montó ataques de varias etapas.

La primera dificultad es que Firefox camufla este tipo de cambios como mejoras corrientes, para ponérselo más difícil a los atacantes. GLM 5.3 descubrió ese truco y, aun así, identificó qué cambios estaban relacionados con la seguridad. En un caso, a partir de una corrección en preparación detectó un error de gestión de memoria e ideó cómo leer y modificar la memoria del navegador.

Después chocó con las capas de protección integradas de Firefox: al principio el modelo no logró llegar al archivo necesario. Entonces añadió al primer exploit varias etapas más y esquivó las barreras restantes. En todos los ataques exitosos contra versiones actuales se apoyó en la misma vulnerabilidad desconocida hasta entonces. El modelo la volvía a encontrar en cada intento. Ese fallo permitía salir de la «sandbox», es decir, del entorno aislado del navegador, y leer archivos directamente del ordenador.

Las cifras son estas:

• 6 versiones de Firefox, publicadas entre el 17 de septiembre y el 26 de octubre; • alrededor de $1000 en API por cada ataque exitoso; • 12 horas tardó el ataque más rápido; el máximo fue de 48; • más de 200 millones de usuarios activos de Firefox, potencialmente en riesgo, incluidas contraseñas guardadas, cookies de autenticación y documentos personales.

Los autores señalan aparte que ni Z.ai ni otros proveedores de API activaron filtros de protección ni rechazaron la solicitud. La tarea se planteó como un ejercicio de seguridad, pero por su comportamiento era indistinguible de un intento de atacar a personas reales.

Sobre la divulgación responsable: el equipo informó de la vulnerabilidad a Mozilla, que la cerró en Firefox 159.0, del 27 de octubre de 2026. Los autores no comprobaron si el mismo método funcionaría contra la nueva versión. Consideran que atacar se ha vuelto «como mínimo notablemente más difícil».

Chrome resistió por ahora, pero eso no es una garantía

Se probó el mismo enfoque contra Google Chrome. Se gastaron unos $100 000 en API y no se obtuvo un equivalente funcional. Los autores subrayan que esto no demuestra que Chrome sea invulnerable. Un planteamiento mejor de la tarea o modelos más potentes podrían conseguirlo. Citan datos de pruebas limitados según los cuales Kimi K3.1 Pro, anunciado hace poco, podría superar a GLM 5.3 en tareas ofensivas. Ellos mismos no la probaron.

Hay otra advertencia: el problema va más allá de los navegadores. La brecha de parches existe en los sistemas operativos móviles y en el firmware de los routers. Los proyectos abiertos son más vulnerables porque todo su código es público, pero eso no ayuda a los cerrados. Anthropic ya ha mostrado que su modelo Mythos sabe aprovechar la brecha de parches en Windows sin acceso al código fuente, y los modelos son cada vez mejores descompilando programas y encontrando por sí mismos las correcciones de seguridad en ellos.

Hay ejemplos reales. Según el informe, en septiembre de 2026 se usó la brecha de parches en ataques contra Chrome. Ese mismo mes, un proveedor publicó compilaciones corregidas de PHP más de seis horas antes del lanzamiento acordado de los parches para dos fallos críticos. Según informes externos, esto pudo provocar miles de intentos de explotación antes de la publicación oficial y millones justo después. El riesgo es especialmente alto donde los usuarios actualizan poco: los routers y los sistemas móviles siguen siendo vulnerables durante mucho más tiempo.

Actualizar más rápido no basta: qué recomiendan los autores

Las recomendaciones de los investigadores son estas:

• mantener las correcciones de seguridad privadas hasta que estén listas para su publicación; • trasladarlas más rápido de la versión beta a la versión estable; • no cerrar en un mismo paquete vulnerabilidades que puedan encadenarse.

Firefox y Chrome ya han pasado a actualizaciones semanales. Pero eso no elimina el problema estructural: en cuanto una corrección llega al código público, señala al atacante la propia vulnerabilidad. Que los defensores tengan acceso a modelos cerrados potentes tampoco resuelve la cuestión.

Tras el lanzamiento de Claude Mythos Preview de Anthropic en abril de 2026, los laboratorios punteros restringieron el acceso a sus modelos y pusieron en marcha programas de acceso anticipado para defensores, entre ellos Glasswing y Daybreak. Pero a medida que los modelos abiertos se vuelven más potentes, las capacidades ofensivas escapan al control de cualquier «guardián» único. Los autores escriben que ven en los resultados un indicio de la difusión de ciberhabilidades avanzadas. Según su estimación, es probable que muchos otros programas ya sean vulnerables a ataques de este tipo, y que su número crezca con la llegada de modelos abiertos más potentes.

Para ingenieros y proveedores, la conclusión es sencilla: la ventana entre la publicación de la corrección y la actualización en los usuarios debe tratarse ya como tiempo de ataque activo, y los procesos de publicación de parches deben diseñarse asumiendo que una IA lee cada commit público.