Dans les coulisses du durcissement de Firefox avec Claude Mythos Preview

• Mozilla a mis en place un pipeline capable de trouver à grande échelle de vrais bugs de sécurité dans Firefox, en augmentant le signal et en réduisant le bruit dans les rapports de sécurité générés par l’IA grâce à de meilleures performances des modèles et à l’amélioration du harness
• Dans Firefox 150 release, 271 bugs identifiés par Claude Mythos Preview ont été corrigés, et des correctifs liés sont aussi inclus dans 149.0.2, 150.0.1 et 150.0.2
• Parmi les bugs représentatifs rendus publics figurent un primitive de faux objet causée par l’élimination de l’initialisation d’une structure WebAssembly GC dans le JIT, un UAF du processus parent via une condition de concurrence IPC, un problème de désérialisation de NaN, un bug de rehash vieux de 20 ans dans XSLT, ainsi qu’un overflow d’un bitfield de layout sur 16 bits exploitant rowspan=0
• Une grande partie des bugs publiés sont des évasions de sandbox : ils supposent qu’un processus de contenu déjà compromis élève ses privilèges vers le processus parent, une surface d’attaque que l’analyse par IA couvre plus largement que le fuzzing seul
• Mozilla a superposé un harness agentique à son infrastructure de fuzzing existante afin d’écarter les suppositions non reproductibles et de valider les hypothèses avec des cas de test, avec l’intention à terme de l’intégrer à l’intégration continue pour scanner les patchs lorsqu’ils entrent dans le tree

---

Le changement révélé par les bugs de sécurité Firefox trouvés par des modèles d’IA

• Il y a encore quelques mois, les rapports de bugs de sécurité générés par l’IA soumis aux projets open source paraissaient plausibles mais étaient souvent faux, créant un coût asymétrique pour les mainteneurs
• Dans Firefox, la situation a beaucoup évolué en peu de temps, principalement grâce aux progrès des modèles et à l’amélioration des techniques permettant de piloter, étendre et combiner les modèles avec un harness pour augmenter le signal et filtrer le bruit
• Mozilla garde habituellement les rapports de bugs détaillés non publics pendant plusieurs mois, même après la publication des correctifs et des avis de sécurité, mais a décidé cette fois d’en publier une partie compte tenu de l’urgence et de l’intérêt pour l’ensemble de l’écosystème
• Les rapports publiés couvrent plusieurs sous-systèmes du navigateur ; leur sélection est en partie arbitraire, mais leur profondeur et leur diversité montrent que les défenseurs doivent appliquer ce type de techniques

Bugs représentatifs rendus publics

• 2024918
  • À cause d’une vérification d’égalité incorrecte, le JIT a supprimé par optimisation l’initialisation d’une structure WebAssembly GC encore vivante, ce qui a permis de créer une primitive de faux objet menant potentiellement à des lectures/écritures arbitraires dans un code ayant pourtant fait l’objet d’un fuzzing intensif par des chercheurs internes et externes
• 2024437
  • Un bug vieux de 15 ans dans l’élément <legend>, déclenché par une combinaison sophistiquée de cas limites répartis dans des zones éloignées du navigateur, comme la limite de profondeur de pile récursive, des propriétés expando et le cycle collection
• 2021894
  • Une condition de concurrence IPC pouvait être exploitée de façon fiable pour qu’un processus de contenu compromis manipule le comptage de références d’IndexedDB dans le processus parent, provoquant un UAF et une évasion de sandbox potentielle
• 2022034
  • Un NaN brut pouvait franchir une frontière IPC en ressemblant à un pointeur d’objet JS tagué, si bien que la désérialisation d’un double pouvait mener à une primitive de faux objet dans le processus parent et à une évasion de sandbox
• 2024653
  • Un cas de test complexe mêlant boucles d’événements imbriquées, listener pagehide et garbage collection déclenchait un UAF dans le setter d’attributs de l’élément <object>
• 2022733
  • En injectant des milliers de hachages de certificats dans WebTransport, il était possible d’allonger une condition de concurrence dans une boucle de copie à fort comptage de références, puis de provoquer via IPC un UAF dans le parent à partir d’un processus de contenu compromis
• 2023958
  • En interceptant des appels aux fonctions DNS de glibc pour simuler un serveur DNS malveillant et reproduire un cas limite de fallback d’UDP vers TCP, il était possible de provoquer pendant le parsing de HTTPS RR et d’ECH une lecture hors limites du tampon et une fuite de mémoire de pile du processus parent
• 2025977
  • Un bug XSLT vieux de 20 ans où un appel réentrant à key() déclenchait un rehash de table de hachage, libérait le backing store mais continuait d’utiliser des pointeurs bruts vers les entrées ; c’était l’un des plusieurs problèmes XSLT sec-high corrigés
• 2027298
  • Après avoir patché le sélecteur de couleur pour simuler un choix utilisateur difficile à automatiser, des événements d’entrée synchrones faisaient tourner une boucle d’événements imbriquée, réentraient dans l’actor teardown et provoquaient la libération d’un callback pendant son déroulement, causant un UAF dans le processus de contenu
• 2023817
  • Un processus de contenu compromis pouvait envoyer une image de fond d’écran arbitraire à décoder dans le processus parent ; combiné à une vulnérabilité hypothétique dans un décodeur d’image, cela pouvait mener à une évasion de sandbox
  • Cela nécessitait dans le processus parent un raisonnement difficile à automatiser pour juger du niveau de confiance de l’entrée
• 2029813
  • Dans RLBox, la technologie de sandboxing granulaire introduite avec Firefox 95, il était possible de contourner la sandbox en exploitant une faille dans la logique de validation lors de la copie de valeurs du côté non fiable vers le côté fiable
• 2026305
  • Un cas de test minuscule exploitant la sémantique spéciale de rowspan=0 dans les tableaux HTML ajoutait plus de 65535 lignes pour contourner le clamping et faire déborder un bitfield de layout sur 16 bits, sans être détecté par les fuzzers pendant des années

Évasions de sandbox et couches de défense

• Une grande partie des bugs publiés sont des évasions de sandbox, et ils doivent être chaînés avec d’autres exploits pour conduire à une compromission complète de Firefox
• Ces rapports supposent qu’un processus sandboxé chargé de rendre le contenu d’un site est déjà compromis par un autre bug et que du code machine contrôlé par l’attaquant cherche à élever ses privilèges vers le processus parent privilégié
• Pour produire des évasions de sandbox, le modèle peut patcher le code source de Firefox tant que le code modifié ne s’exécute qu’à l’intérieur du processus sandboxé
• Ce type de bug est difficile à trouver par fuzzing ; Mozilla a développé des techniques comme le fuzzing IPC avec snapshots, mais l’analyse par IA a pu couvrir cette surface importante bien plus largement
• Ce que le modèle n’a pas trouvé restait aussi important
  • Ces dernières années, des chercheurs en sécurité ont envoyé plusieurs rapports montrant comment provoquer une prototype pollution dans le processus parent privilégié afin d’échapper à la sandbox de processus
  • Au lieu de corriger les problèmes un à un, Mozilla a appliqué un changement d’architecture qui fige les prototypes par défaut
  • Les logs du harness montrent de nombreuses tentatives d’emprunter cette voie d’évasion, bloquées par la conception, ce qui confirme directement l’efficacité du travail de durcissement antérieur

Construire un pipeline de durcissement avec un harness

• Mozilla mène en interne depuis plusieurs années des expériences d’audit de code par LLM pour analyser statiquement du code à haut risque avec des modèles comme GPT 4 ou Sonnet 3.5
• Les premières expériences montraient du potentiel, mais la proportion de faux positifs était trop élevée pour passer à l’échelle
• L’arrivée de harness agentiques capables de détecter de façon fiable des problèmes de sécurité a changé la donne
  • ils peuvent trouver de vrais bugs
  • ils permettent d’écarter les suppositions non reproductibles
  • avec les bonnes interfaces et consignes, ils peuvent créer et exécuter des cas de test reproductibles pour valider dynamiquement des hypothèses de bug dans le code
• Après avoir corrigé les premiers problèmes envoyés par Anthropic en février, Mozilla a construit son propre harness au-dessus de son infrastructure de fuzzing existante
• Au départ, Mozilla a lancé à petite échelle des expériences avec Claude Opus 4.6 pour rechercher des évasions de sandbox
  • même ce seul modèle a identifié un nombre important de vulnérabilités jusque-là inconnues, nécessitant un raisonnement complexe sur le code d’un moteur de navigateur multiprocessus
  • au début, l’équipe observait directement le processus dans le terminal en ajustant en temps réel les prompts et la logique
  • une fois le fonctionnement stabilisé, les tâches ont été parallélisées sur plusieurs VM éphémères, chacune recherchant des bugs dans des fichiers cibles précis puis enregistrant les résultats dans des buckets
• Le seul sous-système de découverte ne suffisait pas
  • il fallait l’intégrer à l’ensemble du cycle de vie des bugs de sécurité, y compris quoi chercher, où regarder et comment traiter les résultats
  • cela incluait la déduplication par rapport aux problèmes existants, le suivi des bugs, le triage et la diffusion des correctifs
  • le modèle constitue la primitive centrale qui anime le harness, mais un pipeline complet est nécessaire pour le rendre utile à grande échelle
• Le harness peut être réutilisable d’un projet à l’autre, mais le pipeline varie selon le sens du codebase, les outils et les processus propres à chaque projet
• Un important travail itératif a été nécessaire, avec une boucle de retour étroite liée à la façon dont les ingénieurs Firefox traitent les bugs entrants

Claude Mythos Preview et l’effet du changement de modèle

• Une fois le pipeline de bout en bout en place, il devient simple de remplacer un modèle par un autre lors de l’arrivée d’un nouveau modèle
• Mozilla a trouvé plusieurs bugs graves avec des modèles publics, et ce pipeline lui a permis d’exploiter immédiatement l’occasion d’évaluer Claude Mythos Preview
• La montée en version du modèle a amélioré l’efficacité de l’ensemble du pipeline
  • meilleure détection des bugs potentiels
  • meilleure création de cas de test de preuve de concept démontrant les bugs
  • meilleure caractérisation des pathologies et de leur impact
• En plus des 271 bugs identifiés par Claude Mythos Preview et corrigés dans Firefox 150 release, des correctifs liés sont aussi inclus dans 149.0.2, 150.0.1 et 150.0.2
• En interne, l’équipe continue aussi de trouver des bugs par d’autres méthodes, et comme dans d’autres projets, les signalements externes ont fortement augmenté ces derniers mois
• Tous les bugs ont demandé une attention minutieuse pour être correctement corrigés, et de nombreux efforts ainsi que de longues heures de travail ont été nécessaires ces derniers mois pour suivre cette échelle inédite
• Plus de 100 personnes ont contribué au code afin de livrer la version la plus sûre possible de Firefox ; au-delà de l’écriture et de la revue des patchs, il a aussi fallu construire et étendre le pipeline, faire le triage, tester les correctifs et gérer le processus de release pour chaque bug

Leçons clés

• Toute personne qui développe du logiciel peut dès maintenant utiliser des modèles modernes et des harness pour trouver des bugs et durcir son code
• Il est possible de commencer avec un prompt simple, puis d’observer et d’itérer
  • le prompt initial n’était pas très différent de celui montré dans cette vidéo
  • avec les itérations, de nombreux outils d’orchestration ont été ajoutés pour optimiser et étendre le pipeline, mais la boucle interne restait essentiellement : « il y a un bug dans cette partie du code, trouve-le et génère un cas de test »
• Firefox n’a probablement pas encore épuisé tout son stock de bugs potentiels, mais Mozilla se dit satisfaite de la trajectoire actuelle
• Les scans actuels se concentrent surtout sur des zones de code spécifiques désignées, c’est-à-dire des fichiers et des fonctions, en combinant jugement humain et signaux automatiques
• À court terme, l’objectif est d’intégrer cette analyse au système d’intégration continue afin de scanner les patchs lorsqu’ils entrent dans le tree
• Les modèles s’adaptent souplement au format du contexte fourni, et Mozilla s’attend à ce qu’un scan basé sur les patchs fonctionne aussi bien, voire mieux, qu’un scan basé sur les fichiers
• Le moment est risqué, mais l’opportunité est grande, et il faut agir ensemble pour rendre Internet plus sûr

Questions fréquentes

• Pourquoi le nombre de « 271 bugs » diffère des chiffres des avis de sécurité

  • La page web des avis de sécurité regroupe plusieurs bugs signalés en interne sous des CVE « rollup »
  • La page est générée à partir du yaml du dépôt foundation-security-advisories, qui est l’emplacement officiel des attributions de CVE
  • Certains navigateurs ne créent pas d’identifiants CVE pour les problèmes découverts en interne, mais Mozilla les publie afin de fournir une information aussi transparente que possible
  • Firefox 150 contenait 3 rollups internes
    • CVE-2026-6784 : 154 bugs
    • CVE-2026-6785 : 55 bugs
    • CVE-2026-6786 : 107 bugs
  • Le total des trois rollups internes est de 316 bugs, soit plus que les 271 bugs annoncés comme trouvés avec Claude Mythos Preview
  • La raison est que l’équipe sécurité de Mozilla attaque Firefox chaque jour pour trouver de nouveaux bugs, en combinant systèmes de fuzzing, inspection manuelle et nouveau pipeline agentique utilisant plusieurs modèles
  • Dans la release d’avril, 423 bugs de sécurité ont été corrigés au total
    • les 271 bugs annoncés il y a deux semaines
    • 41 bugs signalés de l’extérieur
    • les 111 restants ont été découverts en interne et se répartissent globalement en trois catégories
      • des bugs trouvés avec ce pipeline utilisant Claude Mythos Preview mais corrigés dans d’autres releases que Firefox 150
      • des bugs trouvés avec ce pipeline utilisant d’autres modèles
      • des bugs trouvés par d’autres techniques comme le fuzzing
  • Anthropic reçoit aussi directement le crédit pour 3 CVE, distinctement de ce travail plus récent
    • CVE-2026-6746
    • CVE-2026-6757
    • CVE-2026-6758
  • Il s’agit de correctifs de bugs envoyés à Mozilla il y a plusieurs mois par l’Anthropic Frontier Red Team, et chacun a reçu son propre CVE selon la procédure habituelle

• Signification des niveaux de gravité sécurité

  • Mozilla applique des security severity ratings de critical à low pour indiquer l’urgence d’un bug
  • sec-critical et sec-high sont attribués aux vulnérabilités pouvant être déclenchées par un comportement utilisateur normal, comme la visite d’une page web
  • Il n’y a pas de différence technique entre sec-critical et sec-high, mais sec-critical est réservé aux problèmes publiquement divulgués ou connus comme exploités dans des attaques réelles
  • sec-moderate est attribué à des vulnérabilités qui seraient autrement classées sec-high mais exigent des étapes anormales et complexes de la part de la victime
  • sec-low est attribué à des bugs gênants mais éloignés d’un préjudice utilisateur, comme un crash sans impact de sécurité
  • La répartition des 271 bugs annoncés dans Firefox 150 est la suivante
    • 180 sec-high
    • 80 sec-moderate
    • 11 sec-low
  • Mozilla accorde la plus haute priorité aux bugs critical/high, mais il est aussi courant de prioriser des bugs de sécurité moderate et low pour corriger des problèmes de justesse et renforcer la défense en profondeur

• Différence entre sec-high ou sec-critical et un exploit réel

  • Un bug sec-high ou sec-critical ne signifie pas automatiquement un exploit pratique
  • Dans la plupart des cas, un seul bug critical/high ne suffit pas à compromettre Firefox
  • Firefox dispose d’une architecture de défense en profondeur ; par exemple, exploiter un bug JIT ne donne qu’une exécution de code à distance dans un processus sandboxé et isolé par site
  • En pratique, un attaquant doit généralement enchaîner plusieurs exploits pour franchir une ou plusieurs couches de sandboxing ainsi que des mitigations au niveau de l’OS, comme l’ASLR, afin d’élever ses privilèges
  • Mozilla ne développe généralement pas d’exploits pour vérifier si un bug pourrait réellement être utilisé par des attaquants
  • La classification sec-high repose sur des symptômes de crash prévisibles, comme des use-after-free ou des problèmes mémoire hors limites signalés par AddressSanitizer
  • Le modèle de menace part du principe qu’avec suffisamment d’efforts, ce type de bug peut être exploitable
  • Cette approche réduit le risque de faux négatifs dans l’analyse d’exploitabilité et permet de concentrer les ressources sur la découverte et la correction d’un plus grand nombre de vulnérabilités

[GN⁺]

Avis sur Lobste.rs

• J’aimerais qu’ils publient aussi les prompts et autres fonctionnalités utilisés pour ce travail
  Ce serait bien d’inclure les prompts dans les rapports de bugs ou les historiques de résolution pour que ce soit reproductible
  Comme ils ont aussi mentionné des modèles non-Mythos, une partie de ce travail pourrait sembler immédiatement utile à d’autres

  • Pour la plupart des projets, la barrière à l’entrée est vraiment faible
    En gros, il suffit de dire : « examine ce projet sous l’angle des problèmes de sécurité, en commençant par (fichier), et liste tous les chemins possibles », puis pour chaque élément d’enchaîner avec : « vérifie ce rapport et crée une preuve de concept »
    À ce stade, avec Opus, il est plus difficile de ne rien trouver que de trouver quelque chose de cette manière
  • Vous pensez vraiment que le prompt allait au-delà de « trouve des vulnérabilités de sécurité dans cette base de code » ?

• Quoi qu’on en dise, c’est vraiment impressionnant
  Ils ont trouvé 271 problèmes de sécurité avec Mythos, et 423 au total
  Parmi eux, 180 étaient de gravité élevée, et certains problèmes de sécurité dataient de 20 ans

  • On ne sait pas tout à fait à quel point la comparaison entre Opus 4.6 et Mythos était équitable
    Le texte laisse entendre, sans le dire exactement ainsi, que Mythos a trouvé « 271 bugs » dans du code déjà scanné auparavant avec la 4.6
    Je me demande aussi si le harnais de recherche a changé en même temps

• Le passage disant que « l’un des nombreux problèmes sec-high que nous avons corrigés concernait XSLT » semble avoir été inclus à cause de la controverse sur la suppression de XSLT

• Ce qui m’intrigue le plus ici, c’est aussi le nombre de faux positifs signalés
  Le modèle a peut-être signalé environ deux fois plus de vulnérabilités potentielles, et je me demande si ce qui est présenté ici correspond uniquement à celles qui ont été confirmées
  Je ne sais pas non plus s’il va jusqu’à reproduire le problème avant de le signaler
  Dans les tickets publics, on voit des commentaires qui semblent tenter une reproduction, mais il pourrait aussi s’agir d’un bot déjà existant
  Je ne connais pas très bien la façon dont Firefox traitait ce type de travail à l’origine, ni comment cela se passe maintenant avec l’IA, donc une explication plus détaillée serait vraiment très intéressante