BigSleep, basado en LLM, encontró 45 vulnerabilidades en V8 y Fuzzilli, 37; solo el 25% coincide

Durante seis meses, de abril a septiembre de 2026, el agente LLM BigSleep encontró en V8 45 vulnerabilidades válidas, y el fuzzer generativo Fuzzilli, 37. Google utiliza ambas herramientas en producción para revisar el código nuevo del motor de JavaScript de Chrome. El equipo de Project Zero comparó sus resultados y extrajo dos conclusiones. El solapamiento entre lo que encuentra cada una es pequeño: según el bug tracker, ronda el 25% (20 de 81 informes válidos). En un experimento reconstruido con bugs históricos llegó a aproximadamente el 60%. Aun así, una parte considerable de las vulnerabilidades la detecta solo uno de los dos enfoques.

Cómo se pasó de 441 informes a 45 vulnerabilidades

El recuento en bruto a partir de los hotlists del bug tracker de Chromium da una ligera ventaja a BigSleep: 441 informes frente a 316 de Fuzzilli. Pero al principio BigSleep encontraba muchos problemas de configuración e integración, por ejemplo, un bloqueo de flags inseguros que no funcionaba (crbug.com/503869331). Estos bugs casi no tienen impacto real en la seguridad.

Si se filtra solo por type:vulnerability, el panorama se invierte: 178 de Fuzzilli y 95 de BigSleep. Pero esa cifra también está inflada. Parte de los informes son duplicados o se cerraron como WAI («funciona como se diseñó»). Filtrar simplemente por el estado fixed tampoco basta. Por ejemplo, el bug de Fuzzilli crbug.com/511935486 lo abrió y lo cerró Clusterfuzz el mismo día, porque el caso de prueba dejó de reproducirse. Casi con seguridad es un duplicado de crbug.com/511210507, pero la firma del fallo en el stack trace era algo distinta y el sistema no los fusionó. Ningún ingeniero llegó a tocar ese bug.

Por eso solo se contaron los informes «válidos»: los que no son duplicados, no son WAI y tienen al menos un commit de corrección. Para el tipo Type-Vuln el resultado fue 45 frente a 37 a favor de BigSleep.

Solapamiento: una cuarta parte en el tracker, cerca del 60% en el experimento

Para contar los hallazgos comunes, los bugs se deduplicaron en cuatro pasos:

• duplicados explícitos, cuando el informe de un sistema está marcado como duplicado del informe del otro, como crbug.com/522410841 y crbug.com/522860268; • duplicados implícitos, cuando para los informes «no válidos» se busca el commit que los corrige y se fusionan los bugs vinculados a él. La relación puede ser múltiple: un bug de BigSleep y uno de Fuzzilli duplican ambos a un tercero; • duplicados de la base de datos de Clusterfuzz que no llegaron al tracker; • bugs distintos cerrados por un mismo CL (por ejemplo, cuatro bugs en crrev.com/c/7965120), que también se consideran duplicados.

Resultado: 20 bugs comunes de 81, y algo más de la mitad los encontró primero Fuzzilli.

Este recuento subestima el solapamiento, así que se montó un experimento. Se tomaron unos 1150 bugs históricos de Fuzzilli, desde 2023 hasta mediados de 2026. Quedaron unas 600 vulnerabilidades y, de ellas, 132 bugs reproducibles en la compilación pública debug+asan de d8 para x64 sin flags especiales. Tras la deduplicación quedaron 112. Para cada uno se localizó el commit que probablemente lo introdujo, sobre todo mediante bisección, y se ejecutó 25 veces el agente con la tarea de encontrar bugs en ese commit y confirmarlos con un caso de prueba que hiciera fallar la compilación. En total son 2800 ejecuciones con la configuración de BigSleep de producción de aquel momento, con el modelo Gemini 3.6 flash.

Resultado: alrededor del 62% de los bugs originales se encontraron de nuevo; en otro 12% aproximadamente de los commits, el agente dio con un bug distinto ya corregido, y en el 26% no encontró nada. El planteamiento perjudica de partida al agente: el commit pudo identificarse mal, y en un caso real el bug también puede detectarse en un commit posterior del mismo código.

Memorización, dificultad y qué sigue quedando para el fuzzer

Por separado se comprobó si el modelo recuerda bugs de sus datos de entrenamiento. La fecha de corte de conocimiento de Gemini 3.6 flash es marzo de 2026. Los bugs de Chrome se hacían públicos entonces unos tres meses después, así que el corte efectivo para los bugs de Fuzzilli cae en enero de 2026. No se encontró una memorización estadísticamente significativa en bugs anteriores a 2026. En otros modelos conviene repetir la comprobación.

En cuanto a la «dificultad» de un bug, es decir, el tiempo que Fuzzilli tardó en encontrarlo, la dependencia es estadísticamente significativa, aunque de magnitud pequeña. Además, la dirección es contraria al escenario ideal, en el que el LLM resuelve con facilidad lo que al fuzzer le cuesta y el presupuesto de fuzzing puede redistribuirse.

No se hizo el experimento inverso (buscar con el fuzzer los bugs pasados de BigSleep). A un fuzzer no se le puede dirigir con la misma facilidad a un commit concreto. Además, la mayoría de los bugs antiguos de BigSleep aparecieron tras meses o años de fuzzing sobre compilaciones vulnerables. En producción, el fuzzer ya parte con ventaja: BigSleep se ejecuta una vez al día e informa de los fallos con un retraso de 1–2 días.

Práctica para equipos de seguridad

Por ahora no se puede comparar el coste por hallazgo. Clusterfuzz se ha optimizado durante años, BigSleep no ha recibido un trabajo comparable, y el precio por bug no se ha ajustado en ninguno de los dos sistemas.

Conclusiones de la metodología:

• ejecute tanto fuzzing como análisis con agentes: sus «puntos ciegos» difieren de forma notable; • dé al agente el diff de un commit concreto y exija una PoC. Detenerse en el primer fallo limita el gasto de tokens; • verifique la PoC en compilaciones anteriores y posteriores a la corrección, para distinguir el bug buscado de otro distinto; • use compilaciones con sanitizers y un modo de «solo flags seguros»; • calcule las métricas solo con informes válidos que tengan commits de corrección, y deduplíquelos junto con Clusterfuzz; • al evaluar con bugs históricos, compare la tasa de éxito antes y después de la fecha de corte del modelo para descartar la memorización.