BigSleep, agent LLM, trouve 45 vulnérabilités dans V8, Fuzzilli 37 : 25% de recoupement

En six mois, d'avril à septembre 2026, l'agent LLM BigSleep a trouvé 45 vulnérabilités exploitables dans V8, contre 37 pour le fuzzer génératif Fuzzilli. Google utilise ces deux outils en production pour vérifier le code récent du moteur JavaScript de Chrome. L'équipe Project Zero a comparé leurs résultats et en tire deux constats. Le recoupement entre les trouvailles est faible : environ 25% d'après le bug tracker (20 rapports exploitables sur 81). Dans une expérience reconstituée sur des bugs historiques, il atteint environ 60%. Une part importante des vulnérabilités n'est donc détectée que par l'une des deux approches.

Comment 441 rapports se réduisent à 45 vulnérabilités

Le décompte brut des hotlists du bug tracker de Chromium donne un léger avantage à BigSleep : 441 rapports contre 316 pour Fuzzilli. Mais à ses débuts, BigSleep a surtout remonté des problèmes de configuration et d'intégration, comme un blocage des flags dangereux qui ne fonctionnait pas (crbug.com/503869331). Ces bugs n'ont presque aucun impact réel sur la sécurité.

Si l'on ne garde que type:vulnerability, le tableau s'inverse : 178 pour Fuzzilli et 95 pour BigSleep. Ce chiffre reste toutefois gonflé. Une partie des rapports sont des doublons ou ont été fermés comme WAI (« works as intended », fonctionne comme prévu). Un simple filtre sur le statut fixed ne suffit pas non plus. Par exemple, le bug Fuzzilli crbug.com/511935486 a été ouvert et fermé le même jour par Clusterfuzz, parce que le cas de test ne se reproduisait plus. Il s'agit presque certainement d'un doublon de crbug.com/511210507, mais la signature du crash dans la stack trace différait légèrement et le système ne les a pas fusionnés. Aucun ingénieur n'a touché à ce bug.

Les auteurs n'ont donc compté que les rapports « exploitables » : ni doublons, ni WAI, avec au moins un commit de correction. Pour le type Type-Vuln, on obtient 45 contre 37 en faveur de BigSleep.

Recoupement : un quart dans le tracker, environ 60% dans l'expérience

Pour compter les trouvailles communes, les bugs ont été dédupliqués en quatre étapes :

• les doublons explicites, lorsque le rapport d'un système est marqué comme doublon du rapport de l'autre, comme crbug.com/522410841 et crbug.com/522860268 ; • les doublons implicites : pour les rapports « non exploitables », on cherche le commit correctif et l'on fusionne les bugs qui y sont rattachés. Le lien peut être multiple : un bug BigSleep et un bug Fuzzilli peuvent tous deux dupliquer un troisième ; • les doublons issus de la base Clusterfuzz qui ne sont jamais arrivés dans le tracker ; • les bugs différents fermés par un même CL (par exemple, quatre bugs dans crrev.com/c/7965120) sont eux aussi considérés comme des doublons.

Résultat : 20 bugs communs sur 81, dont un peu plus de la moitié ont d'abord été trouvés par Fuzzilli.

Ce décompte sous-estime le recoupement, d'où l'expérience. Les auteurs ont pris environ 1150 bugs historiques de Fuzzilli, de 2023 à mi-2026. Ils ont conservé environ 600 vulnérabilités, puis 132 bugs reproductibles dans la build publique debug+asan de d8 sur x64, sans flags spéciaux. Après déduplication, il en restait 112. Pour chacun, ils ont identifié le commit introducteur probable, principalement par bisection, puis lancé l'agent 25 fois avec pour tâche de trouver les bugs liés à ce commit et de les confirmer par un cas de test faisant planter la build. Cela représente 2800 exécutions sur la configuration de BigSleep en production à l'époque, avec le modèle Gemini 3.6 flash.

Résultat : environ 62% des bugs d'origine ont été retrouvés, environ 12% des commits ont mené à un autre bug, déjà corrigé, et pour 26% rien n'a été trouvé. Le protocole désavantage d'emblée l'agent : le commit a pu être mal identifié, et en conditions réelles un bug peut aussi être détecté à partir d'un commit plus tardif dans le même code.

Mémorisation, difficulté et ce qui reste du ressort du fuzzer

Les auteurs ont aussi vérifié que le modèle ne se « souvient » pas de bugs présents dans ses données d'entraînement. La date de coupure des connaissances de Gemini 3.6 flash est mars 2026. Les bugs de Chrome étaient alors rendus publics environ trois mois après leur correction, de sorte que la coupure effective pour les bugs Fuzzilli tombe en janvier 2026. Aucune mémorisation statistiquement significative n'a été trouvée sur les bugs antérieurs à 2026. Pour d'autres modèles, cette vérification mérite d'être refaite.

Sur la « difficulté » d'un bug, c'est-à-dire le temps qu'a mis Fuzzilli à le trouver, la corrélation est statistiquement significative, mais d'amplitude réduite. Sa direction va en outre à l'opposé du scénario idéal, où le LLM s'attaque sans peine à ce que le fuzzer trouve difficilement, ce qui permettrait de réallouer le budget de fuzzing.

L'expérience inverse (chercher avec le fuzzer les anciens bugs de BigSleep) n'a pas été menée. On ne peut pas diriger un fuzzer vers un commit précis aussi simplement. De plus, la plupart des anciens bugs de BigSleep ont été trouvés après des mois, voire des années de fuzzing de builds vulnérables. En production, le fuzzer a de toute façon de l'avance : BigSleep est lancé une fois par jour et signale les crashs avec 1 à 2 jours de retard.

Ce que les équipes de sécurité peuvent en retenir

Il n'est pas encore possible de comparer le coût par trouvaille. Clusterfuzz est optimisé depuis des années, alors que BigSleep n'a pas reçu un travail comparable, et le coût par bug n'a été réglé sur aucun des deux systèmes.

Enseignements de la méthode :

• lancez à la fois du fuzzing et de l'analyse par agent : leurs angles morts diffèrent nettement ; • donnez à l'agent le diff d'un commit précis et exigez un PoC. S'arrêter au premier crash limite la consommation de tokens ; • vérifiez le PoC sur les builds avant et après correction pour distinguer le bug recherché d'un autre ; • utilisez des builds avec sanitizers et un mode « flags sûrs uniquement » ; • ne calculez les métriques que sur les rapports exploitables avec commits correctifs, et dédupliquez-les avec ceux de Clusterfuzz ; • lors d'une évaluation sur des bugs historiques, comparez le taux de réussite avant et après la date de coupure du modèle, afin d'écarter la mémorisation.