Ce que l’expérience a montré
Epoch AI a publié une expérience dans laquelle GLM-5.3, un modèle à poids ouverts développé par Z.ai, a réussi à construire des attaques contre six versions récentes de Firefox. L’étude porte sur la fenêtre de mise à jour : la période pendant laquelle un correctif de sécurité est déjà visible dans le code, mais n’a pas encore été distribué à tous les utilisateurs dans une version stable.
Lors des essais, une page web conçue par le modèle pouvait amener le navigateur à lire un fichier local et à en envoyer le contenu à un serveur, sans autre action de la personne qui consultait la page. Le résultat est grave, mais sa portée est précise : il décrit ce qui s’est produit dans les environnements et avec les versions testés. Il ne démontre pas que toutes les installations de Firefox, tous les navigateurs ou tous les systèmes sont vulnérables de la même façon.
Que signifie la fenêtre de mise à jour ?
Un correctif peut devenir visible avant que la mise à jour correspondante soit proposée au grand public. Dans les projets open source, les changements présents dans des branches de développement ou des versions bêta peuvent révéler des indices sur les failles en cours de correction. Un attaquant qui repère ces changements peut tenter de reconstituer le problème et de préparer une attaque contre des versions qui n’intègrent pas encore le correctif.
La fenêtre ne se referme pas nécessairement dès qu’une mise à jour est publiée : certaines personnes ou organisations tardent aussi à l’installer. L’expérience d’Epoch AI se concentrait sur l’intervalle entre la publication d’informations sur les correctifs et leur intégration dans la version stable, et non sur le temps que met chaque utilisateur à effectuer la mise à jour. Cette distinction est importante : le résultat montre une occasion d’attaque, pas un taux de victimes constaté.
Méthode et sens de l’expression « sans intervention humaine »
Epoch AI a indiqué à GLM-5.3 quelle version de Firefox examiner, lui a fourni des outils de base et des informations publiques disponibles à la date de sortie de chaque version, puis a exécuté le modèle sans accès à Internet. Une fois l’environnement préparé, le modèle a repéré des changements liés à la sécurité, sélectionné des failles et tenté d’enchaîner plusieurs étapes d’exploitation. Selon le rapport, il n’a pas reçu de consignes humaines pendant chaque tentative.
L’expression « sans intervention humaine » décrit donc le travail du modèle après la préparation de l’essai et la définition de l’objectif par l’équipe. Elle ne signifie pas que le système a fonctionné sans configuration, sans ressources choisies par les chercheurs ou en dehors d’un environnement d’évaluation. Epoch AI indique avoir accordé jusqu’à 48 heures par tentative ; la plus rapide à réussir a duré 12 heures. La préparation et les essais préliminaires ont également contribué au coût total.
Ce que recouvre l’autonomie, et ce qu’elle ne signifie pas
| Élément | Ce que rapporte l’étude | Limite d’interprétation |
|---|---|---|
| Préparation | L’équipe a choisi les versions, les outils et les informations publiques, puis configuré l’environnement. | Il ne s’agissait pas d’un essai sans préparation humaine. |
| Exécution | Pendant chaque tentative, le modèle a cherché à construire l’attaque sans consignes humaines. | L’autonomie observée concerne cet environnement et cet objectif. |
| Connectivité | Les modèles n’avaient pas accès à Internet ; les ressources nécessaires ont été fournies directement. | Les conditions ne reproduisaient pas toutes celles d’une opération en ligne. |
| Durée | Chaque tentative pouvait durer jusqu’à 48 heures ; la plus rapide à réussir a pris 12 heures. | Cela ne permet pas d’établir le temps nécessaire à un attaquant dans d’autres conditions. |
La chaîne reposait aussi sur une vulnérabilité supplémentaire
Le rapport n’attribue pas les attaques aux seules informations contenues dans les correctifs publics. Epoch AI indique que, pour les versions récentes compromises pendant les essais, GLM-5.3 a aussi trouvé et utilisé une vulnérabilité qui n’avait pas encore été publiée. L’équipe a signalé cette faille à Mozilla, qui l’a corrigée dans Firefox 159.0, publié le 27 octobre 2026.
Cette dépendance est essentielle pour évaluer le résultat. L’étude montre que le modèle a combiné des indices tirés de correctifs visibles avec une autre faille, nécessaire pour contourner des protections du navigateur et lire des fichiers. Epoch AI n’a pas confirmé si les attaques restaient possibles dans Firefox 159.0. L’équipe estime que le correctif devrait les rendre nettement plus difficiles, mais cela ne constitue pas une validation ultérieure excluant le risque. Le rapport n’affirme pas non plus que le modèle a obtenu l’exécution de code arbitraire sur les versions récentes.
Coûts, Chrome et portée des résultats
Epoch AI estime que les dépenses totales de l’étude ont dépassé 100 000 dollars en frais d’API, notamment pour construire l’environnement et effectuer les essais préliminaires. Une fois ce dispositif en place et la tâche orientée vers le problème, le coût marginal estimé pour compromettre une nouvelle version de Firefox était d’environ 1 000 dollars. Ces montants ne sont pas universels : ils dépendent des tarifs d’API et de la configuration de l’expérience.
L’équipe a également essayé une méthode similaire contre Google Chrome, sans obtenir d’attaque équivalente malgré environ 100 000 dollars dépensés en tentatives. Ce résultat ne prouve pas que Chrome est immunisé : le rapport précise que d’autres méthodes de sollicitation ou des modèles plus performants pourraient modifier l’issue. La publication d’Epoch AI documente l’expérience sur Firefox ; l’évaluation de GLM-5.3 par Anthropic porte sur d’autres tests et ne constitue pas une réplication indépendante de la chaîne contre Firefox.
Conclusions que permettent les résultats
| Résultat rapporté | Conclusion prudente |
|---|---|
| Six versions de Firefox ont été compromises dans l’environnement d’Epoch AI. | Dans ces conditions précises, GLM-5.3 a pu construire des attaques. |
| Après la préparation du dispositif, le coût marginal a été estimé à environ 1 000 dollars par version. | Ce montant correspond à une estimation des frais d’API pour ce processus, et non au coût de toute attaque. |
| Aucun exploit équivalent n’a été obtenu contre Chrome malgré environ 100 000 dollars de tentatives. | L’essai n’a pas abouti à une attaque ; il ne démontre pas qu’une telle attaque est impossible. |
| Mozilla a corrigé la vulnérabilité supplémentaire dans Firefox 159.0. | Le correctif est documenté, mais Epoch AI n’a pas confirmé son effet sur la chaîne d’exploitation complète. |
Mesures possibles pour les équipes qui maintiennent des logiciels
Epoch AI estime que la fenêtre de mise à jour peut concerner d’autres catégories de logiciels lorsque les détails d’un correctif deviennent publics avant d’être distribués aux utilisateurs. La publication cite les navigateurs, les systèmes d’exploitation mobiles et les micrologiciels de routeurs parmi les domaines où les retards de mise à jour peuvent compter. Il s’agit d’une évaluation générale du risque, et non d’une démonstration expérimentale selon laquelle GLM-5.3 aurait compromis tous ces produits.
Parmi les mesures proposées par l’équipe figurent le maintien de la confidentialité des correctifs jusqu’à ce que la version soit prête à être distribuée, la réduction du délai entre les versions de test et les versions stables, ainsi que l’évitement de regroupements de correctifs susceptibles d’être enchaînés dans une attaque. Pour les utilisateurs et les administrateurs, installer les mises à jour de sécurité disponibles réduit l’exposition aux failles déjà corrigées ; cela ne suffit pas à éliminer le risque de vulnérabilités inconnues ni à garantir que tous les logiciels sont à jour.
Évaluer les risques dans une équipe logicielle
Pour réduire l’exposition, une équipe peut commencer par repérer à quel moment les changements de sécurité deviennent visibles et mesurer le délai avant leur distribution générale. Elle peut ensuite donner la priorité aux mises à jour des produits dont le déploiement est lent. Il est également utile d’évaluer si plusieurs failles peuvent être enchaînées et si les correctifs peuvent être publiés de façon coordonnée. Ces mesures réduisent certaines possibilités d’attaque, sans garantir l’absence d’autres failles.
- 01Dresser l’inventaire des produits et des versions déployées.
- 02Examiner quelles informations sur les correctifs sont visibles avant la mise à jour générale.
- 03Réduire, lorsque c’est possible, le délai entre la correction et sa distribution.
- 04Prioriser l’installation des mises à jour de sécurité et repérer les versions qui restent exposées.
- 05Évaluer les failles comme des éléments susceptibles de former une chaîne, et pas uniquement comme des problèmes isolés.
Questions ouvertes
- La publication d’Epoch AI est la source primaire de l’expérience portant spécifiquement sur Firefox. Les sources disponibles ne documentent pas de réplication indépendante de ces chaînes d’exploitation.
- Epoch AI n’a pas confirmé si les attaques fonctionnaient encore dans Firefox 159.0 après la correction de la vulnérabilité supplémentaire.
- L’absence d’exploit équivalent lors des essais contre Chrome ne permet pas de conclure que des attaques similaires sont impossibles.
- Le coût marginal d’environ 1 000 dollars par version correspond à un environnement déjà préparé et aux tarifs d’API retenus par Epoch AI ; il ne constitue pas une estimation universelle.
Poursuivre l’exploration
Sources consultées
Corrections et transparence
Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.
Proposer une correction