Chrome corrige el zero-day CVE-2026-85046: actualizá y reiniciá

Google publicó el 3 de septiembre de 2026 una actualización de Chrome que tapa 12 fallas de seguridad, y de una de ellas la propia empresa avisa que ya hay un exploit circulando. Es el CVE-2026-85046, un zero-day de Chrome alojado en V8, el motor de JavaScript del navegador. La versión que lo arregla es la 152.0.7977.82 y, aunque se descarga sola, no te protege hasta que reinicies el navegador.

La prioridad es instalar la actualización y reiniciar. El estado de los avisos de otros navegadores está resumido más abajo. Las versiones citadas son una referencia fechada al 5 de septiembre de 2026: usá el actualizador oficial para obtener la última disponible para tu canal.

Actualización del 9 de septiembre — leé esto antes que el resto: el 8 de septiembre Google promovió Chrome 153 al canal estable con 230 parches de seguridad y otro zero-day de V8 con exploit circulando, el CVE-2026-87491. Quedarte en la rama 152 ya no alcanza. El detalle, la comparación entre las dos fallas y lo que cambia para vos están en la actualización del 9 de septiembre.

Actualización del 10 de septiembre: dos firmas de seguridad publicaron los informes que contestan lo que Google no había contado — quién usó estas dos fallas, contra quién y desde cuándo—, y una de ellas midió que el arreglo del CVE-2026-85046 estuvo casi cuatro semanas a la vista de cualquiera antes de llegar a tu navegador. Está todo en la actualización del 10 de septiembre. Lo que tenés que hacer no cambió: actualizar y reiniciar.

Cómo actualizar Chrome y aplicar el parche

Chrome se actualiza solo, pero el parche recién entra en funcionamiento cuando reiniciás el navegador — y mucha gente tiene la misma ventana abierta hace semanas. El chequeo manual toma menos de lo que tardaste en leer este párrafo:

1. Abrí el menú de tres puntos, arriba a la derecha.
2. Entrá en Ayuda → Información de Google Chrome.
3. Chrome busca la actualización solo al abrir esa pantalla.
4. Cuando termine, tocá Reiniciar. Sin ese reinicio, seguís con la versión vieja.

La versión vigente al 9 de septiembre es la 153.0.8010.36 (Linux) o .36 / .37 (Windows y Mac), que trae 230 parches e incluye un segundo zero-day explotado. La tabla que sigue retrata el día del parche del CVE-2026-85046 y se conserva como referencia histórica: lo que corresponde hoy está en la actualización del 9 de septiembre. No bajes de versión ni cambies de rama por esta tabla; si el equipo está administrado, pedí confirmación a sistemas.

Estas eran las versiones a las que había que llegar al 3 de septiembre, según lo que uses:

Los anuncios de Early Stable 153 citados aquí no enumeran el arreglo de este CVE. No deduzcas que una rama es vulnerable o está corregida solo por comparar números de ramas distintas. Mantené tu canal actualizado; no cambies ni bajes de versión por esta tabla. Si el equipo está administrado, pedí confirmación a sistemas.

Las cuatro filas retratan el 3 de septiembre, y ese día la rama 153 todavía era Early Stable. El 8 de septiembre pasó a canal estable con parches de seguridad propios y documentados.

Qué parcheó Google y por qué este zero-day de Chrome es el que importa

El canal estable de Chrome pasó a 152.0.7977.82/.83 en Windows y Mac, y a 152.0.7977.82 en Linux. Google aclara que el despliegue ocurre «over the coming days/weeks», o sea que no le llega a todo el mundo el mismo día. En el anuncio oficial de Chrome Releases el detalle está en la última línea de la sección de seguridad, sin negrita ni alarma:

«Google is aware that an exploit for CVE-2026-85046 exists in the wild.» Traducido: Google sabe que existe un exploit para esa falla dando vueltas fuera del laboratorio. Google no dijo quién lo usa, ni contra quién, ni desde cuándo — y esa reticencia es la política de siempre, no un olvido. Seis días después, dos firmas de seguridad contestaron las tres preguntas con informes propios: está en la actualización del 10 de septiembre.

De hecho, el mismo documento lo explica: «Access to bug details and links may be kept restricted until a majority of users are updated with a fix» — el acceso a los detalles del bug puede quedar restringido hasta que la mayoría de los usuarios tenga el parche. Por eso el ticket del error —el 542403045— estuvo restringido al principio; para el 21 de septiembre ya se podía leer sin iniciar sesión, con el caso de reproducción y el crédito al investigador.

Qué es una «type confusion» en V8, en criollo

El registro oficial de la vulnerabilidad —redactado por Google, que actúa como autoridad de numeración de sus propios CVE, y publicado en la base del programa CVE— la describe así: «Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High)»

Desarmemos esa frase, porque cada pedazo importa:

• Type confusion (CWE-843): el programa guarda un dato pensando que es de un tipo y después lo lee como si fuera de otro. Es como abrir un sobre esperando una carta y encontrar una llave — y usarla igual.
• En V8: el motor que ejecuta el JavaScript de todas las páginas que visitás. No es un rincón exótico del navegador; es el corazón.
• Remote attacker: no necesita tu PC, le alcanza con que abras algo.
• Via a crafted HTML page: el vehículo es una página web preparada. No hace falta que descargues ni instales nada.
• Inside the sandbox: y acá está el matiz que casi nadie cuenta. La ejecución de código queda adentro del sandbox de V8, el cajón blindado del propio motor de JavaScript. Ojo con el nombre, porque en esta historia hay dos encierros, uno adentro del otro: el de V8 y, más afuera, el del proceso aislado con el que Chrome contiene lo que ejecuta. Existen justamente para eso: para que un bug del motor no se convierta solo en control de tu máquina.

Que sea «adentro del sandbox» no lo vuelve inofensivo — significa que, tal como está documentado, esta falla sola no alcanza para tomarte la PC entera: haría falta encadenarla con al menos una segunda que rompa ese encierro. Es la diferencia entre que te entren al garage y que te entren a la casa. Igual conviene cerrar el garage. Eso dejó de ser una hipótesis: los informes del 9 de septiembre documentan la cadena completa —dos fallas de V8 más una tercera en el núcleo de Windows— y la contamos en la actualización del 10 de septiembre.

La puntuación CVSS que le asignó el enriquecimiento de CISA en el mismo registro es 8,8 sobre 10 (severidad alta), con un detalle relevante: el vector marca UI:R, o sea que requiere interacción del usuario. Alguien tiene que abrir la página. No se propaga solo.

Los 12 parches, uno por uno

El resto del lote no trae exploits conocidos, pero vale mirarlo porque muestra algo interesante: de las 12 fallas, ocho las encontró Google internamente y cuatro llegaron de afuera, firmadas por tres investigadores (uno de ellos, Salvatore Gulizia, reportó dos). La que está siendo explotada es una de esas cuatro.

Un dato que da para chiste amargo: el reporte de la única falla que hoy se está explotando figura con una recompensa de US$ 1.000. Es lo que el programa de recompensas de Chrome consignó en el propio anuncio; lo que ese mismo bug vale en el mercado gris es otra conversación, y no la tenemos documentada.

Qué cambió en los registros oficiales

El aviso original de Google ya advertía que existía explotación. El 4 de septiembre CISA añadió el CVE a su catálogo KEV y su enriquecimiento pasó a marcar explotación activa. Ese desfase entre documentos no era un motivo para demorar el parche. Al publicar esta nota no se conocía la fecha de inicio de los ataques; los informes del 9 de septiembre la fijaron, y la contamos en la actualización del 10 de septiembre.

Edge, Brave, Opera y Vivaldi: mismo motor, distinto calendario

V8 no es propiedad exclusiva de Chrome: es el motor de JavaScript de Chromium, el proyecto de código abierto sobre el que están construidos también Microsoft Edge, Brave, Opera y Vivaldi. La pregunta obvia es si todos quedan expuestos y todos se arreglan juntos.

Cada navegador integra Chromium en su propio calendario. Consultá la versión instalada y el aviso de su fabricante; no traslades automáticamente una versión de Chrome a un producto distinto.

Si usás uno de esos navegadores, el movimiento correcto es revisar el canal de avisos de ese fabricante y actualizar apenas publique. Y sí, ya cubrimos antes lo rápido que se mueve el terreno de los navegadores: hace unos días contamos cómo Edge 152 empezó a cortar por su cuenta las notificaciones de los sitios de estafa.

Estado de otros navegadores al 5 de septiembre

Las fuentes actuales permiten distinguir los navegadores que nombran expresamente el CVE de aquellos donde la inclusión del arreglo se infiere de su versión de Chromium. Que el parche esté disponible no demuestra que esté instalado en tu equipo.

Corrección: las notas actuales de Edge identifican CVE-2026-85046 y el arreglo en 152.0.4191.62. Retiramos la afirmación de que el aviso no existía cuando publicamos: no tenemos una captura suficiente para sostenerla.

Cómo quedó cada navegador con motor Chromium

La nota original decía que no podíamos afirmar el estado de cada uno sin su aviso. Ya están los avisos:

Edge y Opera son los dos que nombran el zero-day de Chrome con todas las letras, y el más explícito es el de Microsoft: «The Chromium team reported that CVE-2026-85046 has an exploit in the wild, and this update contains a fix for it», contra el «This update includes an important security fix addressing CVE-2026-85046» de Opera. Al 5 de septiembre, Brave y Vivaldi no nombraban la falla, y ahí convenía separar lo que estaba medido de lo que estaba deducido. Medido: Brave corre la 152.0.7977.83 y Vivaldi la 152.0.7977.112. Deducido: que las dos traen el arreglo. En el caso de Brave la deducción es corta —la .83 es una de las dos builds que Google nombró como parcheadas, y el propio aviso de Google publica el registro de cambios 152.0.7977.76..152.0.7977.83—; en el de Vivaldi es un poco más larga, porque la .112 viene después de la .82 en la misma rama y las ramas de Chromium arrastran lo anterior. Ninguno de los dos lo afirmaba con esas palabras, y nosotros tampoco. Eso cambió para Vivaldi el 7 de septiembre: lo contamos en la actualización de más abajo.

Para Brave, la tabla enlaza al canal oficial de releases. Si una página de novedades no coincide con el actualizador, comprobá el canal y la versión instalada antes de dar por aplicada la corrección.

Y una aclaración que vale para los cuatro: «cubierto» quiere decir que el fabricante ya publicó la versión con el arreglo, no que vos la tengas. Vale lo mismo que para Chrome — hasta que no cerrás y volvés a abrir el navegador, seguís corriendo el código viejo.

Actualización del 8 de septiembre: Vivaldi también nombra el CVE-2026-85046

Vivaldi editó su propio anuncio y ahora sí identifica la falla. El 5 de septiembre, cuando escribimos el bloque anterior, la actualización menor de Vivaldi 8.2 solo decía que subía a Chromium 152.0.7977.112, sin mencionar el CVE. Esa página se modificó el 7 de septiembre a las 10:36 GMT y su registro de cambios pasó a decir, con todas las letras: «[Chromium] Update to 152.0.7977.112 (includes a fix for CVE-2026-85046 [Type confusion in V8])».

Es un cambio de clase de evidencia, no de versión: la build es la misma que ya venía corriendo. Lo que cambió es que en Vivaldi el arreglo dejó de estar deducido por nosotros y pasó a estar declarado por el fabricante. Con eso son tres los navegadores con motor Chromium que nombran este zero-day expresamente: Edge, Opera y Vivaldi.

Queda Brave como el único de los cuatro donde la cobertura del arreglo sigue siendo una deducción a partir del número de build y no una afirmación del fabricante. Si publica su aviso, lo agregamos acá.

Y una moraleja para el que administra equipos: los avisos de seguridad se editan después de publicados. Si armaste tu inventario de parches el viernes, el changelog del lunes puede no ser el mismo. Conviene volver a mirar la página del fabricante antes de dar una campaña por cerrada, no solo el número de versión.

Actualización del 9 de septiembre: Chrome 153 tapa un segundo zero-day de V8

La rama 152 dejó de ser el destino. El 8 de septiembre Google promovió Chrome 153 al canal estable para Windows, Mac y Linux —153.0.8010.36 en Linux, 153.0.8010.36 o .37 en Windows y Mac— con una cifra que no es de todos los días: «This update includes 230 security fixes». Y otra vez el dato que importa está escondido en la última línea de la sección de seguridad: «Google is aware that an exploit for CVE-2026-87491 exists in the wild».

Es otro zero-day de Chrome explotado en la práctica, en el mismo motor V8, cinco días después del anterior — y, según el conteo de BleepingComputer, el séptimo que Google parchea en lo que va de 2026. No es una reaparición del CVE-2026-85046: aquel sigue tapado desde la 152.0.7977.82. Es una falla distinta, con su propio número, su propio tipo y su propio parche.

Dos escalas y un mismo CVE: por qué vas a leer «Medium» y «alta» el mismo día

El registro oficial del CVE-2026-87491 —redactado por Google, que numera sus propios CVE— lo describe así: «Out of bounds write in V8 in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium)». El mismo campo, en la ficha del zero-day anterior, dice «High».

Y en el mismo documento conviven dos calificaciones distintas, que es lo que explica que vayas a leer cosas opuestas el mismo día. Además del «Medium» de la escala interna de Chromium, el registro trae el enriquecimiento de CISA con una puntuación CVSS de 8,8 sobre 10, severidad alta (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). Es exactamente el mismo par de números que la ficha del CVE-2026-85046. Así que cuando BleepingComputer lo describe como «high-severity», no se contradice con Google: está citando la otra escala del mismo registro. Las dos son correctas y miden cosas distintas.

Lo que no cambia con ninguna de las dos es lo único que te toca decidir: hay explotación declarada por Google, y eso es un dato aparte de la severidad. Una etiqueta «Medium» no es permiso para postergar el reinicio. Por qué Chromium la clasificó por debajo del zero-day anterior —que tiene la descripción prácticamente idéntica, ejecución de código adentro del sandbox— no está explicado en ningún documento público, así que no lo vamos a inventar.

Por qué al 9 de septiembre todavía no figuraba en el catálogo del gobierno de EE. UU.

El catálogo KEV de CISA —el listado de vulnerabilidades con explotación confirmada— no incluye al CVE-2026-87491. Medido el 9 de septiembre a las 11:20 GMT: la versión vigente es la 2026.09.08, publicada a las 18:00 GMT, con 1.699 entradas, y la más reciente de Chromium sigue siendo el CVE-2026-85046, sumado el 4 de septiembre.

Pero CISA sí lo miró, y conviene leer bien qué anotó. Su enriquecimiento dentro del registro del CVE, fechado el 9 de septiembre a las 10:29 GMT, marca Exploitation: none — el mismo campo que en el zero-day anterior pasó a active el 4 de septiembre. Y el catálogo KEV vigente es anterior al anuncio de Google (18:00 GMT contra 21:24 GMT), así que todavía no hubo una publicación del catálogo donde el CVE pudiera entrar.

Ninguna de las dos cosas contradice a Google, que es quien declara el exploit y quien numera el CVE: el triage de CISA es automático y va por detrás. No uses la ausencia en el KEV como señal de que la falla es menos seria, y no esperes a que aparezca ahí para actualizar. El catálogo se republica en días hábiles por la tarde (GMT); si CISA publica hoy su actualización, es probable que entre.

Y entró, ese mismo día. Lo que leíste arriba retrata el 9 de septiembre a las 11:20 GMT; esa misma tarde CISA publicó el catálogo con el CVE adentro. Los números están en la actualización del 10 de septiembre.

¿Y en el celular? El anuncio de Chrome para Android del 8 de septiembre, en el mismo blog de Chrome Releases, informa la versión 153.0.8010.36 y deja escrito el criterio general: «Android releases contain the same security fixes as their corresponding Desktop releases (Windows & Mac: 153.0.8010.36/.37 Linux: 153.0.8010.36) unless otherwise noted» — o sea que Android trae los mismos parches que escritorio salvo aviso en contrario, y acá no hay tal aviso. Se actualiza desde Google Play.

Qué hacer, que es lo mismo de siempre y sigue siendo gratis: Ayuda → Información de Google Chrome, dejá que baje lo que tenga que bajar y reiniciá el navegador. Si administrás equipos, esta vez el salto es de rama —de la 152 a la 153—, así que revisá que el despliegue no esté frenado por una política de versión fija antes de dar la vuelta por terminada.

Actualización del 10 de septiembre: quién lo explotó y por qué el parche tardó casi cuatro semanas

El 9 de septiembre, dos empresas de seguridad publicaron con horas de diferencia los informes que responden lo que Google se había guardado. Proofpoint (15:00 GMT) y Volexity (17:36 GMT) investigaron por separado y llegaron a lo mismo: las dos fallas de Chrome que venimos contando no se usaron sueltas, sino encadenadas con una tercera de Windows, dentro de un kit al que Proofpoint bautizó BlueMoon.

El arreglo estuvo casi cuatro semanas a la vista, antes de llegar a tu navegador

Este es el dato que más incomoda, y no es una interpretación nuestra. Chrome se construye sobre Chromium, que es código abierto: cuando alguien corrige un bug, la corrección se publica en el repositorio antes de que exista una versión de Chrome que la traiga. Proofpoint lo mide con fechas:

«The change containing the fix for CVE-2026-85046 was committed on 7 August 2026 but was not rolled into the general stable Chromium build until 3 September 2026. This opened a nearly four-week window during which the diff was publicly available without a released patch.»

Proofpoint, informe del 9 de septiembre de 2026 (consultado el 10)

Traducido: el parche se subió al repositorio el 7 de agosto y recién llegó a la versión estable el 3 de septiembre —el día que publicamos esta nota—. En el medio hubo casi cuatro semanas en las que cualquiera que mirara el repositorio veía exactamente qué se había arreglado, mientras los usuarios seguían sin el arreglo. Volexity lo explica en términos aún más crudos:

«The vulnerability was known and fixed upstream, making it an N-day at the Chromium source level, but there was no patch release for Google Chrome users. Therefore, the exploit was effectively a zero-day against Google Chrome.»

Volexity, informe del 9 de septiembre de 2026 (consultado el 10)

El origen ya estaba en esta nota desde el 3 de septiembre: la tabla de los 12 parches acredita el hallazgo a Salvatore Gulizia («Serotav»), el 4 de agosto de 2026, y Volexity lo confirma por su lado al señalar que la falla llegó a Chromium por reporte de un investigador privado ese mismo día. Lo que no sabíamos era el resto de la línea de tiempo. Ahora se ve completa: el problema no fue que nadie viera la falla, sino el tiempo entre verla, arreglarla y repartir el arreglo. Ese hueco tiene nombre propio en la industria —patch gap— y es el que da título al informe de Volexity.

La cadena de tres, eslabón por eslabón

Más arriba en esta nota escribimos que la falla de V8, sola, no alcanzaba para tomar el control del equipo: que haría falta encadenarla con otra que rompiera el sandbox. Los informes documentan que fue exactamente así, con un eslabón más de los previstos:

El tercer eslabón no es de Chrome: es de Windows, y ya lo contamos acá cuando salió, en el Patch Tuesday de septiembre, donde figuraba como uno de los dos zero-days del mes. La ficha de Microsoft lo confirma con el campo que importa —exploited: Yes— y su propia sección de preguntas describe el prerrequisito casi como si narrara este ataque: «An attacker who can execute code in a low-privilege AppContainer could exploit this vulnerability». Un AppContainer de bajo privilegio es, precisamente, el cajón donde Chrome mete lo que ejecuta.

Un matiz que conviene no perder, y conviene leerlo completo: ese tercer eslabón no dispara contra cualquier equipo. Proofpoint publica la lista exacta de versiones de Windows que el exploit acepta, y Volexity la midió por su cuenta y coincide: Windows 10 1809 a 22H2, Windows Server 2019, Windows Server 2022 y Windows 11 21H2 —la versión inicial del 11, build 22000—. Volexity agrega el detalle que define el borde: «All build versions above 22000 are rejected», o sea que el exploit descarta solo todo lo que esté por encima de esa build. Proofpoint anota además que el ataque apuntaba a «older Windows builds», con una DLL cuya fecha de compilación es de 2025.

Traducido a la pregunta que te estás haciendo: si tenés Windows 11 al día, esa tercera pata no te alcanza; si estás en la 21H2 original, en Windows 10 o en un Server de esa franja, sí. Y ojo con la conclusión fácil: los dos primeros eslabones son del navegador y no distinguen versión de Windows. Que la cadena completa no cierre no significa que no te entren al navegador.

Quién lo usó y contra quién

Volexity detectó la campaña el 1 de septiembre, contra clientes suyos en organizaciones no gubernamentales. El correo traía un enlace a la web —real— de una universidad estadounidense: los atacantes abusaban de una falla de cross-site scripting reflejado en ese sitio para rebotar a la víctima hacia su propia infraestructura. Conviene decirlo con el sujeto en su lugar: la universidad no participó de nada, le usaron el sitio. Volexity atribuye la operación a un actor chino que sigue como UTA0560, y detectó al mismo tiempo a otro, JungleBamboo (conocido también como APT31, Violet Typhoon o TA412), usando la misma cadena contra otros objetivos. Cada uno dejó su propio malware: UTA0560, un backdoor que Volexity llama GRIMWEDGE; JungleBamboo, un cargador que instalaba una extensión de navegador dedicada a robar credenciales.

Proofpoint, que trabajó por separado, fecha el primer uso todavía antes —28 de agosto— y lo atribuye a TA412, que es el mismo grupo que Volexity llama JungleBamboo. Ahí no termina: el informe documenta cuatro actores distintos adoptando el kit en cuestión de días, con blancos que van de ONG, mineras y firmas de trading de materias primas en Estados Unidos al sector aeroespacial estadounidense, una manufacturera vietnamita y objetivos en Singapur e Indonesia. Uno de ellos desplegó ShadowPad, un backdoor conocido desde hace años en operaciones vinculadas a China.

Y hay un detalle que le toca de cerca a quien no usa Chrome: según Proofpoint, el instalador de esa extensión maliciosa «enumerates installed Chromium-family browsers, specifically Google Chrome, Microsoft Edge, Brave, and Vivaldi» —busca cuál de los cuatro tenés instalado y cierra el navegador para poder tocarle las preferencias—. Es decir que la parte del robo de credenciales no era exclusiva de Chrome, aunque la puerta de entrada sí fuera su motor.

Por qué esto te importa aunque no seas una ONG

La respuesta corta: porque, según la propia Proofpoint, esto no se queda entre espías.

«Proofpoint assesses that BlueMoon will likely proliferate further and be adopted by both espionage-motivated and financially motivated threat actors.»

Proofpoint, informe del 9 de septiembre de 2026 (consultado el 10)

«Motivados financieramente» es el eufemismo de la industria para los que no quieren tus secretos de Estado sino tu home banking. Proofpoint agrega que el patrón de fondo —desarrollar exploits rápido aprovechando el patch gap del código abierto— probablemente se repita más allá de BlueMoon. Y aclara algo que también hay que decir: parte del uso del kit todavía no está atribuido, así que tampoco se puede afirmar que sea exclusivo de actores alineados con China.

Ahora, la parte que juega en contra del alarmismo, y que también es de Proofpoint: atar una falla del navegador —que sí afectaba a las versiones estables— a una de Windows que solo corre en builds viejos «substantially narrows the pool of viable targets and reduces the chain’s overall probability of success». Es decir: achica bastante el universo de víctimas posibles y baja la probabilidad de que la cadena funcione. Proofpoint lo lee, junto con la adopción apurada por varios grupos a la vez, como señal de un despliegue hecho a las apuradas. Traducido para vos: esto no fue una plaga masiva, fue una operación quirúrgica contra blancos elegidos. La razón para actualizar no es el pánico, es que la próxima vez el eslabón viejo puede no ser necesario.

De ahí sale la moraleja práctica, que es la misma de siempre pero ahora con números detrás: el tiempo que tardás en reiniciar el navegador es tiempo de ventaja para el que ya sabe cómo entrar. No porque haya que vivir con miedo, sino porque cerrar esa ventana cuesta dos clics y treinta segundos.

El papeleo se puso al día

El catálogo KEV de CISA, que el 9 de septiembre a la mañana todavía no incluía al CVE-2026-87491, lo incorporó esa misma tarde: versión 2026.09.09, difundida a las 19:00 GMT, con 1.703 entradas y plazo de corrección para organismos federales de EE. UU. el 23 de septiembre. El otro CVE de la cadena, el de Windows, había entrado el 8 de septiembre, con plazo al 22.

Y el registro del CVE-2026-87491 también se movió: el enriquecimiento de CISA que el 9 de septiembre marcaba Exploitation: none pasó a decir active. La modificación quedó sellada el 10 de septiembre a las 03:55 GMT. Un detalle para quien mire la ficha y se confunda con las fechas: el 21 de septiembre CISA volvió a editar su parte del registro, y esa pasó a ser su fecha de última actualización. En esa edición agregó la marca de su catálogo KEV con la fecha de alta, el 9 de septiembre —el enlace al catálogo ya estaba desde el 10—, y el campo timestamp de su evaluación, que hasta entonces decía «9 de septiembre a las 00:00 GMT», pasó a mostrar las 03:55 GMT del 10. La evaluación no cambió: al 21 de septiembre seguía en active. Poco más de un minuto después, CISA hizo la misma pasada sobre el registro del CVE-2026-85046, que por eso también pasó a figurar como actualizado el 21.

Qué hacer, que no cambió: Ayuda → Información de Google Chrome, y reiniciar. Si administrás equipos con Windows 10 o Server, esta cadena es un argumento concreto para no dejar el reinicio del navegador para el viernes.

¿Y esto qué significa para vos?

Si sos usuario particular, la tarea es una sola y no cuesta plata: abrí Chrome, forzá el chequeo y reiniciá. No hay configuración que tocar, no hay que desinstalar nada y no existe un «truco» alternativo — el parche es el arreglo.

Si administrás equipos: comprobá la versión y los reinicios pendientes en todas las instalaciones, incluidos puestos compartidos. Programá el reinicio necesario tras desplegar esta actualización; no esperes a una rutina semanal para aplicar un parche con explotación conocida.

Desconfiá de páginas o ventanas que te pidan descargar una supuesta actualización desde un enlace inesperado. Hacé el chequeo desde Ayuda → Información de Google Chrome o desde el sistema de administración de tu empresa. Si necesitás reinstalar, usá el sitio oficial de Google.

Antes de pensar en comprar nada: Chrome ya trae Navegación Segura activada de fábrica, y esa función bloquea los sitios maliciosos ya reportados sin que gastes un peso. Esa es tu primera capa gratis y conviene no desactivarla. Contra ese segundo problema —la página trucha, no la falla de V8— un antivirus con protección web suma otra capa y bloquea sitios ya reportados antes de que el navegador los cargue. Que quede claro para no vender humo: eso no reemplaza al parche, que es lo único que cierra esta vulnerabilidad. Es la tercera puerta, no la primera. Y el límite de esa capa quedó a la vista en esta misma historia: en la campaña que documentó Volexity el señuelo era la web real de una universidad, no un sitio ya fichado como malicioso — así que un filtro de reputación no tenía nada que bloquear. Por eso el orden no se discute: parche primero.

Preguntas frecuentes sobre el CVE-2026-85046 y el parche de V8

¿Cómo sé si mi Chrome ya está parcheado?

Abrí Ayuda → Información de Google Chrome, dejá que busque actualizaciones y reiniciá cuando lo pida. Google identifica el arreglo del CVE-2026-85046 en la rama estable 152 desde 152.0.7977.82/.83 en Windows y Mac, y .82 en Linux. Desde el 8 de septiembre eso ya no alcanza: la rama estable es la 153 y tapa además el CVE-2026-87491, también explotado, desde 153.0.8010.36 (y .37 en Windows y Mac). Para otra rama o un equipo administrado, seguí el canal oficial y consultá su aviso; no alcanza con comparar el número mayor.

¿Me pueden hackear solo por entrar a una página?

Según el registro oficial, el ataque llega por una página HTML preparada y requiere que alguien la abra. La ejecución de código queda dentro del sandbox de Chrome, así que esta falla por sí sola no entrega el control del equipo: haría falta encadenarla con otra vulnerabilidad. Y es lo que pasó: los informes del 9 de septiembre documentan que se usó encadenada con el CVE-2026-87491 —para escapar del sandbox— y con una falla del núcleo de Windows, el CVE-2026-85880. La cadena completa está en la actualización del 10 de septiembre. Es un motivo más para reiniciar el navegador hoy, no la semana que viene.

¿Afecta también a Edge, Brave u Opera?

Comparten Chromium, pero sus avisos son distintos. Al 8 de septiembre, Edge, Opera y Vivaldi confirman el CVE-2026-85046 expresamente —Vivaldi lo agregó a su registro de cambios el 7 de septiembre—. En Brave, la inclusión del arreglo se infiere de la compilación de Chromium publicada; su aviso no lo nombra. Las tablas separan esas dos clases de evidencia. Para el CVE-2026-87491, anunciado el 8 de septiembre, ya hay dos fabricantes que lo nombran: Vivaldi, en su actualización menor (2) de la 8.2, del 11 de septiembre, que pasa a Chromium 152.0.7977.124 ESR con los arreglos de seguridad de la 153; y Microsoft, en sus notas de seguridad de Edge, que lo dan por corregido en la Stable 152.0.4191.66. Ojo con un detalle de esas notas: la entrada que lo nombra lleva fecha del 4 de septiembre, anterior al anuncio de Google, así que no sirve para saber desde cuándo Edge lo tiene tapado. Cuando lo nombren los demás, lo agregamos acá con la misma distinción entre lo declarado y lo deducido.

¿Sirve de algo tener antivirus si la falla está en el navegador?

No cierra la vulnerabilidad: eso lo hace únicamente la actualización de Chrome. Y la primera capa gratuita ya la tenés, que es la Navegación Segura del propio navegador. Un antivirus con protección web suma una capa más sobre sitios ya reportados, pero nunca reemplaza al parche.

🛒 Te puede servir

Bitdefender Antivirus Plus — 1 PC, 12 mesesProtección web para la edición compatible indicada en la ficha. Es una capa adicional; no corrige la vulnerabilidad del navegador.Ver precio de hoy → ESET Internet Security — 1 dispositivo, 12 mesesHerramientas de protección para el dispositivo compatible indicado en la ficha. No reemplazan actualizar Chrome.Ver precio de hoy →

¿Y vos qué opinás? Dejalo en los comentarios ⬇️
Ver opciones de protección web →

Revisión editorial · 5 de septiembre de 2026: Adelantamos los pasos de actualización, retiramos la cronología visual desactualizada y distinguimos confirmaciones de fabricante de inferencias por versión. Corregimos la afirmación histórica sobre Edge. · Actualización del 8 de septiembre de 2026: Vivaldi pasó a nombrar el CVE-2026-85046 en su registro de cambios. · Actualización del 9 de septiembre de 2026: Chrome 153 llegó al canal estable con 230 parches y un segundo zero-day explotado, el CVE-2026-87491; fechamos la tabla de versiones del 3 de septiembre y sumamos la puntuación CVSS que faltaba. · Actualización del 10 de septiembre de 2026: Proofpoint y Volexity publicaron los informes que identifican quién explotó las dos fallas de Chrome, contra quién y desde cuándo, encadenadas con el CVE-2026-85880 de Windows; incorporamos el patch gap de casi cuatro semanas entre el arreglo y su llegada a Chrome. Corregimos el estado del catálogo KEV, que pasó a incluir el CVE-2026-87491 el 9 de septiembre, y el enriquecimiento de CISA, que pasó a active.