Chrome parchea CVE-2026-125350, su octavo cero-día de 2026

Un investigador anónimo avisó el pasado viernes 6 de noviembre de un bug para Chrome, y para el lunes por la mañana, Google ya tenía el parche y una confirmación incómoda: alguien estaba usando el fallo antes de que existiera la solución. Se llama CVE-2026-125350, vive en el componente que Chrome emplea para leer XML y es un use-after-free, la clase de error de memoria que lleva una década alimentando las peores tardes de la industria. Con él, el navegador suma su octavo cero-día explotado en 2026, la misma cifra que acumuló durante todo 2025 y con casi dos meses todavía por delante.

La actualización llegó al canal estable el 9 de noviembre. Chrome queda en 157.0.8103.50 y .51 en Windows y macOS, y en 157.0.8103.50 en Linux. El paquete trae nueve correcciones, siete de severidad alta, y se distribuye por oleadas durante los próximos días o semanas.

El aviso oficial es de una sobriedad casi administrativa: confirma que existe un exploit, enumera los CVE y agradece a los investigadores. No dice quién ataca, ni a quién, ni cómo se entrega, ni qué consigue en el equipo comprometido. Esa contención es deliberada y responde a la política de divulgación de Google, que retiene detalles hasta que la mayoría ha actualizado. El problema práctico es que deja al usuario con una decisión que no puede evaluar del todo, mientras el CERT de Hong Kong clasifica el paquete como riesgo extremadamente alto por su capacidad de ejecución remota de código.

Un puntero liberado y ocho cero-días en un año

El fallo es un use-after-free. El navegador reserva un bloque de memoria, lo libera cuando ya no lo necesita y, por un error de gestión, conserva un puntero a esa zona. Si un atacante consigue colocar datos propios en el hueco antes de que el programa vuelva a leer el puntero, el navegador interpretará esos datos como si fueran suyos. En el mejor de los casos la pestaña se cae; en el peor, el atacante obtiene control del flujo de ejecución dentro del proceso del navegador.

Que el componente afectado sea el procesador de XML tiene su gracia. El XML no es el formato que más se ve en la web moderna, pero Chrome lo sigue procesando en documentos, fuentes, sitemaps y varios flujos internos que el usuario nunca identifica como tales. El paquete de este mes toca además WebGL, el sistema de ficheros, la composición de capas, la GPU y el motor V8. Un fallo de memoria en XML es difícil de alcanzar a mano, y ahí está la razón de que el aviso no explique el vector: publicar el detalle equivaldría a repartir el exploit entre quienes todavía no han actualizado.

Un detalle secundario que sí aparece en la letra pequeña: la lista de investigadores acredita a un anónimo y a dos equipos externos, y deja siete entradas firmadas por el propio Google.

El aviso del canal estable de Chrome sí enumera las nueve referencias, y ahí aparece la segunda pieza interesante: CVE-2026-125346, otro use-after-free en el mismo componente XML, reportado en octubre por Arni Hardarson, de Neonix Security. Google no ha dicho que este segundo esté siendo explotado. Dos fallos del mismo tipo en la misma pieza del navegador, en menos de un mes, es el tipo de coincidencia que los equipos de seguridad leen como deuda técnica y no como mala suerte.

Una cifra de miedo

La cifra de ocho merece contexto. Un cero-día explotado significa que alguien encontró la vulnerabilidad y la usó sin que existiera un parche, o al menos sin que el fabricante lo supiera. Que un navegador acumule ocho en un año no indica que sea más inseguro que sus rivales, sino que es el objetivo más rentable del ecosistema: tiene más usuarios que cualquier sistema operativo y se ejecuta sobre todos ellos. Los atacantes no eligen el objetivo más débil, eligen el que da acceso a más gente.

La comparación con 2025 tampoco es tranquilizadora. Google cerró el año pasado con ocho cero-días explotados en Chrome y ahora ha igualado la cuenta en noviembre, con la temporada alta de compras y regalos todavía por llegar. El patrón de los últimos meses apunta a que la explotación se ha industrializado: los fallos se detectan antes, se arman más rápido y se usan en campañas cortas y quirúrgicas antes de que el parche cierre la ventana.

Ocho en un año no es una anomalía estadística, es una tarifa que el ecosistema paga por compartir un solo motor. El navegador que todos usan es también el que todos intentan romper.

Para el usuario, la consecuencia práctica es que actualizar el navegador ha dejado de ser una tarea de mantenimiento y se ha convertido en una rutina de seguridad con fecha. Chrome no se actualiza solo si el equipo nunca se cierra o si una extensión bloquea el proceso, algo más común de lo que parece en flotas corporativas. En Linux, además, el paquete puede llegar empaquetado por la distribución semanas después del aviso si el usuario depende del repositorio del sistema en lugar del binario de Google.

¿Qué versión tienes que tener y cómo comprobarlo?

El procedimiento no ha cambiado: menú de tres puntos, Ayuda, Información de Google Chrome. El navegador se descarga la actualización y ofrece reiniciar; las pestañas se recuperan después. La distribución va por oleadas, así que el número de versión puede tardar en aparecer aunque Google ya haya publicado el arreglo. La tabla importa porque la actualización de Android mantiene los mismos arreglos que el escritorio y porque los usuarios del canal Extended Stable ven un número de versión distinto, una fuente habitual de confusión cuando alguien compara con una captura de pantalla.

ChromeOS es el hueco evidente. La última actualización estable del sistema, la M-156 del 6 de noviembre, no menciona CVE-2026-125350, y la nota de la beta del lunes tampoco traía detalles de seguridad. Quien trabaje en un Chromebook depende de que Google publique esa versión, y mientras tanto conviene asumir que el motor que abre pestañas en el dispositivo sigue siendo el vulnerable.

Lo que arrastra la actualización y no aparece en el aviso

Chrome no vive solo. Edge, Brave, Opera, Vivaldi y una lista larga de navegadores menores se construyen sobre el mismo código, y todos necesitan su propia actualización para recibir el arreglo. La misma lógica se aplica a las aplicaciones de escritorio construidas con Electron (clientes de chat, editores, herramientas de desarrollo) que embeben Chromium y heredan sus fallos sin que el usuario piense en ellas cuando lee eso de actualizar Chrome. Un parche aplicado en el navegador deja sin cubrir buena parte de la superficie real de un escritorio moderno.

Electron, por otro lado, es la puerta menos comentada y la más difícil de cerrar. El usuario no controla cuándo el desarrollador de su aplicación favorita recompila con el Chromium nuevo, y un cliente abandonado puede pasar meses con el motor viejo sin que nadie lo note hasta que alguien lo aprovecha.

Para el entorno corporativo hay dos preguntas que merecen respuesta esta semana. La primera es si el despliegue de Chrome está gestionado y con qué retraso llega el canal estable a los equipos. La segunda es si alguien ha inventariado las aplicaciones Electron que se ejecutan en los puestos de trabajo, porque esas no aparecen en el panel de actualizaciones del sistema operativo ni en los informes de cumplimiento habituales. Ninguna de las dos se resuelve leyendo el aviso de Google.

La ventana que Google no puede cerrar

La política de retener detalles hasta que la mayoría haya actualizado protege a mucha gente y deja a oscuras a otra tanta. Un administrador que necesita justificar una ventana de mantenimiento urgente no tiene más argumento que el número de CVE y la palabra explotado. Un analista que quiere saber si su organización estuvo expuesta tampoco encontrará el vector en el aviso, porque publicarlo convertiría el parche en un manual para el siguiente atacante.

Ese equilibrio es razonable y a la vez insuficiente, y conviene decirlo sin adornos. La única medida que reduce de verdad la exposición es la que lleva años repitiéndose y sigue sin ejecutarse con disciplina: navegador actualizado, sin esperas, y una lista honesta de todas las aplicaciones que llevan un motor de navegador dentro. El resto es gestión de riesgo, es decir, elegir a sabiendas qué se deja abierto.

El calendario de este mes lo deja claro. El CVE-2026-98432 del kernel de Linux sigue esperando parche en Debian y RHEL una semana después de su aviso, y el paquete falso de APT que daba root demostró que incluso el actualizador puede ser el vector.