CVE-2026-59310: qué revela la campaña contra VMware vCenter

CVE-2026-59310 dejó de ser únicamente un problema urgente de actualización. Broadcom divulgó y corrigió el 29 de julio de 2026 esta vulnerabilidad crítica de traversal de directorios en el servidor Syslog de VMware vCenter, pero los investigadores observaron indicios de explotación desde el 3 de agosto, apenas cinco días después. La campaña alcanzó 361 direcciones IP observadas en 47 países y utilizó reverse SSH para conservar el acceso. Por ello, Shadowserver recomendó considerar totalmente comprometidos los sistemas afectados.

Qué permite CVE-2026-59310

Broadcom y la National Vulnerability Database (NVD) describen CVE-2026-59310 como una vulnerabilidad de traversal de directorios en el servidor Syslog de vCenter. Un atacante con acceso de red al servicio no necesita autenticarse para explotarla y ejecutar código arbitrario en un sistema vCenter vulnerable. La falla tiene una puntuación CVSS de 9,8, dentro de la categoría crítica.

En la práctica, un dispositivo vCenter expuesto puede convertirse en una puerta de entrada para mantener la persistencia y avanzar hacia otros componentes de la infraestructura virtualizada. Algunos informes describen ejecución de código en el contexto de root de la aplicación, aunque las descripciones más autorizadas del proveedor y de la base de datos de vulnerabilidades establecen principalmente el riesgo de ejecución arbitraria de código, sin detallar por completo los privilegios obtenidos en cada intrusión.

Broadcom publicó versiones corregidas, pero no ofreció ninguna medida alternativa. En consecuencia, instalar las actualizaciones indicadas por el proveedor es la única mitigación oficial para los sistemas vulnerables.

La cronología: el parche llegó antes que el ataque

Broadcom divulgó CVE-2026-59310 y publicó los parches el 29 de julio. QUIRSO informó de señales de explotación activa a partir del 3 de agosto, después de lo cual la campaña creció rápidamente.

La secuencia es especialmente relevante para la respuesta a incidentes. Un sistema actualizado después del 3 de agosto no puede darse por limpio solo porque la instalación de la actualización haya terminado correctamente. Las organizaciones deben separar dos tareas: corregir la vulnerabilidad y comprobar si un atacante ya había conseguido acceso.

Una campaña de alcance global

Los investigadores asociaron la actividad con 361 direcciones IP de víctimas observadas en 47 países. Alemania, Estados Unidos, Turquía, Irán y Francia concentraron, según los informes, más de la mitad del conjunto observado.

La cifra debe interpretarse con cautela: una dirección IP no equivale necesariamente a una organización, por lo que “361 víctimas” no demuestra que hubiera 361 empresas o instituciones distintas. Aun así, los datos disponibles apuntan a una campaña amplia contra sistemas vCenter accesibles desde internet o expuestos de otra manera a redes no confiables.

Por qué se sospecha de una conexión con China

QUIRSO evaluó con confianza moderada que la campaña podría tener una conexión con China. Entre los indicios citados figuran artefactos en chino, herramientas y trabajos de investigación reutilizados públicamente, actividad compatible con el horario UTC+08:00 y un conjunto de víctimas que aparentemente excluía la China continental.

Estas señales respaldan una evaluación regional o lingüística, pero no identifican a un grupo estatal chino concreto ni demuestran que exista una dirección gubernamental. La atribución basada en artefactos de malware, patrones horarios y selección de objetivos puede cambiar cuando aparecen nuevas pruebas. La descripción más prudente es, por tanto, “actor sospechoso con conexión china”, no una operación estatal confirmada.

La cadena de intrusión descrita por los investigadores

La campaña parece haber utilizado CVE-2026-59310 para obtener la ejecución inicial y, a continuación, desplegar varias capas de persistencia y acceso:

1. Traversal de directorios: solicitudes especialmente manipuladas al servicio Syslog permitieron salir de la ruta prevista y escribir contenido controlado por el atacante.
2. Persistencia mediante cron: los atacantes habrían creado entradas de cron malformadas para lanzar comandos posteriores de forma programada.
3. Entrega de una puerta trasera: según los informes sobre las intrusiones observadas, curl o wget descargaron una puerta trasera llamada linuxFile, con comunicaciones WebSocket y ofuscación XOR.
4. Reverse SSH: se instalaron herramientas de reverse SSH para crear conexiones salientes hacia infraestructura controlada por los atacantes. Shadowserver indicó que este mecanismo de persistencia apareció en todas las víctimas incluidas en su informe especial.
5. Abuso de credenciales y cuentas: los investigadores informaron de cuentas no autorizadas de administradores de vCenter y ESXi, además del uso indebido de credenciales de VMware Directory Service.
6. Despliegue de ransomware: al menos algunos informes relacionaron la actividad con una variante de ransomware derivada de Babuk que añade la extensión .babyk.

El hallazgo del reverse SSH es especialmente importante. La conclusión operativa de Shadowserver es que los sistemas donde se desplegó este mecanismo deben tratarse como totalmente comprometidos. Eliminar un binario o borrar una tarea de cron, sin reconstruir la confianza en el dispositivo y rotar las credenciales privilegiadas, no constituye una recuperación suficiente.

El ransomware pudo tener una función de ocultación

La actividad asociada a .babyk no describe necesariamente una campaña convencional centrada sobre todo en cifrar grandes volúmenes de datos y exigir un rescate. Los analistas plantearon que el cifrado selectivo de registros de ESXi pudo buscar entorpecer la investigación y ocultar pruebas.

Esta explicación sigue siendo una inferencia, no una declaración confirmada sobre la intención de los atacantes. Aun así, los equipos defensivos deben investigar las dos posibilidades: el impacto del ransomware en las máquinas virtuales y una manipulación deliberada de registros para dificultar la reconstrucción de la intrusión.

Herramientas camufladas en GitHub

Los informes también vincularon la operación con un repositorio de GitHub que presentaba binarios de reverse SSH como una utilidad de Linux para limpiar archivos temporales. Disfrazar una herramienta de persistencia como un programa administrativo o de mantenimiento puede facilitar su distribución y hacerla menos llamativa durante las revisiones rutinarias. La evidencia disponible no demuestra de forma independiente quién operaba el repositorio, por lo que su existencia no debe considerarse una prueba de atribución.

El posible impacto para Broadcom

Las acciones de Broadcom cayeron aproximadamente entre un 5 % y un 6 % el 14 de agosto, cuando los informes sobre la explotación activa de VMware llegaron a los inversores. Un reporte describió un descenso de 417,82 dólares a 392,99 dólares durante la sesión.

Los informes de seguridad fueron uno de los factores de la caída, pero no necesariamente el único. La cobertura contemporánea también mencionó otras preocupaciones, incluida la exposición a deuda relacionada con la inteligencia artificial. Por eso, no es sólido atribuir toda la variación bursátil ni una cantidad exacta de valor de mercado perdido exclusivamente a CVE-2026-59310.

Tampoco hay pruebas suficientes en la información disponible para concluir que la campaña ya haya provocado una caída cuantificable de los ingresos de VMware. Los efectos empresariales inmediatos que sí resultan defendibles son el coste de la remediación para los clientes, el riesgo de interrupciones operativas y la presión reputacional. Cualquier impacto duradero en los ingresos requeriría información financiera adicional o comunicaciones de la compañía.

Qué deben hacer los administradores de vCenter

Actualizar es el primer paso, no el último. Las organizaciones deberían:

1. Instalar de inmediato las versiones corregidas de Broadcom en todas las instancias de vCenter afectadas, dando prioridad a los dispositivos expuestos a internet o accesibles desde redes internas amplias. Broadcom no ofrece ninguna medida alternativa.
2. Dar por comprometidos los sistemas que presenten indicadores sospechosos, como cambios inesperados en cron, rastros de reverse SSH, linuxFile, descargas no explicadas mediante curl o wget, cuentas desconocidas de vCenter o ESXi y actividad anómala de VMware Directory Service.
3. Aislar los dispositivos sospechosos y conservar imágenes de disco, registros y datos volátiles antes de reconstruirlos, siempre que sea viable desde el punto de vista operativo.
4. Rotar las credenciales privilegiadas, incluidas las de vCenter SSO, VMware Directory Service, ESXi o root, API, cuentas de servicio y administradores vinculados. También deben invalidarse las sesiones activas y revisarse las rutas de federación.
5. Reconstruir, en lugar de limitarse a limpiar, los sistemas donde se confirme persistencia. La eliminación de cuentas no autorizadas, tareas de cron, binarios, claves SSH y túneles debe formar parte de un proceso documentado de respuesta a incidentes.
6. Buscar indicios en toda la infraestructura virtual, incluida actividad de .babyk, conexiones salientes inesperadas por SSH o WebSocket, cuentas fraudulentas y señales de manipulación de registros de ESXi.
7. Recuperar datos y telemetría confiables desde copias de seguridad inmutables y verificadas cuando se hayan alterado registros o configuraciones.
8. Reducir la exposición futura limitando el acceso de administración de vCenter a redes segmentadas y vigilando las conexiones salientes desde vCenter y los hosts ESXi.

La conclusión operativa es clara: hay que actualizar todos los sistemas vCenter vulnerables, pero una actualización correcta no equivale a un entorno limpio. La explotación acelerada, la persistencia mediante reverse SSH y el presunto abuso de credenciales obligan a investigar los dispositivos expuestos como posibles compromisos totales.