El desarrollador ya corrigió la vulnerabilidad, pero el equipo del usuario aún puede seguir siendo vulnerable. Esto ocurre cuando el código fuente corregido aparece en un repositorio público y la versión estable lista del programa aún no ha llegado a los usuarios. Ese intervalo se denomina patch gap.
Después de que se publica la corrección, a veces resulta más fácil para un atacante encontrar el error. En lugar de revisar millones de líneas de código fuente, se puede comparar la versión antigua y la nueva, localizar la sección modificada y entender qué situación peligrosa corregía el desarrollador. Para Chromium el problema es especialmente visible, ya que el código fuente es abierto, y Chrome, Edge y otros navegadores reciben compilaciones finales según sus propios calendarios.
Qué es el patch gap y cómo se encuentra una vulnerabilidad a partir de una corrección
Google define el patch gap como el intervalo entre el momento en que se añade una corrección de seguridad a Chromium y el momento en que esa misma corrección se entrega a los usuarios de la versión estable de Chrome.
El parche en sí no contiene una descripción lista de la posible explotación. Sin embargo, la naturaleza del cambio a menudo ofrece una pista clara. Una nueva comprobación de límites de un array, una verificación adicional de tipos o un cambio en el manejo de memoria hacen que el investigador examine la implementación previa en ese punto concreto.
La cadena es esta: el desarrollador corrige el error → el cambio aparece en Chromium → el investigador compara versiones → reconstruye la causa del parche → examina la compilación antigua → crea un exploit → la actualización estable llega más tarde a los usuarios.
Google considera este escenario como una explotación de una vulnerabilidad ya conocida, es decir, un n-day. Si se intenta ocultar el objetivo del parche, por lo general eso ayuda poco. El riesgo disminuye mucho más cuando los orígenes se corrigen con rapidez y pronto se publica una versión estable protegida.
El patch gap no crea la vulnerabilidad. El error ya existía anteriormente, pero la publicación pública de la corrección puede reducir drásticamente el tiempo necesario para encontrarla y analizarla.
BlueMoon mostró el patch gap en ataques reales
La historia de BlueMoon ilustra bien cómo se manifiesta el patch gap en la práctica. La secuencia fue simple:
7 de agosto la corrección de CVE-2026-85046 apareció en Chromium →
28 de agosto comenzaron ataques confirmados →
3 de septiembre Google lanzó Chrome 152.0.7977.82/.83 corregido →
la actividad de BlueMoon continuó al menos hasta el 8 de septiembre →
9 de septiembre Proofpoint divulgó las campañas.
Al principio BlueMoon empleó al actor vinculado con China TA412, también conocido como APT31 y Violet Typhoon. Después, el mismo conjunto apareció en UNK_LateNight, UNK_DoubleCheck y UNK_QuietRacket. En pocos días una cadena fue utilizada por cuatro clústeres de espionaje.
| Etapa | Vulnerabilidad | Qué sucedió |
|---|---|---|
| 1. Ejecución de código en el navegador | CVE-2026-85046 en V8 | Un error de confusión de tipos. El parche apareció en Chromium el 7 de agosto, pero la versión estable Chrome 152.0.7977.82/.83 recibió la corrección solo el 3 de septiembre. |
| 2. Evasión del sandbox | Escape del sandbox de V8 sin CVE | El exploit permitía salir del sandbox del navegador. Proofpoint aclara que Google no asigna CVE a ese tipo de fallos de V8. CVE-2026-87491 no está relacionado con BlueMoon. |
| 3. Elevación de privilegios | CVE-2026-85880 en Windows | Un fallo en ALPC y WNF elevaba privilegios solo en compilaciones relativamente antiguas de Windows. Microsoft lo solucionó el 8 de septiembre; la descripción se publicó en MSRC. |
La limitación de la tercera etapa a versiones antiguas de Windows y el notable uso del comando curl indicaban prisa. Proofpoint supone que los operadores intentaron usar la última cadena de navegador antes de la instalación masiva de actualizaciones, de modo que la velocidad fue más importante que el sigilo.
Tras un ataque exitoso, TA412 instalaba la extensión GemStone, disfrazada como Google Gemini. Esta robaba datos del navegador, registraba entradas y aceptaba órdenes. El instalador comprobaba Chrome, Edge, Brave y Vivaldi.
BlueMoon muestra el riesgo principal del patch gap: la corrección puede existir ya en el código fuente, pero los ataques reales continúan hasta que los usuarios reciben e instalan la versión protegida.
En qué se diferencia un zero-day de un n-day y qué relación tiene CVE-2026-87491
Zero-day suele denominarse la vulnerabilidad que los atacantes explotan mientras no existe una corrección disponible para los usuarios. N-day suele referirse a la explotación de un error ya divulgado o corregido, cuando parte de los dispositivos siguen ejecutando la versión antigua. No hay un límite universal estricto entre los términos, por eso distintos investigadores pueden describir el mismo caso de forma algo diferente.
CVE-2026-87491 es un ejemplo aparte y no está vinculada a BlueMoon. El fallo de escritura fuera de límites se encontraba en V8. El investigador Jihyeon Jeong del laboratorio Compsec de la Universidad Nacional de Seúl informó a Google sobre él el 6 de agosto a través del programa de recompensas por errores. La corrección entró en Chrome 153, publicado el 8 de septiembre. Google también confirmó la existencia de un exploit para CVE-2026-87491 en ataques reales.
En una semana de septiembre hubo dos ejemplos independientes de un mismo problema. CVE-2026-85046 se usó en BlueMoon antes de la entrega masiva de la corrección en Chrome 152, y la CVE-2026-87491, divulgada por separado, requirió ya Chrome 153. No deben mezclarse las dos historias, aunque ambas muestran lo corto que puede ser el intervalo entre la disponibilidad de información sobre un error y su explotación.
La agencia CISA incluyó ambas vulnerabilidades en el catálogo KEV. Para CVE-2026-85046 las agencias civiles federales de EE. UU. deben mitigar el riesgo antes del 18 de septiembre de 2026; para CVE-2026-87491, antes del 23 de septiembre. Esos plazos ilustran la diferencia entre la aparición de la corrección y la actualización efectiva de todo el parque de dispositivos.
Un parche público ayuda a buscar errores relacionados. Este enfoque se llama búsqueda de variantes. El investigador analiza la causa de una vulnerabilidad y luego revisa otras funciones y componentes en busca de patrones peligrosos similares. El método lo aplican tanto desarrolladores para proteger el producto como atacantes en busca de nuevos puntos de entrada.
Por qué Chromium es especialmente sensible a los retrasos en las actualizaciones
Chromium sirve como base común para varios navegadores. Cuando los desarrolladores corrigen el código fuente de Chromium, el fabricante del producto final aún tiene que incorporar el cambio en su rama, probar la compilación y entregar la actualización a los usuarios.
Durante los primeros ataques de BlueMoon, las versiones estables más recientes de los navegadores afectados aún no incluían las correcciones necesarias. Los cambios publicados en Chromium ya se podían analizar, mientras que las compilaciones de usuario seguían siendo vulnerables. La salida de un Chrome protegido tampoco implica automáticamente que Edge, Brave, Opera, Vivaldi o una aplicación basada en Electron ya hayan recibido una actualización equivalente.
La actualización automática de Chrome tampoco garantiza protección instantánea. La nueva versión puede descargarse en segundo plano, pero el navegador seguirá ejecutando el código antiguo hasta que se reinicie. Además, Google distribuye algunas versiones de forma gradual durante varios días o semanas.
En el equipo, la comprobación se ve así: Menú → Ayuda → Acerca de Google Chrome → esperar a que compruebe las actualizaciones → Reiniciar. Para otro navegador basado en Chromium hay que comprobar la actualización de ese producto concreto.
La frase «el desarrollador lanzó un parche» y la frase «mi navegador está protegido» son eventos diferentes. La protección aparece después de instalar la versión corregida y, cuando el programa lo exige, al reiniciarlo.
Conclusión
El patch gap surge entre la corrección del código fuente y la entrega de la versión protegida al usuario. En un proyecto abierto como Chromium ese intervalo es especialmente peligroso: un parche publicado permite localizar más rápido la sección modificada y reconstruir el principio de funcionamiento del error.
BlueMoon mostró esa carrera en la práctica. La corrección de CVE-2026-85046 estuvo en los orígenes desde el 7 de agosto; Chrome 152.0.7977.82/.83 recibió la protección el 3 de septiembre, pero se observaron ataques varios días más. Los operadores utilizaron una cadena que incluía un escape no numerado del sandbox de V8 y CVE-2026-85880 para versiones antiguas de Windows, sacrificando el sigilo en favor de la velocidad.
Al notificarse una vulnerabilidad en explotación activa conviene comprobar manualmente la versión del navegador, instalar la actualización disponible y reiniciar completamente el programa. Los usuarios de Edge, Brave, Opera, Vivaldi y otros productos basados en Chromium deben guiarse por la publicación de su fabricante, no solo por noticias sobre parches de Chrome.
El material describe vulnerabilidades y métodos de análisis solo con fines educativos. No se debe crear ni emplear exploits contra sistemas ajenos sin el permiso del propietario. Al investigar software, respete la legislación de la Federación de Rusia y pruebe únicamente sus propios sistemas o recursos para los que tenga permiso explícito.
