Claude d’Anthropic a trouvé 112 bugs dans Firefox en analysant 6 000 fichiers C++

112 rapports envoyés à Mozilla en deux semaines. Derrière, 22 failles de sécurité avec CVE, dont 14 classées sévères. Et au passage, une grosse poignée de bugs non sécurité que personne n’avait vraiment vus venir. Tout ça sur Firefox, un des logiciels open source les plus testés de la planète.

Le truc qui pique un peu l’ego des vieux outils, c’est que Claude, l’IA d’Anthropic, n’a pas juste fait du bruit. Il a trouvé des erreurs de logique profonde, là où les fuzzers traditionnels tournent parfois en rond. Mozilla a corrigé l’essentiel dans Firefox 148.0, sorti le 24 février. Du coup, ça pose une question simple: qu’est-ce que l’IA change vraiment dans la chasse aux vulnérabilités?

22 CVE dans Firefox 148: le tableau de chasse

Sur la collaboration, les chiffres sont nets. Anthropic a soumis 112 rapports uniques à Mozilla après avoir scanné près de 6 000 fichiers C++ de Firefox. Mozilla a fait le tri, a confirmé la matière exploitable, puis a attribué 22 CVE à des bugs jugés security-sensitive. Sur ces 22, 14 ont été classés haute sévérité. Ce n’est pas un détail: c’est le genre de ratio qui déclenche des réunions en urgence.

Mozilla dit avoir intégré les correctifs dans Firefox 148.0. Dans la pratique, ça veut dire que le travail n’est pas resté dans un PDF ou un ticket oublié. Les équipes ont validé, patché, livré. D’après ce qui a filtré, la cadence a ressemblé à une réponse à incident: afflux massif de tickets, mobilisation de plusieurs équipes d’ingénierie, triage accéléré, et corrections poussées dans une release stable. Pas glamour, mais efficace.

Ce qui impressionne, c’est la vitesse d’amorçage. Anthropic explique que Claude a repéré un premier bug sérieux en une vingtaine de minutes d’exploration, un Use After Free dans le moteur JavaScript. Le genre de vulnérabilité mémoire qui peut ouvrir la porte à l’exécution de code si tu arrives à la chaîner correctement. Les chercheurs l’ont validée sur une machine virtuelle, puis l’ont fait revérifier par d’autres personnes avant de déposer un rapport complet.

Et il n’y a pas que les CVE. Dans les 112 rapports, il y a aussi environ 90 bugs supplémentaires, plutôt des crashs, des erreurs de logique, des soucis de robustesse. Mozilla en a corrigé la majorité. Pour un navigateur, ces petits bugs comptent: un crash reproductible devient parfois un point d’entrée, ou au minimum un signal que ton code a des coins sombres. Les fuzzers attrapent déjà des crashs, oui, mais là le volume et la variété ont clairement bousculé la routine.

Pourquoi les fuzzers ratent des erreurs de logique

Le fuzzing classique, c’est une méthode qui a fait ses preuves depuis vingt ans: tu balances des entrées aléatoires ou semi-guidées, tu observes les crashs, tu minimises le cas, tu corriges. Sur des composants C/C++, c’est redoutable pour les erreurs mémoire et les dépassements de tampon. Le problème, c’est que beaucoup de bugs modernes ne crient pas crash tout de suite. Ils se cachent dans des enchaînements d’états, des invariants implicites, des hypothèses de développeurs jamais écrites nulle part.

Une erreur de logique profonde, c’est typiquement un code qui marche dans 99,9% des cas, mais qui se trompe quand deux conditions rares se rencontrent. Exemple de mécanique, sans inventer de bug précis: une fonction qui valide une taille à un endroit, puis réutilise cette taille ailleurs après une conversion de type, ou après une mutation d’état. Le fuzzer peut générer des entrées bizarres, mais il ne comprend pas forcément quel chemin est intéressant s’il n’y a pas de crash immédiat comme récompense.

Claude, lui, n’est pas juste un générateur d’inputs. Dans cette collaboration, l’approche a consisté à analyser du code, raisonner sur les chemins, puis produire des cas de test reproductibles et des explications. Anthropic insiste sur un point très concret: fournir des rapports exploitables, avec un minimum reproductible, une preuve de concept quand possible, et même une proposition de patch. Ça change la vie côté Mozilla, parce que le temps perdu sur les faux positifs est un vrai poison en sécurité.

Un ingénieur sécu que j’appelle Marc (oui, encore un Marc) résume ça de façon brutale: Un fuzzer te dit ‘ça casse’. Claude te dit ‘ça casse parce que tu as supposé X, sauf que Y’. Ça ne rend pas le fuzzing obsolète, mais ça comble un trou. Les fuzzers excellent quand la surface d’attaque se mesure en octets d’entrée. Ils souffrent quand le bug est une histoire de logique, de séquences, de contrats implicites entre modules.

Dans le moteur JavaScript, 20 minutes pour un Use After Free

Anthropic a commencé par le moteur JavaScript de Firefox. Choix logique: c’est une zone à très forte exposition, parce qu’elle traite du code non fiable en permanence, page après page. C’est aussi relativement isolable par rapport au reste du navigateur, donc plus simple à analyser en tranche. Et c’est un terrain où les bugs mémoire, les erreurs de gestion d’objets, et les confusions de type peuvent coûter très cher quand un attaquant sait les enchaîner.

Le point marquant, c’est la chronologie. Après environ vingt minutes, Claude Opus 4.6 signale un Use After Free. Les chercheurs d’Anthropic valident le problème sur une VM avec une version récente de Firefox, puis font revérifier par d’autres personnes en interne. Ensuite, ils déposent un ticket dans Bugzilla avec description, cas reproductible, et une proposition de patch générée par Claude et validée par l’équipe. Ce n’est pas juste j’ai peut-être trouvé un truc, c’est voilà comment le reproduire, voilà où regarder.

Mozilla, de son côté, n’a pas demandé un rapport parfait sur chaque crash. Après discussion technique, un chercheur Mozilla a encouragé Anthropic à soumettre les résultats en bloc, même si tous les cas de crash n’étaient pas validés comme ayant une implication sécurité. Ça dit deux choses. Un: ils voulaient capter l’élan. Deux: ils avaient confiance dans la qualité globale du pipeline de remontée, au moins assez pour investir du temps de triage sans se faire noyer.

Ce passage est important parce qu’il montre la limite habituelle des programmes de bug bounty et du fuzzing interne: tu peux avoir des tonnes de signaux, mais si tu n’as pas des cas minimaux et une explication claire, tu perds des jours. Là, l’IA a servi d’accélérateur de compréhension et de rédaction technique. Le résultat, c’est un Time-to-Fix réduit, et une release 148.0 qui embarque des corrections avant que ça ne s’ébruite trop.

112 rapports en deux semaines: Mozilla en mode “incident”

Quand 112 rapports arrivent d’un coup, même pour un projet mature, ça secoue. Mozilla décrit une mobilisation proche d’une réponse à incident pour trier, confirmer, assigner, corriger. C’est le côté moins sexy de l’histoire: l’IA peut multiplier la production de tickets, mais derrière il faut des humains pour décider ce qui est réel, ce qui est critique, ce qui est duplicat, et ce qui peut attendre. Sans cette capacité, tu finis par ignorer des alertes, et là c’est le drame.

Le triage a aussi une dimension politique interne. Quand 14 CVE haute sévérité sortent d’un lot, tu ne peux pas les traiter comme des bugs normaux. Ça implique des validations croisées, des tests de non-régression, parfois des discussions sur le backport, et une coordination de divulgation. D’après les infos publiques, Mozilla a corrigé les 22 CVE dans la version 148.0. Pour les autres bugs, la plupart ont été corrigés aussi, et le reste doit suivre dans des versions à venir.

Ce qui différencie cette vague de tickets d’un fuzzing classique, c’est la plausibilité. Les fuzzers génèrent des crashs, oui, mais ils génèrent aussi des montagnes de choses inintéressantes, et des cas difficiles à réduire. Là, Anthropic met en avant des cas reproductibles et des explications, ce qui réduit le coût de validation. Et quand tu réduis le coût de validation, tu peux te permettre d’en traiter plus. C’est bête, mais c’est la variable qui décide si un projet corrige 20% ou 80% des alertes qu’il reçoit.

Il y a quand même un revers. Si demain plusieurs acteurs sortent des outils du même genre et bombardent les mainteneurs open source, tu risques l’embouteillage. Même avec de bons rapports, 500 tickets plausibles peuvent faire craquer une équipe. Et ça, Anthropic le dit à demi-mot: le futur, c’est une hausse du volume et de la crédibilité des signalements. Donc soit tu renforces les process, soit tu te fais submerger. On parle de Firefox, mais pense aux petits projets critiques maintenus par deux bénévoles.

Le revers de la médaille: exploits rares, coût API, faux sentiment de sécurité

Anthropic a aussi testé un truc qui fascine tout le monde: transformer des vulnérabilités en exploit pratique. Résultat: sur plusieurs centaines de tentatives et environ 4 000 dollars de crédits API, Claude n’a réussi à produire un exploit fonctionnel que dans deux cas. Ça calme. Ça veut dire que trouver un bug et l’exploiter de façon fiable restent deux sports différents, surtout sur un navigateur moderne blindé de mitigations.

Autre nuance importante: les patches générés par agent. Anthropic est clair: même si un patch passe des vérifications de tâche, ça ne garantit pas qu’il est bon pour un merge immédiat. En gros, tu peux corriger le symptôme et casser un invariant ailleurs, ou introduire une régression subtile. Les task verifiers augmentent la confiance minimale, mais ça ne remplace pas la revue de code et la compréhension du module. Si tu laisses une IA patcher en automatique, tu invites des bugs fantômes.

Et puis il y a le risque de faux sentiment de sécurité côté grand public. 22 failles corrigées peut se lire comme tout va bien, circulez. Sauf que la vraie leçon, c’est plutôt: même un projet ultra-audité a encore des classes d’erreurs que les outils dominants ne voient pas bien. Ça ne veut pas dire que Firefox était un gruyère, ça veut dire que la complexité logicielle dépasse la capacité des méthodes uniques. La défense, c’est la redondance: fuzzing, revue, analyse statique, et maintenant IA.

Marc, encore lui, m’a lâché une phrase que je trouve juste: L’IA baisse le prix du signal, mais elle baisse aussi le prix du bruit. Si tu n’as pas des règles de divulgation coordonnées et une discipline de triage, tu peux te faire manipuler, ou juste épuiser. Anthropic a publié des principes de divulgation coordonnée et recommande des rapports propres, avec cas minimaux et détails. Tant mieux. Le jour où des acteurs moins soigneux s’y mettent, Mozilla et les autres vont devoir blinder leurs pipelines.