BigSleep, baseado em LLM, achou 45 vulnerabilidades no V8; Fuzzilli, 37, com 25% de sobreposição

Em seis meses, de abril a setembro de 2026, o agente LLM BigSleep encontrou 45 vulnerabilidades funcionais no V8, e o fuzzer generativo Fuzzilli, 37. O Google usa as duas ferramentas em produção para verificar o código novo do motor JavaScript do Chrome. A equipe do Project Zero comparou os resultados e chegou a duas conclusões. A sobreposição entre os achados é pequena: no bug tracker, cerca de 25% (20 de 81 reports funcionais). Em um experimento reconstruído com bugs históricos, ela chegou a aproximadamente 60%. Ainda assim, uma parcela considerável das vulnerabilidades é encontrada por apenas uma das abordagens.

Como 441 reports viraram 45 vulnerabilidades

A contagem bruta pelas hotlists do bug tracker do Chromium dá uma pequena vantagem ao BigSleep: 441 reports contra 316 do Fuzzilli. Mas, no início, o BigSleep encontrava muitos problemas de configuração e de integração, como o bloqueio de flags inseguras que não funcionava (crbug.com/503869331). Bugs assim quase não têm impacto real na segurança.

Se considerarmos apenas type:vulnerability, o quadro se inverte: 178 do Fuzzilli e 95 do BigSleep. Mas esse número também está inflado. Parte dos reports são duplicatas ou foram fechados como WAI ("works as intended", ou seja, "funciona como projetado"). Um simples filtro pelo status fixed também não resolve. Por exemplo, o bug do Fuzzilli crbug.com/511935486 foi aberto e fechado no mesmo dia pelo Clusterfuzz, porque o testcase deixou de reproduzir. Quase certamente é uma duplicata de crbug.com/511210507, mas a assinatura do crash pelo stack trace era um pouco diferente, e o sistema não os uniu. Nenhum engenheiro chegou a mexer nesse bug.

Por isso, foram contados apenas os reports "funcionais": que não são duplicatas nem WAI e têm pelo menos um commit de correção. Para o tipo Type-Vuln, o resultado foi 45 contra 37 a favor do BigSleep.

Sobreposição: um quarto no tracker, cerca de 60% no experimento

Para contar os achados em comum, os bugs foram deduplicados em quatro etapas:

• duplicatas explícitas, quando o report de um sistema está marcado como duplicata do report do outro, como crbug.com/522410841 e crbug.com/522860268; • duplicatas implícitas: para os reports "não funcionais", busca-se o commit de correção e unem-se os bugs ligados a ele. A relação pode ser múltipla: um bug do BigSleep e um do Fuzzilli podem duplicar um terceiro; • duplicatas da base do Clusterfuzz que não chegaram ao tracker; • bugs diferentes fechados pelo mesmo CL (por exemplo, quatro bugs em crrev.com/c/7965120) também são tratados como duplicatas.

Resultado: 20 bugs em comum de 81, e pouco mais da metade deles foi encontrada primeiro pelo Fuzzilli.

Essa contagem subestima a sobreposição, por isso a equipe montou um experimento. Foram usados cerca de 1150 bugs históricos do Fuzzilli, de 2023 até meados de 2026. Desses, ficaram cerca de 600 vulnerabilidades e, em seguida, 132 bugs reproduzíveis na build pública debug+asan do d8 em x64, sem flags especiais. Após a deduplicação, restaram 112. Para cada um, identificou-se o provável commit que introduziu o bug, principalmente por bisseção, e o agente foi executado 25 vezes com a tarefa de encontrar bugs nesse commit e confirmá-los com um testcase que derruba a build. No total, foram 2800 execuções, na configuração do BigSleep de produção da época, com o modelo Gemini 3.6 flash.

Resultado: cerca de 62% dos bugs originais foram reencontrados; em outros 12% dos commits, o agente achou um bug diferente, já corrigido; em 26%, não encontrou nada. O cenário é deliberadamente desfavorável ao agente: o commit pode ter sido identificado de forma errada, e, na prática, o bug também poderia ser pego em um commit posterior no mesmo trecho de código.

Memorização, dificuldade e o que continua com o fuzzer

Também foi verificado separadamente se o modelo "lembra" de bugs presentes nos dados de treinamento. A data de corte de conhecimento do Gemini 3.6 flash é março de 2026. Na época, os bugs do Chrome eram abertos ao público cerca de três meses depois, de modo que o corte efetivo para os bugs do Fuzzilli cai em janeiro de 2026. Não foi encontrada memorização estatisticamente significativa nos bugs anteriores a 2026. Para outros modelos, vale repetir a verificação.

Quanto à "dificuldade" do bug, medida pelo tempo que o Fuzzilli levou para encontrá-lo, a relação é estatisticamente significativa, embora pequena em magnitude. A direção, porém, é oposta à do cenário ideal, em que o LLM resolve com facilidade o que o fuzzer alcança com dificuldade e o orçamento de fuzzing poderia ser redistribuído.

O experimento inverso (usar o fuzzer para buscar bugs antigos do BigSleep) não foi feito. Não dá para apontar o fuzzer para um commit específico com a mesma facilidade. Além disso, a maioria dos bugs antigos do BigSleep foi encontrada depois de meses ou anos de fuzzing de builds vulneráveis. Em produção, o fuzzer já sai com uma vantagem: o BigSleep roda uma vez por dia e reporta os crashes com 1–2 dias de atraso.

Práticas para equipes de segurança

Ainda não é possível comparar o custo por achado. O Clusterfuzz foi otimizado ao longo de anos, o BigSleep não recebeu um trabalho comparável, e o custo por bug não foi ajustado em nenhum dos dois sistemas.

Conclusões da metodologia:

• rode fuzzing e análise agêntica: eles têm "pontos cegos" claramente diferentes; • dê ao agente o diff de um commit específico e exija um PoC. Parar no primeiro crash limita o gasto de tokens; • verifique o PoC em builds anteriores e posteriores à correção, para distinguir o bug procurado de outro; • use builds com sanitizers e o modo "somente flags seguras"; • calcule as métricas apenas com reports funcionais que tenham commits de correção e deduplique-os junto com os do Clusterfuzz; • ao avaliar com bugs históricos, compare a taxa de sucesso antes e depois da data de corte do modelo, para descartar memorização.