Un fallo corregido en el código de Chromium seguía abierto en Chrome: así lo aprovechó el espionaje chino

Entre el 1 y el 12 de septiembre, dos equipos, Proofpoint y Volexity, documentaron por separado lo mismo: varios grupos de espionaje presuntamente chinos usando una cadena de exploits contra Google Chrome y Windows cuyo fallo principal ya estaba corregido en el código, aunque no en el navegador. El arreglo de ese fallo existía en el código fuente de Chromium desde principios de agosto. No había llegado a la versión de Chrome que ejecutan los usuarios. En ese desfase cabía un ataque.

El fenómeno tiene nombre entre quienes desarrollan navegadores: patch gap, el hueco entre el momento en que una corrección entra en un repositorio abierto y el momento en que se despliega a los usuarios finales. Lo llamativo esta vez no es el hueco, que se conoce desde hace años, sino quién lo aprovechó, con qué rapidez y con qué ayuda. El resto de este análisis parte de las publicaciones de Proofpoint y Volexity, dos equipos con telemetría independiente que llegaron por separado a la misma actividad.

El hueco que casi nadie estaba mirando

Chromium es de código abierto. Cuando un investigador reporta un fallo y Google lo corrige, el cambio se publica en el árbol público de Chromium antes de que Chrome, Edge, Brave o Vivaldi lo empaqueten en una versión estable y la distribuyan. Ese intervalo puede durar días o semanas. Durante ese tiempo, la corrección es visible para cualquiera que siga el repositorio, mientras los usuarios siguen ejecutando el código vulnerable.

El fallo central de esta campaña, CVE-2026-85046, es una confusión de tipos en V8, el motor de JavaScript y WebAssembly de Chrome. Lo reportó un investigador el 4 de agosto y la corrección entró en el código de Chromium poco después. Google no publicó la actualización estable de Chrome que la incluía hasta el 3 de septiembre, según recoge Help Net Security. Volexity detectó el primer ataque el 1 de septiembre. Para los usuarios de Chrome, el fallo era un zero-day de facto aunque el arreglo llevara semanas a la vista en el código abierto.

Cuatro datos que sostienen el análisis

Dos investigaciones, la misma cadena

Volexity vio dos grupos —UTA0560 y JungleBamboo, este último también conocido como APT31 o Violet Typhoon— explotando la misma cadena desde el 1 de septiembre contra ONG y otros objetivos, con código de exploit idéntico byte a byte pero cargas distintas. Proofpoint, que sigue la misma actividad bajo el nombre de kit BlueMoon, contabilizó cuatro grupos de espionaje, la mayoría con vínculo chino sospechado, adoptándolo entre el 28 de agosto y los primeros días de septiembre. Que dos equipos con telemetría distinta describan la misma cadena da al hallazgo un peso que un solo informe no tendría.

Tres fallos encadenados

La cadena combina tres vulnerabilidades. CVE-2026-85046 da lectura y escritura arbitraria dentro del entorno aislado (sandbox) de V8. Una segunda, CVE-2026-87491, un fallo en WebAssembly, permite escapar de ese aislamiento; Google la corrigió el 8 de septiembre, también según Help Net Security, y era la séptima zero-day de Chrome del año. La tercera, CVE-2026-85880, es una escalada de privilegios en el mecanismo ALPC del núcleo de Windows que lleva de la pestaña del navegador a SYSTEM. Microsoft la parcheó en el Patch Tuesday de septiembre, el mayor de su historia, y fue una de las dos que se explotaban antes del parche.

Un calendario que no cuadra con el desarrollo artesanal

Los dos fallos de Chrome eran zero-day de patch gap. Volexity encontró fechas en el código del exploit que sitúan su desarrollo entre el 27 y el 29 de agosto, pocos días antes de los primeros correos. Una cadena de exploits de navegador completa ha sido históricamente una capacidad rara y cara, reservada a unos pocos actores. Aquí se desarrolló, se desplegó y se compartió entre varios grupos en cuestión de días.

Indicios de que la IA bajó el listón

Proofpoint recuperó artefactos del kit (registro de depuración extenso, comentarios que documentan iteraciones de fallo y arreglo, y una referencia a un fichero de traspaso en markdown del tipo que usan los agentes de IA para pasarse el trabajo entre sesiones) compatibles con un desarrollo asistido por IA, aunque ningún artefacto lo confirma por sí solo. Volexity coincide en que el desarrollador reconstruyó los arreglos a partir del código fuente de Chromium.

Si esa lectura se confirma, encaja con el patrón que describimos cuando la IA empezó a inventar ataques en vez de copiarlos: la IA no aporta una capacidad nueva, acorta el tiempo que separa un arreglo público de un exploit funcional.

Qué ha cambiado respecto a hace un año

Hace un año, el patch gap era un problema teórico que preocupaba sobre todo a los equipos de Chromium. La barrera práctica nunca fue conocer el hueco. Lo difícil era convertir un diff de código fuente en un exploit fiable antes de que la versión estable cerrara la puerta, y esa dificultad es justo la que un modelo de lenguaje recorta.

El resultado se ve en las cifras del año de Chrome: siete zero-day en 2026, dos de ellas en menos de una semana en septiembre. Y se ve en el modo de operación de los atacantes. Su cadena era ruidosa a propósito: el paso final descargaba un ejecutable con un simple comando curl, algo que un EDR con reglas de comportamiento debería detectar sin problema. Priorizaron llegar antes que pasar desapercibidos. Cuando la ventaja de tiempo es el activo, la operación se optimiza para la velocidad, no para el sigilo.

Qué implica para la arquitectura de defensa

La primera consecuencia es incómoda para el discurso habitual de la higiene: "estamos al día con los parches" deja de ser una respuesta completa cuando la corrección pública precede al despliegue. Entre que el arreglo es visible en el código abierto y que llega a tu flota pueden pasar días o semanas en los que estás expuesto sin poder hacer nada por acelerarlo, salvo forzar el reinicio del navegador para que aplique la versión ya publicada.

La segunda es que el navegador es una superficie de ataque de primera categoría, no una aplicación de escritorio más. La cadena no necesitó que la víctima descargara ni abriera un adjunto: bastó con hacer clic en un enlace de un correo de spear-phishing y visitar una página. En dos de los casos, el objetivo final no fue el equipo, sino una extensión de navegador maliciosa disfrazada de asistente de Google Gemini, dedicada a robar credenciales y sesiones. Es el vector que analizamos en extensiones de navegador y GenAI, ahora entregado a través de una cadena de zero-days.

La tercera es de gobierno. Muchas organizaciones tratan la actualización del navegador como algo que el usuario resuelve solo. Estas campañas dependían de que el navegador no se reiniciara para aplicar la versión con el parche. Sin una política que fuerce el reinicio y mida qué versión ejecuta cada equipo, la corrección existe pero no protege.

Qué controles siguen valiendo y cuáles han caducado

Sigue valiendo la gestión de actualizaciones del navegador entendida como control medible, no como acto de fe: forzar el reinicio tras cada versión de seguridad y comprobar la versión desplegada en la flota, sobre todo la de las ramas de Windows más antiguas, que fue donde la escalada del núcleo funcionaba.

La detección por comportamiento también aguanta, y en este caso era eficaz: el árbol de procesos de la cadena por defecto era chrome.exe lanzando cmd.exe, cmd.exe lanzando curl.exe y curl.exe descargando y ejecutando el binario, una secuencia que no debería producirse en un navegador. Es el mismo principio de detección de abuso de binarios legítimos: mirar toda la cadena de ejecución en vez del fichero aislado.

El control de extensiones no ha caducado. Los dos grupos que instalaron una extensión maliciosa tuvieron que manipular el fichero de preferencias seguras de Chrome para saltarse su comprobación de integridad; una política empresarial que restrinja qué extensiones pueden instalarse corta ese paso. Y sirven los indicadores concretos que publican los dos equipos: tareas programadas con nombres que imitan actualizadores (EdgeCore_AutoUpdate, GeForceService), claves en almacenamiento de sesión como v8ctf_exp_attempt, y ejecutables sueltos en %TEMP%. Recoger la telemetría del endpoint y del navegador en el SIEM es lo que convierte esos indicadores en detección.

Lo que ha caducado es la idea de que un CVSS o una fecha de parche describen tu exposición real. La priorización por riesgo real tiene que incorporar el estado de despliegue efectivo, más allá de la disponibilidad del arreglo, junto con la vigilancia del patch gap en el software de código abierto que ejecutas. Es el criterio de urgencia que ya introdujo la BOD 26-04 de CISA: explotación observada por encima de puntuación teórica. Las tres vulnerabilidades entraron en el catálogo KEV entre el 4 y el 9 de septiembre.

Lo que queda abierto

Ni Proofpoint ni Volexity saben con certeza cómo varios grupos distintos obtuvieron la misma cadena casi a la vez. Las hipótesis van desde un proveedor comercial común hasta un intermediario estatal que la distribuyó. Volexity lo valora con confianza baja, y ese es el límite honesto del caso a día de hoy.

Lo que sí queda claro es la dirección. El patch gap del software de código abierto ya no es un tecnicismo: es una ventana de exposición que se puede explotar, y la reconstrucción de arreglos públicos con ayuda de IA la abre más rápido. La métrica que de verdad describe el riesgo son los días que tarda cada parche en llegar a cada equipo desde que el arreglo es público. Pocas organizaciones la miden.

En Hard2bit trabajamos ese tipo de exposición desde la gestión de vulnerabilidades y el threat hunting, donde el dato que importa no es el que figura en el aviso, sino el que se mide en la flota.

Las técnicas, cronologías e indicadores citados proceden de las publicaciones de Proofpoint, Volexity, Google, Microsoft y CISA con la información disponible a 14 de septiembre de 2026, y se describen con fines de detección y defensa. Las atribuciones a grupos son las de los investigadores citados y pueden evolucionar. Ninguna mención implica un fallo de diseño en los productos citados más allá de las vulnerabilidades reconocidas por sus fabricantes. Cada organización debe validar las búsquedas de indicadores en su propio entorno antes de aplicarlas.