Zero-day de Chrome bajo explotación activa: el plazo para parchar vence el 18 de septiembre

Google confirmó que un exploit para CVE-2026-85046, una falla en el motor V8 de Chrome, ya circula en la naturaleza. El parche existe desde el 3 de septiembre de 2026, la CISA (la agencia de ciberseguridad de Estados Unidos) lo agregó a su catálogo de vulnerabilidades explotadas al día siguiente, y puso como plazo el 18 de septiembre para que las agencias federales estadounidenses lo apliquen. Ese plazo no es un trámite ajeno: si el exploit ya está activo, cualquier empresa que use Chrome, Edge, Brave, Opera o Vivaldi tiene la misma exposición y el mismo reloj corriendo.

Qué es exactamente la falla

CVE-2026-85046 es un error de confusión de tipos (type confusion) en V8, el motor que ejecuta JavaScript y WebAssembly dentro de Chrome y de todo navegador basado en Chromium. El fallo ocurre cuando el compilador deja que un arreglo con la marca interna PACKED_ELEMENTS reciba en su lugar el mapa PACKED_SMI_ELEMENTS, según describió el investigador que lo reportó. Esa confusión permite lectura y escritura arbitraria en la memoria del proceso, y de ahí a ejecutar código dentro del sandbox del navegador con solo hacer que la víctima cargue una página HTML manipulada, según detalla la base de conocimiento de nflo sobre la falla.

No hace falta que la víctima descargue nada ni acepte un instalador. El vector es cualquier página que ejecute el código malicioso, incluida una legítima que haya sido comprometida sin que el dueño del sitio lo note. Tratar esto como "cuidado con las pestañas raras" describe mal el problema.

Google recibió el reporte el 4 de agosto de 2026, de parte del investigador Salvatore Gulizia, y pagó una recompensa de 1,000 dólares estadounidenses por el hallazgo, de acuerdo con la cobertura de The Hacker News. Es la sexta vulnerabilidad de Chrome explotada activamente que Google parcha en lo que va de 2026, señal de que el motor V8 sigue siendo el blanco preferido para este tipo de ataque.

Los datos duros

• CVE: 2026-85046, con puntaje CVSS de 8.8 sobre 10.
• Versiones que corrigen la falla: Chrome 152.0.7977.82/.83 para Windows y macOS, y 152.0.7977.82 para Linux, liberadas el 3 de septiembre de 2026 en el canal estable.
• Advertencia oficial de Google: la compañía declaró que "está al tanto de que existe un exploit para CVE-2026-85046 en la naturaleza".
• CISA: agregó la falla a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV) el 4 de septiembre de 2026 y fijó como fecha límite el 18 de septiembre para que las agencias civiles federales de Estados Unidos apliquen el parche, según la alerta publicada por CISA.
• Microsoft Edge: publicó el 2 de septiembre de 2026 la versión 152.0.4191.62, que ya corrige la falla, y el 4 de septiembre liberó la 152.0.4191.66 como refuerzo adicional de seguridad de Chromium.
• Brave, Opera y Vivaldi: comparten el mismo motor V8 y necesitan el mismo nivel de corrección equivalente al build 152.0.7977.82 de Chromium, cada uno en el calendario de su propio proveedor, típicamente unos días después del parche de Google.

El dato que se pierde en la mayoría de las coberturas: la versión 152.0.7977.75, liberada antes de este ciclo, no trae la corrección. Si el inventario de tu empresa marca "Chrome actualizado" sin revisar el número exacto de build, puede estar viendo una versión que ya quedó atrás.

Por qué esto no es solo "actualizar Chrome"

El error está en V8, y V8 es el motor compartido de todo navegador basado en Chromium. Cambiar de Chrome a Edge o a Brave pensando que se resuelve el problema no funciona: los tres corren el mismo componente vulnerable. Cada navegador necesita su propio parche, publicado por su propio proveedor, en su propio calendario. Edge ya lo tiene desde el 2 de septiembre; Brave, Opera y Vivaldi lo liberan por separado, y no todos lo hacen el mismo día que Google.

Hay un caso adicional que rara vez se menciona: las aplicaciones construidas sobre Electron empaquetan su propia copia de Chromium, que no se actualiza sola con el sistema operativo. Si tu empresa usa herramientas internas o de terceros hechas en Electron (editores, clientes de chat, paneles de administración empaquetados como aplicación de escritorio), esa copia de Chromium queda expuesta hasta que el fabricante de esa aplicación específica publique su propia versión corregida, y eso puede tardar más que el ciclo de Chrome.

Qué revisar esta semana en tu operación

1. Inventario real, no supuesto. Pregunta a tu equipo de TI o a tu proveedor de soporte qué navegador y qué número de build exacto corre en cada equipo, no solo "si Chrome está actualizado". La diferencia entre 152.0.7977.75 y 152.0.7977.82 es la diferencia entre estar expuesto y no estarlo.
2. Ubica cada navegador Chromium, no solo Chrome. Si en tu empresa hay equipos con Edge, Brave, Opera o Vivaldi instalados (por default de Windows, por preferencia de algún área, o porque vino con el equipo), cada uno necesita verificación independiente.
3. Revisa las aplicaciones basadas en Electron. Pregunta a tus proveedores de software empaquetado si su producto usa Electron y si ya liberaron una versión con el Chromium corregido.
4. Decide entre actualización forzada y opcional. Si tu organización no tiene una política de actualización automática obligatoria para navegadores, este es el caso concreto para justificarla ante dirección: el exploit ya circula, no es un escenario hipotético.
5. Trata el 18 de septiembre como tu propia fecha límite, aunque no seas una agencia federal estadounidense. CISA fija ese plazo para su propio universo de agencias, pero el criterio detrás (exploit activo, parche disponible, sin razón para esperar) aplica igual a cualquier empresa.

Dónde esto no aplica, o donde la respuesta obvia falla

Si tu empresa ya tiene actualización automática forzada de navegadores en todos los equipos, y el navegador se reinicia solo para aplicar el update sin depender de que el usuario lo acepte, este incidente probablemente ya está resuelto para ti sin que hicieras nada especial esta semana. No hace falta un proyecto nuevo para un caso donde el proceso ya funciona.

Tampoco es correcto tratar esto como un problema exclusivo de equipos con acceso a internet sin restricciones. Una intranet o un portal interno también corre en el navegador, y si ese navegador está desactualizado, el vector funciona igual dentro de la red corporativa.

Y si la respuesta de tu equipo es "vamos a migrar a Firefox para evitar esto", vale la pena precisar que resuelve este CVE específico porque Firefox usa un motor distinto (SpiderMonkey), pero no resuelve el problema de fondo: la próxima falla de este tipo puede aparecer en cualquier motor, y la pregunta real es si tu empresa tiene un proceso de gestión de parches para endpoints o si depende de que cada usuario decida cuándo actualizar. Ese proceso es independiente del navegador que elijas.

Si tu empresa no tiene hoy un inventario de qué corre en cada equipo ni un mecanismo para forzar actualizaciones de software crítico, construimos la plataforma que automatiza ese seguimiento.

Vale la pena preguntarse, más allá de este parche puntual, quién en tu organización tiene hoy la responsabilidad explícita de saber qué versión de navegador corre en cada máquina, y qué pasa si esa persona está de vacaciones cuando aparece el siguiente zero-day. Casos como el reciente de los mismos modelos que descubren vulnerabilidades de día cero y ya sirven para atacar y para defender sugieren que el ritmo de aparición de estas fallas no va a bajar.

Fuentes

• Google Releases Chrome Update to Patch Actively Exploited V8 Zero-Day, The Hacker News
• CVE-2026-85046, base de conocimiento de nflo
• CISA Adds One Known Exploited Vulnerability to Catalog, CISA
• Google patches actively exploited Chrome zero-day (CVE-2026-85046), Help Net Security
• Google actualiza Chrome y corrige 12 fallos de seguridad para Windows Mac y Linux, Infobae