Google corrigió más fallos de seguridad en Chrome en un solo mes que en los dos años anteriores juntos, gracias a la IA

Chrome 149 y 150 suman 1.072 vulnerabilidades corregidas, más que las 23 versiones anteriores combinadas. Google atribuye el salto a un ecosistema de agentes basados en Gemini que ahora participa en cada fase del ciclo de vida de un fallo de seguridad: desde su descubrimiento hasta la redacción del parche.

Google ha publicado un informe detallado sobre cómo el equipo de seguridad de Chrome está integrando modelos de lenguaje en su proceso de gestión de vulnerabilidades, y las cifras son llamativas: entre las versiones Chrome 149 y 150, lanzadas en junio, se corrigieron 1.072 fallos de seguridad, más que en las 23 versiones anteriores combinadas. Doug Turner, director de ingeniería de Chrome, ha declarado a TechCrunch que los modelos de lenguaje han transformado el descubrimiento de vulnerabilidades en una operación automatizada a escala industrial.

Solo la versión 149 llegó a corregir 429 fallos en su lanzamiento inicial —la cifra más alta registrada en una sola actualización—, de los cuales 371 fueron detectados internamente por Google. El resto llegó vía el programa de recompensas por errores, que repartió 209.000 dólares entre investigadores externos. Veintidós de esos fallos se clasificaron como críticos, la mayoría vulnerabilidades de tipo use-after-free en componentes gráficos como Angle.

De la fuzzing asistida a los agentes autónomos

El uso de IA en el equipo de seguridad de Chrome no es nuevo: empezó en 2023 mejorando la cobertura de fuzzing. En 2024 llegó Naptime, desarrollado con Project Zero, que dotaba a los modelos de herramientas específicas para investigación de vulnerabilidades. En 2025, la colaboración con Google DeepMind y Project Zero dio lugar a Big Sleep, un agente capaz de encontrar fallos en el motor JavaScript V8 y en la pila gráfica.

A comienzos de 2026, Google construyó un nuevo sistema basado en Gemini para rastrear vulnerabilidades en todo el código base de Chrome con menos falsos positivos. Uno de sus primeros hallazgos fue un sandbox escape que permitía a un proceso de renderizado comprometido engañar al navegador para leer archivos locales, un fallo que llevaba más de 13 años oculto en el código.

Para mitigar el riesgo de que estos sistemas actúen de forma imprevista, Google señala que sus modelos analizan el código exclusivamente en reposo, en máquinas aisladas sin acceso general a internet, con listas de permitidos estrictas para cualquier petición de red y sin capacidad de modificar el sistema local ni acceder a directorios fuera del código fuente designado.

Triaje y corrección, también automatizados

Más allá de encontrar fallos, Google ha automatizado buena parte del triaje: un sistema filtra duplicados y spam, intenta reproducir el fallo con una prueba de concepto, añade metadatos como la severidad y asigna el caso al componente y responsable adecuados. La compañía calcula que este proceso ahorra cientos de horas de trabajo de desarrollo al mes.

En la fase de corrección, varios agentes trabajan de forma encadenada: uno genera candidatos de parche, otro —un agente "crítico"— evalúa cuál es la mejor opción y comprueba que cumple con las convenciones de estilo de Chromium, y un tercer tipo de agente redacta pruebas que validan el parche en todas las plataformas compatibles. Estos mismos modelos, integrados junto con CodeMender en el pipeline de integración continua, escanean cada cambio de código cada 24 horas; solo en mayo bloquearon más de 20 vulnerabilidades antes de que llegaran a producción, incluida una clasificada como crítica de máxima prioridad (S1+).

El reto sigue siendo llegar a tiempo al usuario

Encontrar y corregir un fallo más rápido no sirve de mucho si el parche tarda semanas en llegar a los usuarios. Ese margen —el llamado "patch gap"— es la ventana en la que un atacante puede analizar un parche ya público en el repositorio y desarrollar un exploit antes de que la mayoría de usuarios haya actualizado. Para reducirlo, Google está probando pasar de una actualización de seguridad semanal a dos por semana, y está desarrollando "parcheo dinámico", una técnica que sustituiría procesos internos del navegador (como el renderizador o la GPU) sin necesidad de reiniciarlo por completo. En macOS, Chrome 150 ya reinicia automáticamente para aplicar actualizaciones pendientes cuando detecta que no hay ninguna ventana abierta.

Blindaje estructural: memoria segura y cadena de suministro

En paralelo, Chrome sigue reforzando su base de código en C++ mediante tecnologías como MiraclePtr —que neutraliza vulnerabilidades use-after-free— y un proceso de "spanification" que ya cubre el 97% del código propio de Chrome con comprobaciones estrictas de límites de memoria. A más largo plazo, la compañía está migrando los componentes históricamente más problemáticos —parsers, códecs de imagen, motores de fuentes— a Rust.

Google recuerda además que Chromium depende de más de 2.300 componentes de terceros, de los cuales unos 1.700 llegan de una forma u otra a los usuarios finales. Para mantenerlos al día, la compañía está moviendo todas esas dependencias a canales de actualización automática, y ha contribuido con 12,5 millones de dólares al proyecto Alpha-Omega, orientado a dar a los mantenedores de proyectos de código abierto herramientas para responder con rapidez a los avisos de vulnerabilidades.

Google insiste en que el aumento de fallos detectados no debe interpretarse como un deterioro de la seguridad de Chrome, sino como el resultado de una capacidad de detección muy superior a la que existía hasta ahora.