Claude Opus 4.6 a passé Firefox au crible — 22 failles découvertes en 14 jours

22 vulnérabilités dans Firefox en deux semaines. Pas un concours de bug bounty, pas une équipe de pentesters survoltés, juste un modèle IA, Claude Opus 4.6, branché sur une collaboration avec Mozilla. Le chiffre claque parce qu’en 2025, aucune équipe humaine n’a fait mieux sur un mois entier, d’après les chercheurs côté navigateur.

Le détail qui pique, c’est la gravité. Sur ces 22 failles, 14 ont été classées high-severity. Presque un cinquième de toutes les failles critiques corrigées dans Firefox sur l’année 2025, qui en comptait 73. Et la plupart des correctifs ont atterri dans Firefox 148, sorti fin février. Du coup, oui, c’est une bonne nouvelle pour les utilisateurs. Mais pour l’écosystème sécurité, ça ressemble aussi à un changement de cadence.

Deux semaines, 22 failles, et 14 critiques

Ce que racontent Anthropic et Mozilla, c’est une perf de productivité brute. Claude Opus 4.6 a identifié 22 vulnérabilités sur une fenêtre de 14 jours, pendant une période de recherche en janvier 2026. La répartition est nette, 14 classées critiques, 7 modérées, 1 faible. Et la plupart ont été corrigées dans Firefox 148, même si quelques correctifs doivent encore arriver sur une version suivante.

Le repère qui parle au grand public, c’est la comparaison 2025. Les chercheurs indiquent que ce volume de vulnérabilités dépasse ce qui a été rapporté sur n’importe quel mois de 2025. Et côté criticité, ces 14 failles pèsent lourd, presque un cinquième des 73 high-severity corrigées sur l’année. Quand tu connais le niveau de revue et de test autour de Firefox, ça donne une idée du saut.

Dans la pratique, ça ne veut pas dire « l’IA a tout fait toute seule ». On te parle d’une collaboration, avec des humains qui trient, reproduisent, qualifient. Mais le rythme change, et pas qu’un peu. Un chercheur sécurité que je connais, côté navigateur, résume ça cash, « si tu peux multiplier par dix la vitesse de détection, tu changes l’économie de la défense ». Et tu changes aussi l’économie de l’attaque, on va y revenir.

Le truc, c’est que le chiffre « 22 » peut tromper si tu le lis comme un tableau de chasse. Une vulnérabilité, c’est une chaîne, découverte, reproduction, analyse, correctif, tests, déploiement. Là, l’info importante, c’est la capacité à sortir des pistes sérieuses, à un rythme qui met la pression sur les équipes de triage. Si tu as déjà vécu un Bugzilla qui déborde, tu vois très bien le film.

Pourquoi le moteur JavaScript de Firefox a été visé

Anthropic explique être parti d’abord sur le moteur JavaScript, puis avoir élargi à d’autres zones du code. Logique, le JavaScript, c’est l’endroit où le navigateur avale du code non fiable en continu. Tu visites une page, tu exécutes du script, et si une faille de mémoire traîne, tu as une surface d’attaque royale. C’est aussi pour ça que les équipes sécurité y passent un temps fou depuis des années.

Mozilla et Anthropic décrivent Firefox comme un projet open source très testé et très audité. C’est presque un compliment à double tranchant, si une IA arrive à y trouver autant de failles, ça veut dire qu’elle est devenue un outil sérieux, pas un gadget. Et ça veut dire aussi que les zones « déjà bien ratissées » restent perfectibles. Les navigateurs, c’est des millions de lignes, du C++ historique, des optimisations, des couches de sandbox, bref, un terrain idéal pour des bugs subtils.

L’exemple mis en avant est parlant, une vulnérabilité use-after-free repérée après « seulement » 20 minutes d’exploration. Le use-after-free, c’est typiquement le genre de bug mémoire qui peut mener à de la corruption, voire à de l’exécution de code si tu arrives à enchaîner. Là, l’équipe humaine a validé le problème dans un environnement virtualisé, pour éviter le faux positif ou l’illusion statistique.

Et c’est là que tu vois l’intérêt d’un modèle « frontier » côté sécurité, pas juste pour lire du code, mais pour proposer des chemins d’investigation. Le modèle peut pointer une zone, une séquence, un pattern dangereux. L’humain derrière, lui, fait le boulot de rigueur, reproduction, minimisation, preuve, assignation de sévérité. Ce duo, sur un gros projet comme Firefox, c’est un accélérateur, mais ça reste un duo.

Les correctifs dans Firefox 148 et le triage côté Mozilla

La majorité des failles ont été corrigées dans Firefox 148, publié fin février. Pour les utilisateurs, c’est la partie la plus concrète, tu mets à jour, tu récupères des patches, et tu réduis ton exposition. Pour Mozilla, c’est un exercice de gestion de flux, parce qu’un modèle qui crache des rapports à grande vitesse, ça peut vite devenir ingérable si le triage ne suit pas.

On parle d’un navigateur utilisé par des centaines de millions de personnes. Chaque correction doit passer par des tests, éviter les régressions, et rester compatible avec un écosystème web qui casse pour un rien. Dans ce contexte, 14 high-severity en provenance d’un même « canal » de recherche, c’est un gros morceau. Et le fait que quelques fixes attendent la release suivante montre que tout ne se règle pas en claquant des doigts, même quand la détection va vite.

Dans les détails publiés, Anthropic mentionne aussi un volume plus large de bugs, 100 au total, au-delà des 22 vulnérabilités retenues. Et ils parlent de la soumission de rapports de crash à l’outil de suivi, ce qui illustre le côté « bruit et signal ». La sécurité, c’est aussi ça, transformer un crash en vulnérabilité exploitable ou en simple plantage sans impact, et ça demande des heures de travail humain.

Perso, c’est là que je mets une nuance. Accélérer la découverte, c’est bien. Mais si tu ne renforces pas le pipeline derrière, tu crées un goulot d’étranglement. Un responsable sécu que j’ai déjà vu gérer des vagues de rapports me disait, « le vrai coût, c’est pas de recevoir le bug, c’est de le qualifier et de le corriger proprement ». L’IA peut déplacer la charge, pas la supprimer.

Quand Claude tente l’exploitation, ça coince encore

L’autre info qui mérite d’être répétée, c’est que Claude Opus 4.6 est bien meilleur pour trouver des failles que pour écrire un exploit fiable. Anthropic explique avoir dépensé environ 4 000 dollars en crédits API à travers des centaines d’essais pour produire des preuves de concept. Résultat, seulement deux cas où le modèle a généré des exploits fonctionnels. On est loin du fantasme « tu tapes un prompt et tu pwnes tout ».

Et même dans ces deux cas, le cadre est très limité. Les exploits ne marchaient que dans un environnement de test contraint où des protections clés, dont la sandbox de Firefox, étaient volontairement désactivées. Ça change tout. Dans la vraie vie, un attaquant doit composer avec la sandbox, l’ASLR, les mitigations, les différences de versions, les chaînes d’exploit multi-étapes. Là, on parle plutôt d’une démonstration de capacité, pas d’un kit prêt à l’emploi.

Mais il ne faut pas se raconter d’histoires non plus. Si un modèle peut trouver des use-after-free en 20 minutes, la marche suivante, c’est l’amélioration de l’exploitation. Anthropic le dit de façon assez directe, les procédures de Coordinated Vulnerability Disclosure devront peut-être évoluer « à mesure que les modèles progressent ». Traduction, aujourd’hui ça coince, demain ce sera plus fluide, et les délais de divulgation devront peut-être se resserrer.

Le point qui m’intéresse, c’est la dissymétrie. Les défenseurs peuvent utiliser l’IA pour détecter plus vite, mais les attaquants aussi. Et eux n’ont pas à écrire des patchs propres, ni à éviter les régressions. Ils ont juste besoin d’un exploit qui marche « assez » sur un sous-ensemble de machines. Du coup, même si l’exploitation n’est réussie que deux fois sur des centaines de runs, ça ne veut pas dire que le risque est faible, ça veut dire que le risque est en train de se structurer.

Ce que ça change pour l’open source et la divulgation coordonnée

Anthropic insiste sur l’idée que les modèles « frontier » deviennent des chercheurs en vulnérabilités de niveau mondial. Ils expliquent aussi avoir utilisé Claude Opus 4.6 sur d’autres projets importants, dont le kernel Linux. Et ils racontent un point méthodo intéressant, avant d’attaquer le code actuel, ils ont testé la capacité du modèle à reproduire des CVE historiques sur d’anciennes versions, tout en reconnaissant un biais possible, ces CVE ont pu se retrouver dans les données d’entraînement.

Pour l’open source, ça peut être un gros coup de pouce, parce que beaucoup de projets n’ont pas les moyens d’une équipe sécurité dédiée. Un modèle peut aider à pointer des zones risquées, à générer des hypothèses, à accélérer la revue. Mais il y a l’autre face, la quantité. Si tu « démocratises » la recherche de failles, tu vas aussi démocratiser les tickets inutiles, les faux positifs, les rapports mal qualifiés. TechCrunch évoque d’ailleurs le risque de voir arriver une pluie de contributions médiocres en parallèle des bonnes trouvailles.

La divulgation coordonnée, c’est le garde-fou. Anthropic dit avoir publié des principes de Coordinated Vulnerability Disclosure et suivre les normes du secteur « pour le moment ». Ce « pour le moment » est important. Si les modèles accélèrent, la fenêtre entre découverte et exploitation potentielle peut se réduire. Et ça pousse les mainteneurs à patcher plus vite, à communiquer mieux, et à industrialiser la réponse, ce qui coûte du temps et de l’argent.

Pour toi, utilisateur, la morale est basique, mets à jour ton navigateur. Pour Mozilla, c’est une course d’organisation. Et pour le secteur, c’est un signal, la détection automatisée de vulnérabilités sérieuses devient un outil standard. Tu peux t’en réjouir côté défense, mais tu dois aussi accepter que la barre monte. Les équipes qui n’auront pas ce type d’outils, ou qui n’auront pas le pipeline pour absorber les rapports, vont se faire distancer.