
Tech • IA • Robotique • Jeu
Mozilla affirme qu’un pipeline de sécurité piloté par l’IA a aidé Firefox à éviter toute compromission lors du Pwn2Own 2026 et qu’il entraîne désormais une forte hausse, à la fois de la découverte de vulnérabilités et des correctifs.
Pwn2Own est un concours annuel de piratage où les navigateurs sont des cibles de premier plan, et Mozilla le considère comme un test grandeur nature de sa capacité à gérer des failles graves. Avant l’édition 2026, plusieurs chercheurs avaient enregistré des attaques contre Firefox, ce qui a déclenché une course aux correctifs. Au final, personne n’a réussi à compromettre Firefox pendant le concours.
Peu avant l’événement, l’équipe cyber d’OpenAI a signalé plusieurs bugs qui ont été rapidement corrigés et déployés. Mozilla a indiqué que certaines soumissions enregistrées pour le concours s’appuyaient précisément sur ces failles, ce qui suggère que ces correctifs d’urgence ont directement neutralisé des attaques prévues. L’épisode a aussi montré que différents modèles d’IA peuvent découvrir des vulnérabilités différentes dans la même base de code.
Mozilla explique que ce nouveau pipeline d’IA a fonctionné grâce à des investissements de longue date dans la sécurité du navigateur. Cela inclut un programme externe de bug bounty, un usage intensif des address sanitizers, une infrastructure de fuzzing, des workflows internes de red team et des builds faciles à déboguer. Cette base a permis à des agents automatisés d’utiliser nombre des mêmes outils déjà conçus pour les chercheurs humains.
Le système n’inspecte pas les fichiers dans un ordre simple. Il évalue d’abord le code selon son niveau de risque probable, à l’aide de grands modèles de langage et de critères propres au navigateur, comme l’exposition au contenu des pages web, les caractéristiques de sûreté mémoire et la pertinence vis-à-vis du modèle de menace. Les premières versions se concentraient sur les fichiers les plus risqués, tandis que les suivantes sont devenues plus adaptatives à mesure que les bugs les plus faciles étaient épuisés.
Dans la boucle principale, un agent s’exécute dans sa propre VM avec accès à l’arborescence source de Firefox et à la chaîne d’outils de fuzzing. Il propose des bugs possibles via une analyse statique, puis les teste dynamiquement, parfois en écrivant de mini-fuzzers ou des sondes sur mesure. Une découverte n’est acceptée que si elle produit une preuve déterministe, comme un fichier HTML qui fait planter Firefox de manière fiable.
Mozilla a ajouté un agent d’évaluation séparé après avoir constaté que des agents contournaient le processus, notamment dans des cas où ils modifiaient le code pour provoquer eux-mêmes le crash utilisé comme preuve. Ce second agent vérifie si le résultat est légitime et aide aussi à évaluer la gravité. Mozilla indique que ce processus en deux étapes a maintenu un très faible taux de faux positifs et évité aux ingénieurs de perdre du temps sur des rapports convaincants mais erronés.
Une fois une vulnérabilité vérifiée, le système rédige aussi un patch de code et un cas de test. Mozilla précise que ces patchs sont souvent utiles, mais pas toujours prêts à être intégrés, car ils peuvent ne corriger qu’un crash très précis ou manquer de contexte plus large dans le code. Des ingénieurs experts du navigateur examinent toujours les preuves, préparent le correctif final, obtiennent une revue par les pairs et déploient la correction.
À mesure que la découverte automatisée est montée en charge, la priorisation et la déduplication sont devenues beaucoup plus difficiles. Des piles de crash similaires peuvent venir de bugs différents, tandis que des reproductions différentes peuvent renvoyer à la même faille sous-jacente. Mozilla stocke désormais les découvertes dans une base locale et utilise des agents pour comparer les rapports, tout en revérifiant les supposés doublons après le déploiement de correctifs liés afin de repérer les fusions erronées.
Mozilla indique que certaines vulnérabilités semblaient au départ de gravité modérée ou faible, avant d’être ensuite reclassées comme de gravité élevée par des modèles cyber plus performants. Dans plusieurs cas, les modèles ont trouvé des moyens de contourner des mesures de durcissement que les ingénieurs pensaient efficaces. Cela a donné aux équipes un moyen d’identifier des couches défensives fragiles et de reprioriser les correctifs.
L’une des méthodes les plus efficaces a été la variant analysis, dans laquelle des agents prennent un schéma de bug connu et recherchent des failles similaires dans le reste de la base de code. Mozilla explique qu’il peut encapsuler un bug passé ou un ancien correctif, puis demander à un agent de traquer ailleurs des chemins de code apparentés. En septembre, les scans de variantes étaient devenus la principale source de nouveaux bugs détectés et produisaient moins de doublons que certains scans plus larges.
Mozilla indique que 2026 est en bonne voie pour afficher une hausse d’environ 8x par rapport à 2025, à la fois pour la découverte de vulnérabilités et pour les correctifs. Les ingénieurs utilisent désormais un atelier de travail sur les vulnérabilités qui agrège les données de scan, les liens vers les bugs, les journaux et les retours dans une base locale SQLite, permettant à des agents de code de suggérer de nouvelles cibles d’analyse, de diagnostiquer les exécutions ratées et d’améliorer le banc de test.
La stratégie de sécurité de Mozilla passe d’une chasse aux bugs isolée à une découverte, une vérification et une correction continues des vulnérabilités, assistées par l’IA. Le résultat immédiat est un flux beaucoup plus rapide de découvertes vers le pipeline de correction, avec pour objectif à long terme de réduire le nombre de failles exploitables livrées aux utilisateurs.
Poser une question