Google ha arreglado 1.072 fallos de Chrome con IA: el cuello de botella ahora eres tú

Google ha corregido 1.072 fallos de seguridad en dos versiones de Chrome, más que en las veintitrés versiones anteriores juntas. El titular es espectacular y, para tu empresa, casi irrelevante: la inmensa mayoría de esos fallos no los estaba explotando nadie. Lo que sí te afecta es el ritmo al que van a empezar a caerte las actualizaciones encima —Chrome está pilotando dos publicaciones de seguridad por semana, y desde septiembre publica un hito cada dos semanas—. Eso no es una noticia sobre inteligencia artificial. Es una noticia sobre tu calendario.

Los números se publicaron el 30 de julio en el blog de Google. Chrome 149 y Chrome 150, ambas de junio, sumaron 1.072 fallos corregidos; TechCrunch cifra en 1.036 los de los veintitrés hitos anteriores, repartidos a lo largo de dos años. Con Chrome 151 encima, las tres últimas versiones acumulan 1.442 correcciones, y el año va por encima de las 1.800. La curva no ha subido: ha cambiado de forma.

La máquina que peina el código

No es un producto ni un anuncio de feria: es una cadena de herramientas metida en el proceso de ingeniería. Google lleva usando modelos de lenguaje en investigación de seguridad desde 2023, pero lo que ha disparado la cifra, según su propia explicación, es un agente construido a principios de 2026 sobre Gemini, entrenado con una base de conocimiento de CVE anteriores y con el historial completo de Git de Chrome. A eso se le suman Naptime (2024, con Project Zero), Big Sleep (con DeepMind y Project Zero, especializado en el motor JavaScript V8 y en gráficos) y CodeMender, que vive dentro del sistema de integración continua. Los modelos no solo buscan: reproducen el fallo, le asignan severidad, lo enrutan al equipo, generan un parche candidato y escriben la prueba.

El dato que mejor explica el cambio no es el 1.072, es este otro: solo en mayo, ese sistema bloqueó más de veinte vulnerabilidades antes de que llegaran a producción, una de ellas crítica. Y el hallazgo estrella es un escape del sandbox que permitía que un proceso de renderizado comprometido engañara al navegador para leer ficheros locales, y que llevaba más de trece años en el código. SecurityWeek lo identifica como CVE-2026-3545, con CVSS 9,8, corregido a principios de mayo en Chrome 145.

Trece años. Ese fallo sobrevivió a Project Zero, a un programa de recompensas que paga bien, a las auditorías de media industria y a una cantidad de ojos que ningún otro proyecto de software libre tiene. Conviene decirlo sin épica: lo interesante no es que la máquina sea lista, es que el listón humano estaba mucho más bajo de lo que nos gusta creer. Y hay una consecuencia que ya se está notando en el ecosistema: en marzo, Google había recibido más reportes de seguridad que en todo 2025, y ha tenido que reorientar su programa de recompensas para priorizar lo que aporte algo a lo que ya encuentra sus propias herramientas. El cazador de bugs humano compite ahora con algo que no duerme y que además sabe dónde mirar.

«Aplicando modelos como Gemini estamos corrigiendo vulnerabilidades de forma preventiva, adelantándonos a nuestros adversarios y haciendo Chrome más seguro con cada actualización.» — Doug Turner, director de ingeniería de Chrome.

1.072 no es una medida de riesgo

Que hayan arreglado 1.072 fallos no quiere decir que el Chrome de la semana pasada fuera 1.072 veces más peligroso. La inmensa mayoría de esos fallos no los estaba explotando nadie, y muchos ni siquiera eran explotables por sí solos. Lo que ha aumentado no es el riesgo: es la capacidad de encontrar. Son dos gráficas distintas y llevan semanas dibujándose una encima de la otra.

La consecuencia práctica es incómoda para mucha gente que hace informes: contar CVE ha dejado de medir nada. Hace dos semanas contábamos 622 parches de Microsoft en un solo martes, un récord absoluto, y ya entonces el número por sí solo no decía si tu empresa estaba mejor o peor. Ahora el ruido de fondo sube otra vez. Si tu cuadro de mando de seguridad tiene un gráfico de «vulnerabilidades del mes», ese gráfico ya no informa: decora.

Lo que sí sigue midiendo son dos cosas, y ninguna aparece en la nota de prensa: si un fallo se está explotando de verdad —para eso está el catálogo KEV de CISA, y por eso priorizamos por explotación y no por CVSS— y cuánto tardas tú en llevar el parche del anuncio a la máquina. Google acaba de acelerar su mitad de esa ecuación. La segunda la controlas tú, y ahí no hay agente que valga.

El dato que sí te cambia el calendario

Conviene ser honestos con la cronología, porque buena parte de la cobertura la ha mezclado. La cadencia de dos semanas no se anunció el 30 de julio: se anunció el 3 de marzo y arranca con Chrome 153, el 8 de septiembre de 2026. Y las actualizaciones de seguridad semanales existen desde 2023. Lo genuinamente nuevo de este anuncio es otra cosa, y va justo en la dirección que a un administrador le importa: Google está pilotando dos publicaciones de seguridad por semana para estrechar la ventana entre que el fallo se corrige y tú lo tienes puesto. Para un usuario doméstico todo esto es transparente: el navegador se actualiza solo y ya está. Para quien gestiona un parque de doscientos puestos, no.

Porque una actualización de navegador en una empresa no termina cuando se descarga el binario: termina cuando el usuario reinicia. Y el usuario no reinicia. Tiene cuarenta pestañas abiertas, el ERP en una de ellas y un pedido a medio hacer. Existe una política de Chrome Enterprise para forzarlo, RelaunchNotification, y en la mayoría de parques que nos llegan de fuera está sin configurar, con lo cual el navegador está parcheado en disco y sin parchear en memoria. Ese matiz, que suena a detalle de administrador, es literalmente la diferencia entre estar protegido y creerlo.

Y aquí hay que darle a Google lo que es de Google, porque es la parte del anuncio que menos se ha contado: esa mitad también la están atacando. Desde Chrome 150 en macOS, el navegador puede reiniciarse solo para aplicar una actualización pendiente cuando lleva rato de fondo y sin ventanas abiertas. Y el objetivo declarado va más lejos: parcheo dinámico, es decir, aplicar la actualización sin reiniciar el navegador, más una mejor restauración de sesión. Si lo consiguen, el problema del reinicio se termina. Dentro de Chrome. Que es justo donde se acaba el favor: nadie va a hacer parcheo dinámico de tu ERP, de tu cliente VPN ni del firmware de tus puntos de acceso.

Google también ofrece el canal Extended Stable, pensado para entornos sensibles que necesitan ir más despacio, y que sigue con su ciclo de ocho semanas también después de septiembre. Ese contraste resume el dilema mejor que ningún párrafo: ocho semanas por un lado, dos publicaciones de seguridad por semana por el otro. Es una herramienta legítima cuando hace falta. Pero conviene decir para qué sirve y para qué no: es un botón de «voy más despacio», no un botón de «no me actualizo». Si lo activas porque tienes una aplicación interna que solo funciona con una versión concreta del navegador, no has resuelto un problema de seguridad: has aplazado un problema de desarrollo, y le has puesto fecha de caducidad. Y si tu política es «el navegador se revisa en el mantenimiento trimestral», con dos publicaciones de seguridad por semana eso ya no es una política: es una deuda con intereses.

La asimetría que nadie va a arreglar por ti

Aquí está, en nuestra opinión, lo que de verdad hay que llevarse de esta noticia. Google puede permitirse una flota de agentes revisando su propio código, con su propia integración continua, su historial de casi dos décadas y su base de conocimiento de CVE. Es de las poquísimas empresas del mundo que puede. El software que sostiene tu negocio, no.

El ERP vertical que usa tu sector y que mantienen cuatro personas. El software del fabricante de la máquina de producción, que se actualiza cuando viene el técnico. El visor del escáner, el plugin del CRM, la aplicación de fichaje, el firmware de la impresora de etiquetas. Nadie va a pasarle un agente con Gemini a ese código. El listón de seguridad está subiendo, muy rápido, exactamente donde ya estaba alto —navegadores, sistemas operativos, cloud de los grandes— y no se está moviendo ni un milímetro donde estaba bajo. Tu riesgo no baja: se desplaza.

Y hay un detalle del propio anuncio que lo resume mejor que cualquier metáfora: Chrome arrastra más de 2.300 dependencias de terceros, de las cuales unas 1.700 se distribuyen a los usuarios. Ni siquiera Google ejecuta solo código de Google. Buena parte de esas bibliotecas también están dentro de tus aplicaciones, empaquetadas por tus proveedores, y ahí no hay ninguna flota de agentes mirando.

La otra cara ya la escribimos hace una semana: el atacante tiene las mismas herramientas. Ni él ni Google han inventado clases de fallo nuevas; los dos han comprimido el tiempo. Si el tiempo de encontrar se comprime en los dos bandos, el tiempo de aplicar tiene que comprimirse también, y ese es el único de los tres que depende de ti.

El trabajo aburrido que sí cambia el resultado

Nada de esto es glamuroso y casi todo cabe en una tarde de trabajo bien hecha. Es lo que hacemos en los parques que mantenemos, y es literalmente el trabajo del mantenimiento informático cuando se hace en serio y no a golpe de aviso.

• Un inventario que no sea el Excel. Qué software corre en cada puesto y en cada servidor, con versión. Sin eso, «¿estamos afectados?» solo se puede responder con un encogimiento de hombros.
• Actualización automática por defecto en navegadores y clientes. Con esta cadencia, dejar que se actualice solo es la decisión conservadora; retenerlo para «controlar» es la arriesgada. Se ha dado la vuelta y mucha política interna todavía no se ha enterado.
• Forzar el reinicio. RelaunchNotification en modo obligatorio, con RelaunchNotificationPeriod ajustado —por defecto son siete días, que con esta cadencia es demasiado— y RelaunchWindow para que el reinicio forzado caiga de madrugada y no a media mañana. Un parche que espera a que el usuario cierre el navegador el viernes es un parche que no existe de lunes a jueves.
• Excepciones con fecha y con dueño. Toda máquina que no se puede actualizar necesita las dos cosas escritas. Una excepción sin fecha es una decisión permanente tomada por accidente.
• Priorizar por explotación, no por volumen. El catálogo KEV de CISA primero, el resto por ventana de mantenimiento. Intentar llegar a todo es la forma más eficaz de no llegar a lo que importa.
• Medir el tiempo, no la cantidad. La métrica útil es cuántos días pasan entre que el fabricante publica y el parque lo tiene puesto; y sobre todo la cola: ese puñado de máquinas que siempre se queda atrás. El incidente vive en la cola, nunca en la mediana.
• Compensar lo que no se puede parchear. El PC del taller con un Windows que no se toca porque controla una máquina de producción que costó seis cifras existe en casi todas las empresas. No se parchea: se aísla en su VLAN, se le limita con quién habla y se vigila con EDR/MDR. Eso sí se puede hacer hoy.

Y cuatro cosas que no hacemos

• Desactivar la actualización automática para «controlar los cambios». Con hitos cada dos semanas, eso ya no es control: es acumular versiones hasta que el salto sea tan grande que dé miedo darlo.
• Medir la seguridad por número de CVE. Ni al alza ni a la baja. Un mes con 1.072 correcciones puede ser el mes más seguro del año.
• Comprar algo por el titular. Ninguna herramienta que se venda esta semana con la palabra «IA» delante te va a reducir el tiempo entre que sale el parche y lo tienes puesto. Eso es proceso, no producto.
• Confundir «el fabricante ya lo ha arreglado» con «ya está arreglado en mi empresa». La distancia entre esas dos frases, medida en días, es tu superficie de ataque real.

El parche existe desde el minuto cero

Nos gusta esta noticia, y no por la cifra. Nos gusta porque enseña algo que llevamos años diciendo con menos datos: el problema del parcheo nunca fue que faltaran parches. Los parches existen desde el minuto cero. El riesgo vive en los días que hay entre que existen y que están puestos, y esos días no los pone el fabricante, los pones tú. Si tu parte sigue siendo «lo miramos el mes que viene», el resultado neto de toda esta maravilla tecnológica dentro de tu empresa es exactamente cero.

Y si al leer esto no sabes cuántos días tarda un parche en llegar a la última máquina de tu empresa, esa es la pregunta con la que empezaríamos. No hace falta una herramienta nueva para responderla; hace falta mirarlo. Si quieres que lo miremos contigo, ya sabes dónde estamos.

Fuentes (verificadas): las cifras de correcciones (1.072 en Chrome 149 y 150, más que en los 23 hitos anteriores juntos), las herramientas (Naptime con Project Zero en 2024, Big Sleep con DeepMind, el agente sobre Gemini de principios de 2026, CodeMender en la integración continua), las más de 20 vulnerabilidades bloqueadas antes de producción en mayo, el escape de sandbox de más de 13 años, el cambio del programa de recompensas, las más de 2.300 dependencias de terceros (unas 1.700 distribuidas) y la nueva cadencia de hitos cada dos semanas con el piloto de dos publicaciones de seguridad por semana, del anuncio de Google «Chrome: stronger with every update» (blog.google, 30 de julio de 2026). El comportamiento de las políticas RelaunchNotification, RelaunchNotificationPeriod (siete días por defecto en Chrome) y RelaunchWindow, de la documentación de Chrome Enterprise. El reinicio automático desde Chrome 150 en macOS con el navegador de fondo y sin ventanas, el objetivo de parcheo dinámico y el piloto de dos publicaciones de seguridad por semana, del mismo anuncio y de la cobertura de BleepingComputer. La cadencia de dos semanas NO es de este anuncio: se publicó el 3 de marzo de 2026 en el blog para desarrolladores de Chrome y arranca con Chrome 153 el 8 de septiembre de 2026, con el canal Extended Stable manteniendo su ciclo de ocho semanas y las actualizaciones de seguridad semanales existentes desde 2023. La comparativa de los 23 hitos anteriores (1.036 fallos en dos años), las fechas de Chrome 149 y 150 y la cita de Doug Turner, de TechCrunch (30 de julio de 2026). La identificación del escape de sandbox como CVE-2026-3545 (CVSS 9,8, corregido en Chrome 145 a principios de mayo) y el acumulado de más de 1.800 fallos en 2026, de SecurityWeek. El total de 1.442 correcciones en las tres últimas versiones, de The Hacker News. Los 622 parches de Microsoft de julio son los del boletín que cubrimos en su día. No hemos verificado de forma independiente el recuento interno de Google.