La IA de Google encuentra 1,072 fallos en Chrome en 60 días

Google afirma que su flujo de trabajo de seguridad con IA ayudó a encontrar y corregir 1,072 vulnerabilidades de Chrome a lo largo de dos lanzamientos, más que el número total de fallos de seguridad corregidos en los 23 hitos anteriores combinados. Los lanzamientos por hitos, etiquetados M149 y M150, se completaron en aproximadamente 60 días.

La escala importa. Chrome y su proyecto de código abierto Chromium representan alrededor del 73% del mercado global de navegadores, con aproximadamente 3,5 mil millones de usuarios activos. El equipo de seguridad de Chrome de Google detalló el trabajo en una entrada de blog que describe cómo se está usando la IA para mejorar la detección, el triaje y la corrección de vulnerabilidades.

La carga de trabajo de seguridad de Chrome da un giro brusco hacia arriba

Los hitos de Google generalmente llegan aproximadamente una vez al mes. A partir de M128, lanzado el 20 de agosto de 2024, la compañía corrigió aproximadamente 50 fallos de seguridad por hito hasta M145. Luego los números aumentaron rápidamente: M146 corrigió alrededor de 80 fallos, M147 unos 130 y M148 unos 350.

M149 y M150 sumaron 1,072 correcciones, produciendo lo que Google describió como una curva de crecimiento en forma de palo de hockey. El aumento plantea un problema operativo además de una oportunidad de seguridad: cada vulnerabilidad debe validarse, repararse, probarse en los entornos compatibles con Chrome, publicarse y entregarse a los usuarios.

Recomendado

Paquete PyPI 999.9.9 recopiló claves SSH

Una corrección defectuosa podría crear nuevos problemas en miles de millones de instalaciones del navegador, cientos de miles de extensiones de Chrome y la vasta colección de páginas web. Por tanto, Google tiene que aumentar la velocidad de su respuesta sin bajar la calidad de su revisión.

Del fuzzing a los agentes de vulnerabilidades de Gemini

Google comenzó a usar IA para aumentar la cobertura de fuzzing en 2023. El fuzzing alimenta el software con entradas inesperadas o aleatorias para exponer fallos. Alrededor de la época de M128 en 2024, la compañía añadió herramientas de IA especializadas para el análisis de vulnerabilidades.

En 2025, Google dijo que trabajó con DeepMind y Project Zero en Big Sleep, un agente de IA para el descubrimiento de vulnerabilidades que encontró fallos en el motor V8 de JavaScript y en la pila gráfica de Chrome. En 2026, Google presentó un arnés de agentes basado en Gemini, diseñado para buscar vulnerabilidades en todo el código de Chrome.

El sistema está pensado para razonar sobre cadenas de interacciones en lugar de simplemente marcar una línea de código con un manejo de entradas inadecuado. Google lo describió como la exploración de escenarios que podrían conducir a una falla de seguridad, incluida una evasión del sandbox que existía en Chrome desde 2013. Si se explotara, esa falla podría engañar al navegador para que leyera archivos locales. Gemini la encontró a principios de 2026 después de que había sobrevivido a los conjuntos de pruebas durante más de una década.

La fuente no ofrece un desglose de cuántas de las 1,072 vulnerabilidades provinieron de cada sistema de IA, ni identifica el conjunto completo de herramientas utilizadas en los dos lanzamientos.

Cuatro etapas del triaje asistido por IA

Google ha construido un proceso de cuatro etapas para manejar el volumen creciente de informes:

• Filtrado: los agentes de IA eliminan informes inválidos, duplicados o irrelevantes —el “ruido” en el proceso de entrada.
• Reproducción: los agentes ejecutan Chrome en entornos virtuales que coinciden con el navegador y el sistema operativo informados para determinar si el fallo puede reproducirse. Cuando lo logran, añaden detalles como trazas de pila.
• Enriquecimiento: los agentes adjuntan metadatos y otra información de contexto para preparar un expediente más completo.
• Transferencia: el sistema identifica al responsable humano apropiado y transmite la información recopilada.

«Aunque es difícil medirlo con precisión, estimamos que este nuevo proceso está ahorrando cientos de horas de tiempo de desarrolladores al mes.»

Google dice que el flujo de trabajo ahorra tiempo a los desarrolladores al trasladar tareas administrativas y de verificación a los agentes. Los desarrolladores pueden entonces centrarse en investigar y reparar vulnerabilidades confirmadas en lugar de determinar si cada informe debe entrar en la lista de tareas del equipo.

Agentes de corrección, crítica y pruebas

El flujo de reparación utiliza múltiples agentes en lugar de pedir a un único sistema que escriba y envíe un parche. Un agente de reparación produce cambios de código candidatos. Un agente crítico evalúa esos candidatos, selecciona el más adecuado y aporta información adicional para los desarrolladores humanos.

El reparador y el crítico repiten este proceso en un ciclo que se asemeja a la revisión de código. Comprueban si el cambio propuesto funciona y si sigue los estándares de codificación de Chrome. Agentes separados que escriben pruebas luego construyen tests y ejecutan Chrome en sus plataformas soportadas. Los problemas encontrados durante las pruebas se devuelven al reparador y al crítico antes de que un humano revise el parche.

Google dijo que este proceso multiagente ahorra semanas de tiempo a los desarrolladores, aunque la fuente no especifica cuántas correcciones fueron finalmente aceptadas sin revisión humana del código ni cuántos candidatos generó cada vulnerabilidad.

Chrome apunta a lanzamientos de seguridad dos veces por semana

La velocidad de descubrimiento crea un segundo cuello de botella: entregar las correcciones a los usuarios. Google dijo que, incluso cuando sabe que una vulnerabilidad está siendo explotada, las correcciones normalmente han tardado semanas en llegar al canal estable de Chrome.

La compañía trabaja hacia una cadencia de dos semanas para los hitos principales y una cadencia semanal para las actualizaciones de seguridad. Debido al aumento de la velocidad de los ataques, Chrome también impulsa dos lanzamientos de seguridad por semana.

Chrome ha usado descargas silenciosas en segundo plano durante casi una década. Las actualizaciones pueden almacenarse en disco y aplicarse cuando el usuario reinicia el navegador, pero eso crea una ventana entre la descarga de un parche y su activación. Google está probando varias formas de reducir ese retraso:

• Parcheo dinámico que podría eliminar la mayoría de los reinicios del navegador.
• Guardar el estado del navegador localmente para que las sesiones puedan reanudarse fácilmente.
• Encontrar oportunidades menos intrusivas para reiniciar Chrome.

Google no indicó cuándo el objetivo de lanzamientos de seguridad dos veces por semana se convertirá en estándar. La tensión central sigue siendo la misma: Chrome debe parchear más rápido a medida que la IA acelera el descubrimiento de vulnerabilidades, y al mismo tiempo asegurarse de que las propias correcciones no introduzcan fallos a escala global.