Chrome pasa a un ciclo de actualización de dos semanas: con la seguridad en el reloj

Google llevó Chrome 153 al canal Stable el 8 de septiembre de 2026 y, con ello, cambió el navegador más usado del mundo de un ciclo de publicación de cuatro semanas a uno de dos. El cambio, anunciado en marzo y activado esta semana, supone una nueva versión beta y una nueva versión stable cada dos semanas para escritorio, Android e iOS. Chrome 154 ya está en beta y su llegada a Stable está prevista para el 22 de septiembre.

Lectura relacionada: Project Zenith de Microsoft quiere que Windows esté listo para programar. Los desarrolladores no se convencen · Las acciones de ServiceNow cayeron un 27% cuando el miedo a la IA llegó al negocio del software.

El momento no es casual. Google enmarca el ritmo más rápido tanto como una medida de seguridad como una ofensiva de funciones, y Chrome 153 lo deja claro: la versión reúne 230 correcciones de seguridad, cinco de ellas clasificadas como críticas, y un zero-day que los atacantes ya estaban explotando. Las publicaciones más rápidas, sostiene el argumento, reducen la ventana entre que una corrección llega al código público y llega a los usuarios.

Qué cambia realmente

Chrome seguía un ciclo de hitos de cuatro semanas desde 2021, y de seis semanas antes de eso. A partir de Chrome 153, el intervalo se reduce a la mitad:

• Un nuevo hito Stable cada dos semanas. Chrome 153 llegó el 8 de septiembre; Chrome 154 está previsto para el 22 de septiembre.
• También una nueva beta cada dos semanas. Las compilaciones beta salen ahora unas tres semanas antes de la versión Stable correspondiente.
• Todas las plataformas. El ritmo de dos semanas cubre escritorio, Android e iOS.
• Dev y Canary no cambian. Google mantiene su canal Dev semanal y su canal Canary diario tal como estaban.
• Versiones más pequeñas. Cada hito incluye menos cambios, lo que según Google hace más fácil aislar las regresiones.

El mecanismo que hay detrás es una publicación «early stable»: un candidato sale aproximadamente un día después del corte de la rama, para que Google pueda vigilar si algo se rompe antes del despliegue completo. Con el nuevo calendario, Chrome 153 se cortó para Stable el 25 de agosto y llegó a los usuarios el 8 de septiembre, una ventana de estabilización más corta de lo que permitía el plan anterior.

El ritmo, en términos sencillos

La expresión clave es la «semana sin publicación» (no-release week). No significa una semana sin parches. Desde 2023, Chrome mantiene un canal de seguridad semanal independiente que traslada correcciones a la versión Stable actual entre hitos. Una semana sin publicación es, sencillamente, una semana en la que el número de versión del navegador no cambia: ni funciones nuevas ni hito, pero sí la actualización de seguridad habitual.

Con el antiguo ritmo mensual, un hito llegaba más o menos cada cuatro semanas y dejaba dos semanas más tranquilas en medio. En un ciclo de dos semanas esas lagunas desaparecen: una semana suele traer un hito y la siguiente una actualización de seguridad o el inicio de la próxima beta. Para la mayoría de los usuarios, el efecto práctico son actualizaciones de funciones más pequeñas y frecuentes y más avisos de reiniciar para actualizar. Para las empresas, supone un salto de versión en los dispositivos gestionados el doble de a menudo.

Nada de esto altera el mecanismo de actualización. Chrome sigue descargando las actualizaciones en segundo plano y solo las aplica tras un reinicio, y Google sigue desplegándolas a lo largo de varios días en lugar de enviarlas a todas las máquinas a la vez. En los Chromebook, la compañía ha dicho que las nuevas versiones seguirán llegando tras pruebas específicas de plataforma, y prometió más detalles para dispositivos gestionados más adelante.

Por qué Google acelera

La explicación de Google apunta a la IA. «Con herramientas automatizadas de descubrimiento basadas en IA y los informes de errores de la comunidad generando un mayor volumen de parches, los ciclos de publicación más cortos simplifican notablemente la gestión de las correcciones de seguridad», escribió el equipo de Chrome. Reducir la distancia entre que una corrección llega al código público de Chromium y llega a los usuarios finales, continúa la entrada, mantiene lo más pequeña posible la brecha de parcheo «N-day».

La brecha N-day es un problema real, no un eslogan. Cuando un parche aparece en el árbol de código público de Chromium, cualquiera que vigile el repositorio puede estudiarlo y reconstruir un exploit para la versión sin parchear. En teoría, cada día entre una corrección pública y su entrega a los usuarios es un día que un atacante puede aprovechar. Google dijo a TechCrunch que las herramientas automatizadas y los informes de la comunidad han elevado el volumen de parches, y Engadget informó de que el esfuerzo se apoya en herramientas impulsadas por Gemini para encontrar vulnerabilidades más rápido.

El aviso de Chrome 153 muestra la tendencia de la IA de forma tangible. Entre los errores de gravedad alta acreditados figuran hallazgos atribuidos a «Google BigSleep@Grape» y a «OpenAI Codex Security», dos sistemas automatizados que ya presentan los mismos informes que los investigadores humanos. Hay además un motivo competitivo: las publicaciones más rápidas permiten a Chrome lanzar funciones de la plataforma web por delante de sus rivales, y Google señala que Microsoft, Mozilla y Brave avanzan en la misma dirección.

Un primer lanzamiento ajetreado

Chrome 153 muestra cómo será el nuevo ritmo en la práctica. El aviso del canal Stable enumera 230 correcciones de seguridad, entre ellas cinco errores críticos: cuatro fallos de seguridad de memoria en WebGL y uno en el componente Cast.

Solo uno acaparó titulares: CVE-2026-87491, una escritura fuera de límites en V8, el motor de JavaScript y WebAssembly de Chrome. Google lo clasifica como medio, pero el aviso añade la frase que importa: «Google tiene conocimiento de que existe un exploit para CVE-2026-87491 en el mundo real». SecurityWeek lo contabilizó como el séptimo zero-day de Chrome explotado activamente en 2026, y la agencia estadounidense de ciberseguridad CISA lo añadió a su catálogo de vulnerabilidades explotadas el 9 de septiembre, con fecha límite de remediación el 23 de septiembre.

Las compilaciones corregidas son 153.0.8010.36/.37 para Windows y macOS y 153.0.8010.36 para Linux. Según Google, la actualización se despliega a lo largo de los próximos días y semanas, y en Android llega a través de Google Play. Chrome en iOS no se ve afectado por esta vulnerabilidad concreta, según el fabricante.

¿Es el beneficio de seguridad tan grande como parece?

No por sí solo. El canal de seguridad semanal de Chrome (introducido con Chrome 116 en 2023) ya entregaba correcciones con un ritmo de siete días. Reducir a la mitad el intervalo de hitos, de 28 a 14 días, se apoya en un mecanismo que ya funcionaba a la mitad de ese plazo. Las mayores reducciones de la latencia de parcheo de Chrome llegaron en 2020 y 2023, no ahora.

Las fechas de notificación del aviso de Chrome 153 subrayan el punto. Muchos de los errores corregidos el 8 de septiembre se notificaron en marzo, abril y mayo de 2026, meses y no semanas antes de su entrega. El tiempo desde el descubrimiento hasta la entrega lo dominan la clasificación, la reproducción, el desarrollo de la corrección y la revisión, y un tren de publicación más rápido solo comprime el último tramo de esa cadena. Lo que el ciclo de dos semanas cambia de verdad es la latencia de las correcciones que viajan con un hito y el ritmo general al que se mueve el navegador como producto. Es una mejora real, pero incremental y superpuesta a una práctica ya existente.

Las contrapartidas también son reales. Más hitos significan más pruebas y más reinicios forzados, y las versiones más pequeñas no son automáticamente más seguras. Un tren más rápido deja menos tiempo para detectar una compilación defectuosa antes de que llegue a todos, y por eso existe el paso de early stable. Si dos semanas es el intervalo adecuado, o uno que cambia estabilidad por velocidad, es el experimento que Google acaba de empezar.

Qué significa para las empresas

La recomendación de Google es inusualmente directa. Para empresas e integradores de Chromium, el canal Stable de dos semanas «se convierte en la opción más segura» y debería usarse en la mayoría de las organizaciones. Extended Stable sigue existiendo para quienes no pueden asumir una publicación cada dos semanas.

En Extended Stable la aritmética se vuelve incómoda. Su intervalo de ocho semanas no ha cambiado, pero el número de hitos que contiene se ha duplicado: ahora abarca cuatro versiones Stable en lugar de dos, con actualizaciones de funciones importantes cada ocho semanas: Chrome 156 y luego Chrome 160. Un parque en Extended Stable puede por tanto quedar hasta tres versiones de hito por detrás de Stable, cuando antes quedaba una.

Google afirma que sigue trasladando las correcciones de seguridad a Extended Stable semanalmente, lo que suaviza el riesgo. Pero su propia documentación de versiones de Chromium señala que las correcciones complejas o arriesgadas, y las funciones de seguridad más grandes, pueden no ser portables y llegan solo al canal Stable convencional. Extended Stable se ofrece en Windows y macOS; los parques con Linux no tienen una opción equivalente y adoptan el ritmo de dos semanas quieran o no.

La carga operativa también crece. Beta ahora se publica cada dos semanas y llega a los usuarios unas tres semanas antes que Stable, de modo que un equipo que valida contra Beta afronta unas cuatro rondas de prueba dentro de un único ciclo de ocho semanas de Extended Stable en lugar de dos. La recomendación de pruebas no ha cambiado; el trabajo que hay detrás se ha duplicado.

Siete años de aceleración

La historia de versiones de Chrome es una compresión constante del intervalo entre actualizaciones. En 2010 el equipo adoptó la filosofía de publicar pronto y a menudo. En 2021 pasó de seis a cuatro semanas. En 2023 añadió actualizaciones de seguridad semanales y la publicación early stable. El salto a dos semanas en 2026 es el ciclo de hitos más corto que el navegador ha tenido nunca y, con unas 26 versiones Stable al año en lugar de 13, duplica el número de veces que TI debe intervenir en las máquinas gestionadas.

Qué hay que observar

Tres cosas demostrarán si el cambio da resultado. La primera es Chrome 154 el 22 de septiembre: un aterrizaje fluido validaría el calendario comprimido, mientras que una regresión temprana reabriría el debate sobre qué rapidez es demasiada. La segunda es si el sector sigue a Google como este predice; Microsoft Edge pasó a un ciclo principal de dos semanas a finales de agosto, y Mozilla y Brave han señalado planes similares. La tercera es la documentación para empresas, que esta semana todavía describía el ritmo antiguo en varios puntos.

Para el usuario corriente, el consejo es sencillo y no ha cambiado: mantener Chrome actualizado y reiniciarlo cuando lo pida. El navegador funciona ahora con un reloj más rápido, pero la corrección de seguridad que más importa en una semana concreta solo cuenta cuando se ha instalado.