Google anunció una nueva ronda de fallos corregidos en Chrome que eleva el listón de la seguridad del navegador. En total, las correcciones reportadas superan ampliamente la suma de los errores corregidos en los 23 hitos anteriores, lo que deja claro que el ritmo de hallazgos y parches sigue acelerándose.
La compañía detalló que estas incidencias se repararon en las versiones 149 y 150, lanzadas el mes pasado, y que después llegó un parche adicional para la versión 151. Además de los números, el anuncio también describe cómo Google intenta reducir cuellos de botella entre la detección y la divulgación pública, y cómo busca aplicar correcciones sin reiniciar siempre el navegador.
Más de 1.000 vulnerabilidades reparadas en Chrome
Según el comunicado, Google cerró 1.072 problemas de seguridad en las versiones 149 y 150. La cifra es especialmente relevante porque supera el total de fallos corregidos en los 23 anteriores lanzamientos de parche.
En el parche más reciente para Chrome 151, publicado el miércoles, Google resolvió 370 vulnerabilidades. De esas, 349 fueron reportadas por la propia empresa, según su información pública. También indicó que siete de las vulnerabilidades corregidas fueron clasificadas como críticas.
El salto de frecuencia en el hallazgo de bugs
Más allá del volumen de correcciones, Google enmarca el problema en un contexto más amplio: el descubrimiento de vulnerabilidades está aumentando a un ritmo muy alto. Una de las razones que se menciona es el papel de los modelos de lenguaje grandes (LLM), que están acelerando la búsqueda y el reporte de fallos.
El resultado es un incremento inédito de nuevas alertas. Google plantea que, en la práctica, los avisos aparecen más rápido de lo que muchas organizaciones pueden convertirlos en parches, lo que aumenta la presión para mejorar la entrega de actualizaciones.
Datos de 2026: el número de fallos se acerca a los de todo 2025
Como referencia, Google citó estadísticas de la National Vulnerabilities Database (NVD) de Estados Unidos. En 2026, se habrían registrado 46.872 fallos hasta el momento del análisis, acercándose a las 49.920 vulnerabilidades reportadas durante todo 2025.
Este tipo de comparación sirve para entender por qué los equipos de seguridad están revaluando el modo en que responden: no basta con corregir, también hay que reducir el tiempo entre el hallazgo, el parche y la disponibilidad para usuarios.
Un ejemplo crítico: escape del sandbox en el componente Navigation
Entre las vulnerabilidades destacadas, Google mencionó un caso particularmente delicado: un escape crítico del sandbox en el componente Navigation. La incidencia se identificó como CVE-2026-3545 con una puntuación CVSS de 9.6.
De acuerdo con la descripción, un atacante podría explotar el fallo para engañar al navegador y hacer que intente leer archivos locales desde el sistema del usuario. Google indicó que este problema fue corregido a principios de marzo.
Cómo se detectó y por qué tardó en aparecer
Google señaló que el problema se descubrió mediante un entorno de pruebas (agent harness) que aprovechaba sus modelos Gemini. El dato más llamativo es que el fallo habría permanecido sin detección en el código durante más de 13 años hasta que se activó esa forma de análisis.
Google acelera la cadencia y prueba más ritmo de seguridad
El anuncio también se relaciona con el calendario de versiones. Google explicó que está en proceso de pasar a una cadencia de dos semanas para los principales hitos de Chrome, junto con actualizaciones de seguridad semanales.
Además, la compañía mencionó que está pilotando el paso hacia dos publicaciones de seguridad por semana. El motivo es claro: se enfrentan a ataques impulsados por IA que se mueven muy rápido.
Con todo, Google subrayó que el anuncio y la divulgación pública siguen siendo esenciales. Remarcó que cada fallo que llegue a Chrome Stable, independientemente de si fue hallado internamente o reportado desde fuera, debe documentarse y divulgarse públicamente como práctica estándar.
Reducir cuellos de botella en notas de versión y descripciones CVE
Google reconoció que parte del retraso puede venir de tareas manuales: redactar notas de lanzamiento y preparar descripciones asociadas a CVEs tras cada arreglo.
Por eso, afirmó que trabaja en automatizar esfuerzos para generar esas notas y descripciones a partir de los cambios. La idea es acortar la ventana entre el descubrimiento del fallo y su divulgación, sin sacrificar la claridad para la comunidad.
Parcheo dinámico: corregir sin interrumpir siempre el uso
Otra línea de trabajo que destaca el anuncio es la búsqueda de mecanismos para aplicar correcciones sin necesidad de reiniciar Chrome en todas las situaciones. La compañía explicó que, cuando el reinicio sí sea necesario, intentan minimizar el impacto para conservar la sesión.
Según Google, la estrategia aprovecha la arquitectura multiproceso de Chrome. En lugar de depender solo de un reinicio completo, se podrían reemplazar en el momento procesos secundarios en segundo plano (por ejemplo, los vinculados al Renderer o la GPU) con binarios actualizados.
Ejemplo en macOS con estado de aplicación
Google también dio un ejemplo: en Chrome 150, se aprovechó una particularidad del sistema en macOS. Allí, las aplicaciones suelen continuar ejecutándose incluso cuando no hay ventanas abiertas.
De este modo, si Chrome detecta una actualización pendiente mientras está en ese estado sin ventanas, puede reiniciarse automáticamente para aplicar el cambio. Con esta lógica, el usuario no queda con retrasos innecesarios y la carga se reduce respecto a la espera manual.
Eliminar categorías enteras de riesgos de seguridad
Más allá de parchar, Google indicó que también busca reducir clases completas de vulnerabilidades. En particular, mencionó la intención de combatir problemas como use-after-free, fallos out-of-bounds y otras debilidades ligadas a la seguridad de memoria.
Para lograrlo, la compañía planea endurecer el entorno de ejecución, avanzar hacia lenguajes con más garantías de seguridad de memoria, como Rust, y reforzar partes del navegador usando tecnologías web como HTML, CSS y TypeScript en componentes de la interfaz de nivel superior.
La meta es disminuir la dependencia de frameworks tradicionales escritos en C++ y, con ello, reducir la superficie donde históricamente han aparecido ciertas familias de fallos.
Actualizar dependencias de terceros con pipelines automáticos
Finalmente, Google señaló una medida adicional para mejorar la seguridad: mover las dependencias de terceros de Chrome hacia pipelines de actualización automatizados. Así, la empresa busca asegurarse de que los componentes externos relevantes estén al día.
La razón es directa: si cada bug corregido es una oportunidad menos para un atacante, también importa que las piezas que rodean al navegador evolucionen con rapidez. En sus palabras, no basta con descubrir y corregir; hay que publicar y desplegar los cambios más rápido que la explotación maliciosa.
Conclusión: seguridad continua, menos fricción
Los datos de Google muestran un escenario en el que las fallos corregidos en Chrome no se cuentan solo por decenas, sino por miles en pocos hitos. A la vez, el anuncio deja claro que la respuesta no se limita a parchear: incluye acelerar la cadencia, automatizar la divulgación, probar el parcheo dinámico y endurecer el entorno para evitar que reaparezcan ciertas categorías de problemas.
En conjunto, la estrategia apunta a un objetivo más amplio: que Chrome esté continuamente protegido sin interrumpir de forma excesiva la experiencia del usuario, incluso cuando el ritmo de amenazas y hallazgos es cada vez más rápido.
Fuente: https://thehackernews.com/2026/07/three-recent-chrome-releases-fix-1442.html
