Google actualizó el canal estable de Chrome el 3 de septiembre con 12 correcciones de seguridad, y sobre una de ellas dice, textualmente, que "Google tiene conocimiento de que existe un exploit para CVE-2026-85046 en circulación". CISA la sumó al catálogo de explotación activa al día siguiente, con plazo al 18 de septiembre.

La versión que corrige es 152.0.7977.82 (en Windows y Mac también aparece como .83).

Es la falla más fácil de arreglar de todas las que cubrimos esta semana, y por eso mismo la que más gente va a dejar sin arreglar: Chrome se actualiza solo, pero no termina de hacerlo hasta que cerrás y volvés a abrir el navegador.

Qué alcanza realmente CVE-2026-85046

La descripción de NVD es precisa y conviene leerla completa, porque la mitad que se pierde en los resúmenes es la que define el riesgo:

Confusión de tipos en V8 en Google Chrome anterior a 152.0.7977.82 permitía a un atacante remoto ejecutar código arbitrario dentro del sandbox mediante una página HTML preparada.

Dentro del sandbox. V8 es el motor que ejecuta JavaScript, y corre en un proceso aislado a propósito, con permisos recortados. Ejecutar código ahí adentro no es todavía tener la máquina: para salir hace falta una segunda falla, de escape de sandbox, encadenada con esta.

Eso no la vuelve inofensiva. Desde el proceso del renderizador se llega a lo que ese proceso maneja, que es exactamente lo que el atacante suele querer: el contenido de las pestañas y las cookies de sesión. Robada la cookie, el segundo factor ya se cumplió y no vuelve a pedirse — el mecanismo está en la guía sobre cómo funciona el robo de sesión que saltea el MFA.

Hasta dónde llega la falla, y dónde se frena Dentro del sandbox del renderizador — alcanzado Contenido de las pestañas abiertas y cookies de sesión Con la cookie robada, el segundo factor ya no se vuelve a pedir Fuera del sandbox — requiere una segunda falla Sistema operativo, archivos del equipo, otras aplicaciones Ninguna cadena de escape confirmada para este caso "Ejecución de código" no significa lo mismo en un navegador que en un servidor

CISA le asignó 8,8 en CVSS 3.1, y vale aclararlo porque en el propio aviso de Google la severidad figura como High, no como crítica. El puntaje lo cargó CISA, no Google.

Por qué CISA le da 14 días a Chrome y tres a un firewall

Esta semana cubrimos siete fallas con plazo de tres días en aparatos de acceso remoto y centrales telefónicas. Chrome, con explotación confirmada por el propio fabricante, se lleva catorce.

No es incoherencia. Calculado sobre el feed del catálogo, las 70 entradas de Chromium que hay en el KEV nunca recibieron un plazo de tres días: treinta llevan catorce, treinta y cuatro llevan veintiuno y seis llevan ciento ochenta y uno.

La razón es la vía de corrección. Un firewall como el Firebox de WatchGuard lo tiene que parchear una persona en una ventana programada, y si esa persona no existe el equipo queda vulnerable para siempre. Chrome, en cambio, se repara solo en la enorme mayoría de los equipos sin que nadie haga nada. El plazo refleja cuánto tarda ese arreglo automático en llegar a todos, no cuán grave es la falla.

El componente donde apareció esta falla no es cualquiera. Contando sobre el mismo feed:

RecorteEntradas en el catálogo KEV
Chromium, en total70
De esas, en el motor V840 (57%)
De esas, confusión de tipos en V820

Más de la mitad de todo lo que se explotó de Chromium está en el motor de JavaScript, y la mitad de eso es el mismo tipo de error que hoy: confusión de tipos, que es cuando el motor trata un objeto en memoria como si fuera de una clase distinta a la que realmente es.

Dónde se concentra lo explotado de Chromium Chromium, total 70 En el motor V8 40 — el 57% Confusión de tipos 20 El mismo error, veinte veces: es la clase de falla que más se explota en el navegador

Que se repita no es señal de abandono: V8 es el código más auditado del navegador justamente porque es el más atacado. La lectura práctica es otra —el navegador es una superficie de ataque de primera línea, no un accesorio— y merece la misma disciplina de actualización que un servidor.

¿Cómo sé qué versión de Chrome tengo?

En la barra de direcciones, escribí chrome://settings/help y entrá. Esa pantalla hace tres cosas a la vez: muestra la versión instalada, busca actualizaciones y las descarga.

Si el número es 152.0.7977.82 o superior, estás corregido. Si es menor, la pantalla va a descargar la actualización sola y después va a aparecer el botón de Reiniciar.

Ese botón es todo el asunto.

Por qué Chrome descarga el parche pero no lo aplica

El propio anuncio de Google dice que la versión nueva "se desplegará en los próximos días o semanas". O sea que ni siquiera la descarga es instantánea para todos.

Y una vez descargada, Chrome no reemplaza el motor en ejecución: espera al próximo arranque del navegador. En una oficina donde la gente suspende la notebook en vez de apagarla, un Chrome puede llevar semanas abierto. Ese equipo tiene el parche en el disco y sigue corriendo el código vulnerable.

Es la diferencia entre "la empresa está parcheada" y "la empresa descargó el parche", y en un navegador con exploit en circulación esa diferencia se mide en días de exposición.

¿Quién puede ignorar el aviso de Chrome?

  • Quien ya está en 152.0.7977.82 o superior y reinició el navegador después de actualizar.
  • Quien no usa un navegador basado en Chromium. Firefox y Safari tienen otro motor y no les aplica esta falla.

Con una advertencia grande: Edge, Brave, Opera y Vivaldi son Chromium, comparten V8 y se actualizan por su propio canal. Tener Chrome al día no actualiza a los demás. Si en la empresa conviven dos o tres navegadores, son dos o tres actualizaciones distintas.

Qué hacer con Chrome hoy, en orden

  1. Abrí chrome://settings/help y reiniciá el navegador si aparece el botón. Treinta segundos.
  2. Hacé lo mismo con cualquier otro navegador Chromium que haya en los equipos: Edge, Brave, Opera, Vivaldi.
  3. Avisá al equipo que cierre y reabra el navegador. Es el único paso que no se puede automatizar del todo y el que más se saltea.
  4. Si administrás los equipos centralmente, forzá la política de reinicio del navegador: Chrome permite exigir el reinicio tras una cantidad configurable de días desde que la actualización quedó pendiente.
  5. Revisá las sesiones abiertas de las cuentas críticas —correo, banca, panel del hosting— y cerralas si hubo motivo de sospecha. Es la vía por la que esta clase de falla hace daño real.

Si esto te encuentra sin un inventario de qué navegadores hay en la empresa, ese es el problema de fondo y está tratado en la guía de ciberseguridad para PyMEs de LATAM.

Preguntas frecuentes sobre CVE-2026-85046 en Chrome

¿Me pueden tomar la computadora entera con esta falla?

Con esta sola, no. La ejecución de código ocurre dentro del sandbox del renderizador; para salir de ahí hace falta encadenar una segunda vulnerabilidad de escape, y no hay ninguna cadena así confirmada para este caso. Lo que sí alcanza son las pestañas y las cookies de sesión, que ya es suficiente para hacer daño.

Si Chrome se actualiza solo, ¿por qué tengo que hacer algo?

Porque la actualización se descarga sola pero se aplica al reiniciar el navegador. Google además aclara que el despliegue tarda "días o semanas" en llegar a todos. Entrar a chrome://settings/help fuerza la búsqueda y te muestra el botón de reinicio si hace falta.

Uso Microsoft Edge, ¿me afecta?

Edge está construido sobre Chromium y comparte el motor V8, así que la falla del motor le aplica. La corrección llega por el canal de actualización de Edge, que es independiente del de Chrome: hay que actualizarlo por separado.

¿Por qué el plazo de CISA es de 14 días si ya hay exploit?

El plazo estima cuánto tarda la corrección en llegar, no la gravedad. Ninguna de las 70 entradas de Chromium en el catálogo recibió jamás un plazo de tres días, porque el navegador se repara solo en la mayoría de los equipos. Un firewall no.

¿Sirve de algo el antivirus contra esto?

Poco, contra la explotación en sí: el ataque llega como una página web y se ejecuta en memoria dentro del navegador. Donde sí ayuda una herramienta de detección de comportamiento es en lo que viene después, si el atacante intenta persistir o moverse. La cobertura de esa distinción está en cuándo se justifica un EDR sobre un antivirus.


Fuentes primarias. Anuncio del canal estable de Chrome, 3 de septiembre de 2026 · CVE-2026-85046 en NVD · Catálogo KEV de CISA, versión 2026.09.04, del que salen los recuentos de Chromium y V8.

Consultadas el 5 de septiembre de 2026. La falla la reportó Salvatore Gulizia el 4 de agosto, según los créditos del propio anuncio de Google. Para el vocabulario, el glosario; sobre cómo leer los plazos del catálogo, la nota sobre el campo "Exploited" de Microsoft.