- Claude Opus 4.6 a découvert 22 vulnérabilités dans Firefox dans le cadre d’une collaboration avec Mozilla, dont 14 classées à haut risque
- Cela démontre qu’un modèle d’IA peut détecter rapidement des vulnérabilités zero-day dans des logiciels complexes, avec des correctifs intégrés à Firefox 148.0
- Claude a analysé des zones de code incluant le moteur JavaScript sur des milliers de fichiers et soumis 112 rapports ; Mozilla a effectué les corrections sur cette base
- Il a été confirmé que l’IA est très performante pour détecter des vulnérabilités, mais que sa capacité à rédiger de véritables exploits (code d’attaque) reste limitée
- Anthropic présente un modèle de collaboration pour la recherche en sécurité fondée sur l’IA et appelle à un renforcement de la sécurité centré sur les défenseurs via une coopération avec l’écosystème open source
Aperçu de la collaboration avec Mozilla
- Claude Opus 4.6 a découvert 22 vulnérabilités dans Firefox en deux semaines d’analyse, dont 14 classées à haut risque par Mozilla
- Cela représente environ 20 % des vulnérabilités à haut risque corrigées dans Firefox en 2025
- Les correctifs ont été intégrés à Firefox 148.0 et déployés auprès de centaines de millions d’utilisateurs
- Mozilla a validé les signalements d’Anthropic en partageant ses critères et processus de bug report, mettant en place un système de vérification collaboratif
- Cette collaboration est présentée comme un exemple de modèle de coopération entre chercheurs en sécurité fondée sur l’IA et mainteneurs
Processus de détection des vulnérabilités avec un modèle d’IA
- Pour aller au-delà du benchmark CyberGym et mener un test plus réaliste, Anthropic a constitué un jeu de données CVE de Firefox
- Firefox est un projet open source complexe et fortement sécurisé, ce qui en fait un bon terrain pour vérifier les capacités de détection d’une IA
- Après avoir reproduit d’anciens CVE, Claude s’est attaqué à la détection de nouvelles vulnérabilités dans la version la plus récente
- Il a trouvé en seulement 20 minutes une vulnérabilité mémoire de type Use After Free, puis l’a signalée à Mozilla après validation indépendante
- Claude a ensuite analysé plus de 6 000 fichiers C++ et soumis 112 rapports uniques
- La plupart des problèmes ont été corrigés dans Firefox 148, et certains seront résolus dans de futures versions
Expériences sur l’exploitation des vulnérabilités
- Afin d’évaluer la limite supérieure des capacités de sécurité de Claude, une expérience a été menée pour déterminer s’il pouvait transformer les vulnérabilités découvertes en véritable code d’attaque
- Des centaines de tests ont été réalisés, pour un coût d’API d’environ 4 000 dollars
- Au final, seuls 2 exploits ont effectivement réussi, montrant que ses capacités de génération d’attaque restent faibles par rapport à ses capacités de détection
- Les exploits réussis ne fonctionnaient que dans l’environnement de test, où les mécanismes de sécurité sandbox du navigateur avaient été supprimés
- Le système de défense multicouche de Firefox peut atténuer ce type d’attaque
- Anthropic avertit, à travers cette expérience, du potentiel de génération automatisée d’outils offensifs par l’IA
Bonnes pratiques pour la recherche en sécurité fondée sur l’IA
- Via ses recherches sur un patching agent, Anthropic développe des méthodes permettant aux LLM d’effectuer la correction et la vérification de bugs
- Un outil auxiliaire appelé Task verifier est utilisé pour valider en temps réel les résultats de l’IA
- Des tests automatisés vérifient à la fois la suppression de la vulnérabilité et le maintien du bon fonctionnement du programme
- Les rapports jugés fiables par Mozilla comportaient trois éléments clés
- un cas de test minimal de reproduction
- un Proof-of-Concept détaillé
- un patch candidat
- Anthropic recommande aux chercheurs qui soumettent des rapports de vulnérabilité fondés sur des LLM d’y joindre des preuves de vérifiabilité et de reproductibilité
Perspectives et nécessité de renforcer la sécurité
- Claude Opus 4.6 a également découvert des vulnérabilités dans d’autres grands projets, dont le noyau Linux
- À ce stade, l’IA est meilleure pour détecter et corriger que pour générer des exploits, ce qui avantage les défenseurs
- Mais au vu de la rapidité des progrès des modèles, il est possible que l’écart avec les capacités offensives se réduise rapidement
- Anthropic propose déjà aux chercheurs et mainteneurs des fonctions de détection et de patching via Claude Code Security
- L’entreprise appelle les développeurs à profiter de cette fenêtre d’opportunité pour renforcer la sécurité, avec notamment
- la coopération dans la recherche de vulnérabilités
- le développement d’outils de tri des bug reports
- l’extension des fonctions de proposition automatique de correctifs
2 commentaires
Mozilla Foundation Security Advisory 2026-13
C’est vraiment énorme.
C’est le genre de cas qui rappelle une fois de plus à quel point des cas de test rigoureux sont importants.
Réactions sur Hacker News
Si vous êtes responsable du maintien de la sécurité d’un projet open source, cela vaut la peine de demander à Claude Code un audit de sécurité
Pour un projet de grande ampleur comme Firefox, cela peut être difficile, mais pour la plupart des projets, le coût en tokens tourne autour de 3 dollars
Il est fort probable que des attaquants effectuent déjà ce type d’audit, donc ne pas le faire soi-même n’est plus vraiment une attitude responsable
Lors de l’audit du code source principal de Zulip, on a demandé au modèle de s’auto-vérifier pour chaque résultat, ce qui a éliminé la plupart des faux positifs
Ensuite, les problèmes restants ont presque disparu lors du nouvel audit après l’ajout de commentaires dans le code pour clarifier l’intention du modèle de sécurité
Demander « fais en quelques secondes ce qui prendrait une semaine » n’est tout simplement pas réaliste
Le résultat peut sembler crédible sans correspondre à la réalité
Si on traite l’IA comme un stagiaire, on évite d’être déçu — confieriez-vous un audit de sécurité d’un programme géant entier à un stagiaire ?
Dans certains cas, ça marche très bien, dans d’autres c’est totalement inutile
La différence semble au fond dépendre de la qualité du context engineering et du test harness
Ce cas-ci était intéressant aussi, mais j’aurais aimé des explications plus concrètes
J’ai moi aussi récemment publié un projet en open source, et un utilisateur de Reddit a lancé un audit de sécurité complet avec Claude et m’a trouvé 15 vulnérabilités
Injection FTS, injection de joker
LIKE, absence d’authentification d’API, manque de protection de la vie privée, etc. : j’avais raté pas mal de chosesCe qui m’a surpris, c’est à quel point le résultat était structuré — classification par gravité, chemins de fichiers et numéros de ligne, jusqu’aux écarts entre la documentation et le code réel
L’analyse de l’« écart entre la spec et la réalité » a été particulièrement utile
La vraie valeur des audits de sécurité par LLM n’est pas de trouver de nouveaux zero-days, mais de prendre en charge les vérifications répétitives et minutieuses que les humains finissent par ignorer par lassitude
Peu de gens comprennent la complexité des vulnérabilités dans un navigateur comme Firefox
Rien que transformer un simple UAF en shellcode wasm peut prendre plusieurs jours
La compétition sur les capacités cyber de l’IA est encore relativement calme, mais cela pourrait changer d’ici la fin de l’année
Moi aussi, comme Anthropic, j’ai donné à Claude une VM et un validateur pour lui demander de générer un exploit, et cela a plutôt bien fonctionné dans l’environnement kctf-eval
En revanche, on ne sait toujours pas clairement ce que le modèle « comprend » réellement, ou s’il ne fait qu’imiter en s’ajustant au signal de récompense
Il est intéressant de voir que Mozilla a mis à jour son avis de sécurité
Je me demandais qui avait trouvé 22 vulnérabilités dans une seule release, et on le sait enfin
Si cela se limite à faire tomber un fichier, la menace n’est pas énorme, mais quelque chose comme le vol de données de session est bien plus intéressant
Je trouve étrange que le contenu précis des bugs ne soit pas mentionné
J’aimerais savoir s’il s’agit juste de cas limites ou de problèmes réellement significatifs
Les LLM repèrent bien les schémas d’échec familiers, mais cela n’a pas toujours de réelle importance
Je ne suis pas expert en sécurité, mais cela ne semble pas être quelque chose qu’on puisse balayer d’un revers de main sous prétexte que « ce n’est qu’un LLM »
Mon expérience avec les agents IA a été mitigée
Ils se sont montrés utiles pour étendre la couverture de tests, configurer du fuzz testing ou mettre en place des outils d’analyse statique
Mais il leur est aussi arrivé d’affirmer qu’un système était « très sûr » alors qu’aucune frontière de sécurité réelle n’existait
Ils détectent bien les bugs locaux, mais ratent presque toujours les vulnérabilités complexes issues de l’interaction entre plusieurs fonctionnalités
Au final, les affirmations de sûreté du modèle doivent toujours être vérifiées
La valeur de cette approche vient du fait qu’elle fournit des cas de test vérifiables
C’est bien plus efficace qu’un simple rapport d’analyse
Avant, il était vrai de dire qu’ils ne trouvaient bien que des « bugs locaux », mais les SDK agentiques ont changé la donne
Quand la couverture est déjà élevée, ce qui reste est par nature la partie difficile
Dans certains cas, ils arrivent même à détecter des vulnérabilités de logique métier
Les bugs locaux sautent aux yeux, alors que des frontières de sécurité incomplètes peuvent paraître suffisantes au premier abord
On comprend facilement pourquoi Anthropic a choisi Firefox
C’est un projet open source largement déployé, tout en étant activement audité sur le plan de la sécurité
Chromium utilise Gemini de Google, et Safari a une culture de développement trop fermée pour faciliter ce type de collaboration
D’après l’article d’Anthropic, l’exploit écrit par Claude ne fonctionnait que dans un environnement de test
C’était parce que les fonctions de sandbox du navigateur réel avaient été retirées
La défense en profondeur de Firefox aurait donc probablement atténué ce type d’attaque
Chrome applique une politique similaire
La documentation correspondante est disponible dans Security Severity Ratings
Une évasion de sandbox reste possible, donc tous les bugs doivent être corrigés
Les attaquants peuvent accumuler ces zero-days partiels puis les combiner
Cette correction constitue clairement un progrès en matière de sécurité en réduisant ce risque
Moi aussi, je fais tourner des agents IA toute la nuit pour leur faire écrire des tests, et j’ai déjà demandé à Claude d’essayer de la vérification formelle
Anthropic semble avoir adopté une approche similaire
J’ai l’intention d’ajouter ensuite des prompts pour automatiser les property tests et le fuzz testing
J’ai l’impression que les problèmes que je traite ne nécessitent pas quelque chose d’aussi lourd, mais je me trompe peut-être
Je pense qu’un jour il existera un système d’audit de sécurité automatisé pour les projets open source critiques, à l’image de OSS-Fuzz de Google
Anthropic offre déjà un accès gratuit à Claude aux mainteneurs OSS
Les LLM ont aussi provoqué un déluge de faux signalements dans les programmes de bug bounty, mais les modèles récents atteignent désormais un niveau où ils savent distinguer de vraies vulnérabilités
Si on évalue cela avec des modèles gratuits ou bas de gamme, la qualité semblera forcément médiocre
En revanche, un programme d’audit de sécurité fondé sur des LLM haut de gamme permettrait d’assurer un certain niveau de qualité
Pour sauver les bug bounties, on pourrait aussi imaginer des frais d’inscription ou une validation fondée sur les LLM
Lien connexe
Par exemple, en lançant une VM pour que l’agent exécute un test de reproduction