GLM 5.3 aurait conçu des chaînes d’exploitation autonomes contre Firefox avant l’arrivée des correctifs chez les utilisateurs

Un modèle d’IA à poids ouverts aurait conçu des chaînes d’exploitation fonctionnelles contre six versions de Firefox avant que les utilisateurs ne reçoivent les mises à jour de sécurité correspondantes, selon une étude d’Epoch AI rapportée par The Decoder. Les tests suggèrent qu’un modèle suffisamment performant peut transformer des changements de code visibles publiquement en attaques pendant le bref intervalle entre la découverte d’un correctif et son arrivée chez la plupart des utilisateurs.

Le modèle GLM 5.3 a fonctionné sans intervention humaine après que les chercheurs lui ont fourni une version cible de Firefox, des outils de base et des informations publiques dans un environnement hors ligne. Les attaques obtenues auraient pu lire des fichiers locaux lorsqu’une victime chargeait une page web spécialement préparée. Epoch AI a estimé le coût des API à environ 1 000 dollars pour chaque test réussi d’une version de Firefox.

Ces résultats dépassent le seul cas de ce navigateur. Ils indiquent que les modèles à poids ouverts pourraient permettre aux attaquants d’automatiser la recherche de vulnérabilités et le développement d’exploits sans dépendre de l’autorisation ou des contrôles de sécurité d’un grand fournisseur d’IA.

Le test de Firefox et ses éléments de preuve

Les chercheurs d’Epoch AI ont conçu l’exercice autour du « décalage du correctif » : l’intervalle durant lequel un correctif de sécurité est visible dans le code source ou d’autres documents publics, mais n’a pas encore été distribué aux utilisateurs. Firefox dissimule les changements liés à la sécurité parmi les améliorations ordinaires du code, mais les chercheurs ont indiqué que GLM 5.3 avait identifié les correctifs pertinents et les avait utilisés pour étudier les vulnérabilités.

Le modèle a ensuite sélectionné des bugs, développé des étapes d’exploitation et tenté de contourner les défenses de Firefox. Dans un cas signalé, il a trouvé une faille de sécurité mémoire, l’a utilisée pour interagir avec la mémoire du navigateur et a ajouté d’autres étapes après que Firefox eut bloqué l’accès direct au fichier ciblé. La tentative réussie la plus rapide a duré 12 heures ; les chercheurs avaient prévu jusqu’à 48 heures pour chaque exécution.

Selon le rapport, le modèle a redécouvert indépendamment une vulnérabilité supplémentaire jusque-là inconnue lors de chaque attaque réussie. Cette faille a permis à la chaîne d’exploitation de contourner la sandbox du navigateur et d’accéder aux fichiers de l’ordinateur. Epoch AI a signalé le problème à Mozilla, qui l’a corrigé dans Firefox 159.0, publié le 27 octobre 2026. Les chercheurs n’ont pas établi l’efficacité des mêmes techniques contre cette version.

L’impact rapporté aurait été grave si la chaîne avait été déployée contre des utilisateurs ordinaires. Une page web malveillante aurait potentiellement pu accéder aux mots de passe enregistrés, aux cookies d’authentification et aux documents privés, même si l’étude ne prétend pas que ces attaques ont été utilisées dans la nature. Firefox compte plus de 200 millions d’utilisateurs actifs selon les chiffres cités, ce qui accroît l’ampleur potentielle de l’exposition.

Ce que montrent les éléments de preuve — et ce qu’ils ne montrent pas

Les affirmations de performance les plus fortes proviennent de l’exercice de recherche d’Epoch AI rapporté par The Decoder, et non d’un benchmark public indépendant ou d’une campagne criminelle confirmée. L’expérience montre ce que GLM 5.3 a réalisé dans le cadre défini par les chercheurs, mais ne prouve pas que tous les attaquants pourraient reproduire ces résultats au même coût ou à la même vitesse.

Les chercheurs ont également testé Chrome et dépensé environ 100 000 dollars en frais d’API sans produire d’exploit équivalent. Ce résultat ne doit pas être interprété comme une preuve que Chrome est immunisé. Epoch AI a averti que d’autres instructions, outils ou un modèle plus performant pourraient modifier l’issue. Le test ne fournit pas non plus de comparaison directe avec Kimi K3.1 Pro, que les chercheurs ont cité comme potentiellement plus performant pour les tâches cyber offensives sur la base d’informations limitées de benchmark.

L’absence de refus constitue une autre découverte importante, mais elle doit être interprétée avec prudence. Epoch AI a déclaré que ni Z.ai ni les autres fournisseurs d’API testés n’avaient bloqué les demandes ou déclenché de garde-fous. Les chercheurs ont présenté le travail comme un exercice de sécurité tout en reconnaissant que la configuration ressemblait, sur le plan opérationnel, à une attaque contre de vrais utilisateurs. Les politiques des fournisseurs, les versions des modèles et les contrôles d’accès peuvent évoluer après la divulgation.

L’incident n’établit pas non plus que GLM 5.3 puisse compromettre de façon fiable n’importe quel logiciel. Il démontre un résultat reproductible contre une cible précise et pendant une fenêtre de publication donnée. Cette distinction est importante pour les équipes de sécurité qui évaluent l’adoption de systèmes autonomes de programmation ou de recherche de vulnérabilités.

Pourquoi les décalages de correctifs dépassent le cas de Firefox

La faiblesse structurelle tient au calendrier de la divulgation et de la distribution, et non à Firefox seul. Dès qu’un correctif révèle le code modifié, les attaquants peuvent souvent déduire le défaut sous-jacent. Un système d’IA peut accélérer ce processus en comparant les révisions, en testant des hypothèses, en écrivant du code de preuve de concept et en enchaînant plusieurs faiblesses.

Epoch AI affirme qu’une exposition similaire existe pour les navigateurs, les systèmes d’exploitation mobiles, les firmwares de routeurs et d’autres logiciels. Les projets open source facilitent l’inspection du code source, mais les produits propriétaires ne sont pas automatiquement protégés. Les chercheurs ont cité des travaux antérieurs impliquant Claude Mythos d’Anthropic, qui aurait exploité un décalage de correctif Windows sans accès au code source, ainsi que l’amélioration des capacités des modèles à décompiler des logiciels compilés.

Les produits dont les cycles de mise à jour sont lents pourraient être les plus exposés. Les utilisateurs de firmwares de routeurs et de systèmes mobiles peuvent rester non corrigés pendant de longues périodes, tandis que les logiciels d’entreprise ne sont parfois mis à jour que lors de fenêtres de maintenance planifiées. Une vulnérabilité difficile à exploiter manuellement pourrait devenir plus attractive si un système d’IA peut travailler en continu et à faible coût après la publication d’un correctif.

Le rapport soulève aussi des questions sur la divulgation coordonnée. Publier un correctif est nécessaire aux défenseurs, mais divulguer des changements de code détaillés avant l’installation généralisée des correctifs peut fournir une feuille de route aux attaquants. Firefox et Chrome se dirigent vers des mises à jour hebdomadaires, mais la vitesse de mise à jour ne suffit pas pour les appareils rarement redémarrés par les utilisateurs ou que les fournisseurs ne maintiennent plus activement.

Implications pour les concepteurs et les entreprises

Les équipes chargées des produits d’IA devraient considérer la capacité cyber autonome comme un problème de déploiement et de contrôle d’accès, pas seulement de qualité du modèle. Les systèmes capables d’inspecter des dépôts, d’exécuter du code et d’interroger des services externes devraient être isolés, journalisés et limités en débit. Un assistant de programmation généraliste peut devenir un outil de recherche de vulnérabilités lorsqu’on lui fournit la bonne cible, les bons outils et un budget de temps suffisant.

Les éditeurs de logiciels peuvent réduire l’exposition en coordonnant la publication des correctifs avec leur disponibilité étendue, en limitant les détails inutiles dans les changements préalables et en vérifiant si plusieurs correctifs peuvent être enchaînés. Ces mesures impliquent des compromis : les défenseurs ont besoin de suffisamment d’informations pour valider un correctif, tandis que le secret devient plus difficile dès qu’une modification entre dans un dépôt public.

Les acheteurs professionnels devraient demander aux fournisseurs à quelle vitesse les correctifs atteignent les versions prises en charge, si les mises à jour sont automatiques et combien de temps les appareils restent exposés après la divulgation d’une vulnérabilité. Les équipes de sécurité devraient également intégrer le coût de l’exploitation assistée par IA dans la priorisation des fenêtres de correctifs. Les 1 000 dollars rapportés par tentative contre Firefox ne constituent pas un prix universel, mais montrent que le développement d’exploits pourrait devenir abordable pour des groupes disposant de ressources limitées.

Pour les fournisseurs d’IA, l’épisode souligne les limites d’une dépendance aux seuls refus. Les modèles à poids ouverts peuvent être téléchargés et exécutés en dehors du contrôle d’un gardien central. La surveillance côté fournisseur reste importante pour les systèmes hébergés, mais les défenseurs ont aussi besoin de contrôles réseau, de sandboxing, de correctifs rapides et de détection des activités de développement d’exploits.

Les prochains éléments à surveiller

Le premier indicateur sera de savoir si des chercheurs indépendants reproduisent les résultats de Firefox contre des versions ultérieures, notamment Firefox 159.0, et si Mozilla signale des preuves d’exploitation hors de l’environnement de test. Le second sera de voir si d’autres équipes démontrent des attaques comparables liées au décalage des correctifs contre Chrome, les systèmes mobiles ou les firmwares de routeurs.

Les évaluations des modèles devront également dépasser les benchmarks cyber statiques. Les mesures utiles devraient inclure le temps nécessaire pour obtenir un exploit, l’intervention humaine, les outils requis, le coût total, la fiabilité entre les versions et la capacité à enchaîner les vulnérabilités. Des résultats concernant Kimi K3.1 Pro ou de nouveaux modèles à poids ouverts aideraient à déterminer si GLM 5.3 représente une capacité isolée ou une tendance plus large.

Enfin, les fournisseurs et les laboratoires d’IA pourraient modifier leurs politiques d’accès, leurs pratiques de publication ou leurs garde-fous après la divulgation. Ces changements montreront si le secteur répond principalement en restreignant les modèles ou en réduisant la période durant laquelle les correctifs publics devancent la protection des utilisateurs.

Le point de vue de Creati.ai

L’information importante n’est pas simplement que GLM 5.3 a trouvé un exploit Firefox. C’est qu’un système à poids ouverts aurait réalisé une tâche de sécurité en plusieurs étapes dans un cadre de temps et de coût réaliste, en utilisant des informations rendues disponibles par l’activité normale de correction. L’attention se déplace ainsi de la question de savoir si les modèles peuvent écrire du code d’exploitation vers celle de la vitesse à laquelle ils peuvent transformer la maintenance logicielle courante en risque opérationnel.

Pour les concepteurs et les acheteurs professionnels, la leçon pratique est d’évaluer les systèmes d’IA avec les environnements et les permissions qui les entourent. Une distribution plus rapide des correctifs, un accès contrôlé aux outils et des protections mesurables compteront autant que les capacités du modèle. Le cas Firefox reste un résultat de recherche plutôt qu’une preuve d’exploitation généralisée, mais il avertit de manière crédible que le décalage des correctifs devient un problème d’automatisation.