Chrome 155 llegó con 247 correcciones de seguridad

Chrome 155 llegó al canal Stable el 6 de octubre de 2026. El anuncio de la versión dice que incluye 247 correcciones de seguridad, cuatro de ellas clasificadas como críticas. Es un lote inusualmente grande, incluso para el ritmo de dos semanas al que Chrome pasó con Chrome 153.

Esta entrada cubre lo que dice la versión, lo que deja abierto y por qué el ritmo de parches de un navegador forma parte de la rutina de cualquiera que opera un formulario.

Qué llegó

La compilación de escritorio es 155.0.8059.39/.40 en Windows y macOS y 155.0.8059.39 en Linux. Chrome 155 también llegó a Android y a iOS. Llegó en dos pasos: una parte pequeña de los usuarios de Windows y macOS recibió 155.0.8059.26/.27 el 30 de septiembre, y el despliegue amplio empezó el 6 de octubre. Chrome 156 entró en el canal Beta el 30 de septiembre.

El anuncio de Google señala que el acceso a los detalles de los errores y a sus enlaces sigue restringido hasta que la mayoría de los usuarios haya recibido la corrección, y que la restricción dura más cuando el fallo está en una biblioteca de terceros de la que también dependen otros proyectos.

El reparto por gravedad en el análisis secundario es cuatro críticas, 53 altas, 122 medias y 68 bajas. Comparado con la actualización de escritorio anterior, que llevó 11 correcciones, esta es una versión que cambia mucho de golpe.

Los cuatro errores críticos

Las cuatro entradas críticas son errores use-after-free, una clase en la que se libera memoria mientras algo sigue manteniendo un puntero a ella. Google las enumera por componente y por CVE.

• Chromecast: CVE-2026-106382, informado por Google.

• Browser: CVE-2026-106197, informado por Xinyang Ge.

• Navigation: CVE-2026-106358, informado por Xinyang Ge, de Anthropic, con la ayuda de Claude.

• Track: CVE-2026-106347, informado por Xinyang Ge, de Anthropic, con la ayuda de Claude.

Un use-after-free en Navigation o en Track importa a cualquiera cuya página envíe un formulario, porque ambos están en el camino que recorre el navegador cuando un visitante pasa de una página a otra y se envía un envío. Es una razón para ocuparse del parche. No es una afirmación de que algo en tu página estuviera roto.

Por qué el ritmo forma parte de tu rutina

Chrome ya publica cada dos semanas. Un formulario que recibe envíos a través de un componente generado se ejecuta en el navegador que trajo el visitante, y ese navegador no lo controlas tú. Lo que sí controlas es la rapidez con la que tus propias máquinas aplican el parche, y si alguien lee las notas de la versión.

Dos hábitos cubren casi todo. Actualiza los navegadores que usa tu equipo. Luego anota qué pruebas después de cada versión de navegador: un envío desde un navegador de escritorio, uno desde un teléfono y una página alojada abierta desde cero. Es una rutina más barata que enterarte de un cambio de renderizado por la queja de quien envió.

Lo que esto no decide

• No dice que un error se haya explotado. El anuncio de Google no afirma que alguna de las 247 vulnerabilidades se haya usado, y los detalles de los cuatro errores críticos siguen restringidos.

• No dice que FormFlow se haya visto afectado. Nada de esto afirma que FormFlow, sus páginas alojadas o su componente generado fueran vulnerables, se hayan probado con Chrome 155 o hayan cambiado por esta versión.

• No dice que tu formulario funcione en Chrome 155. Si tu página se renderiza y envía correctamente es una pregunta para tu propia prueba, en tu propia página.

Lee el número de correcciones como el tamaño del mantenimiento, no como una medida del peligro. La acción útil es la misma en ambos casos: actualiza y luego prueba la única página de la que dependes.