TL;DR:
- Google prueba duplicar el ritmo de entregas de seguridad de Chrome, de una a dos por semana.
- Chrome 149 y 150 corrigieron 1,072 fallas de seguridad, más que las 23 versiones anteriores sumadas.
- La compañía trabaja en parches que se apliquen sin reiniciar el navegador, todavía sin fecha de llegada.
Google va a parchar Chrome más seguido. El equipo de seguridad del navegador publicó este jueves 30 de julio de 2026 que sus modelos de IA encontraron y corrigieron 1,072 fallas de seguridad solo en las versiones 149 y 150, más que las 23 versiones anteriores juntas, y que ese volumen ya dejó de caber en el calendario de entregas. Por eso la compañía está probando dos actualizaciones de seguridad por semana en lugar de una. Detrás hay una cadena de agentes montada sobre Gemini que rastrea los errores, los clasifica, propone el parche y hasta escribe las pruebas. Y la parte incómoda no cambió, porque mientras el usuario no reinicie el navegador, el parche no lo protege.
El informe, firmado por el equipo de seguridad de Chrome, describe una línea de montaje donde la IA entra en cada etapa:
- Un arnés de agentes con Gemini recorre el código del navegador apoyado en una base de conocimiento que incluye los CVE previos y todo el historial de Git de Chrome.
- El triaje, que antes tomaba de 5 a más de 30 minutos por reporte y dependía sobre todo de un experto humano, ahora filtra spam y duplicados, reproduce la prueba de concepto, asigna la severidad y manda el caso a su responsable.
- Un agente propone varios parches candidatos y otro, el crítico, decide cuál encaja mejor, en un ciclo que imita una revisión de código común y corriente.
- Otros agentes escriben las pruebas y las corren en todas las plataformas que soporta Chrome antes de que un desarrollador revise el arreglo.
Google calcula que solo el triaje automatizado le ahorra cientos de horas de trabajo de ingeniería al mes.
La IA destapó un fallo que llevaba 13 años escondido
El momento que convenció al equipo llegó a principios de 2026, cuando el arnés de agentes encontró un escape del sandbox que había sobrevivido más de 13 años en el código. Explotado, ese fallo le habría permitido a un proceso de renderizado comprometido engañar al navegador para leer archivos locales.
Los modelos no trabajan sueltos. Google detalla que analizan el código en reposo, en máquinas cerradas sin acceso general a internet, con todas las peticiones de red interceptadas y filtradas por listas de permitidos, y que los subagentes no pueden modificar el sistema ni salir de los directorios de código asignados.
El efecto se notó también fuera de casa. Para marzo de 2026 la compañía ya había recibido más reportes de errores que en todo 2025, así que ajustó su programa de recompensas para empujar a los investigadores externos hacia los bugs que sus herramientas internas no alcanzan. Es el mismo fenómeno que ya se ve en el catálogo público de vulnerabilidades.
Patricia Rodriguez
"Un aumento en los errores encontrados y corregidos no es señal de fracaso", escribió el equipo de seguridad de Chrome.
El cuello de botella se movió de encontrar las fallas a repartirlas
Aquí está el problema real. En cuanto una corrección entra al código abierto de Chromium, cualquiera puede leerla, deducir qué fallaba y armar el ataque antes de que la actualización llegue a las máquinas de la gente.
El "patch gap" es esa ventana: el tiempo que corre entre la corrección publicada y el parche instalado. Google dice que triar, arreglar, probar y publicar le toma de uno a dos días. La espera por el reinicio del usuario, en cambio, no tiene reloj.
Chrome ya venía migrando a versiones principales cada dos semanas con parches de seguridad semanales. La prueba de dos entregas por semana es un escalón más, y la compañía la justifica con ataques que también se aceleraron con IA. No es una hipótesis lejana: los agentes ya aparecen del lado ofensivo en incidentes reales, y el propio Chrome se apoya en herramientas del mismo tipo, como BigSleep y CodeMender, integradas a su sistema de integración continua y corriendo cada 24 horas sobre todos los cambios. Solo en mayo bloquearon más de 20 vulnerabilidades antes de que llegaran a producción, incluida una crítica.
Chrome 151 llegó un día antes: 370 correcciones y 349 las halló Google
El mejor termómetro del informe se publicó 24 horas antes. El miércoles 29 de julio Google liberó Chrome 151 al canal estable (versiones 151.0.7922.71/.72 en Windows y Mac, 151.0.7922.71 en Linux) con 370 correcciones de seguridad: 7 críticas, 71 altas, 170 medias y 122 bajas.
El reparto de créditos es lo interesante. Según el conteo de SecurityWeek sobre el boletín oficial, 349 de esas fallas las reportó Google y solo 21 llegaron de investigadores externos, que se llevaron 58,500 dólares en recompensas (13 pagos siguen sin monto público). La más alta del boletín fue de 36,000 dólares por un uso después de liberar en el componente de navegación. Con esta ronda, Chrome acumula más de 1,800 vulnerabilidades corregidas en lo que va de 2026, calcula el mismo medio.
Conviene no revolver las cifras: 1,072 es el conteo propio de Google de errores de seguridad arreglados en dos versiones, mientras que 370 son los CVE listados en el boletín de una sola. Miden cosas distintas y no se suman.
Entre esos créditos aparece uno que ilustra hacia dónde va la industria: el fallo CVE-2026-17658 en el motor V8 lo reportó Duc Nguyen, de Calif.io, en colaboración con OpenAI Codex Security. Máquina contra máquina, con humanos firmando el reporte.
El reinicio del navegador sigue en manos del usuario
Google admite que nadie reinicia Chrome con gusto: interrumpe, hay que buscarle hueco entre tareas y casi nunca es la prioridad del momento. Su apuesta para quitar esa fricción se llama dynamic patching y consiste en reemplazar sobre la marcha los procesos hijos que corren en segundo plano, como el renderizador y la GPU, sin cerrar el navegador. Sigue en investigación y desarrollo, sin fecha comprometida.
Lo que ya funciona es más modesto. Desde Chrome 150 en macOS, si el navegador detecta una actualización pendiente mientras corre en segundo plano y sin ninguna ventana abierta, se reinicia solo.
Para las empresas, que suelen ser las que más tardan en actualizar, Google recomienda tres medidas concretas:
- Aplicar la política RelaunchNotification, que le pide al usuario reiniciar y escala del recordatorio suave al reinicio forzado en un plazo definido.
- Usar el canal Extended Stable en entornos sensibles donde cada cambio de software debe revisarse antes.
- Vigilar las versiones de toda la flota desde los paneles de Chrome Enterprise Core o Premium.
En paralelo, Chrome sigue atacando familias enteras de errores en lugar de casos aislados: 97% del código propio ya compila limpio con las advertencias estrictas de búfer, la tecnología MiracleObject apunta a neutralizar hasta 90% de los usos después de liberar en el hilo principal de la GPU, y los componentes nuevos de alto riesgo se están escribiendo en Rust. La superficie es enorme: el navegador arrastra más de 2,300 dependencias de terceros, de las cuales unas 1,700 llegan al usuario final.
Chrome es el navegador más usado del mundo, así que cada día que un parche se queda esperando un reinicio es un día de ventaja para quien ya leyó la corrección en el código abierto. Google sostiene que la ventaja quedó del lado de los defensores. El número que lo comprobaría, cuánto se acortó de verdad la ventana entre la corrección y la instalación, es justo el que la compañía todavía no publica.
