Hay una diferencia práctica entre comprometer un servidor y comprometer aquello que controla todos los servidores. VMware vCenter es la segunda categoría: es el panel único que administra la flota entera de hipervisores ESXi, guarda credenciales de dominio y se comunica con cada máquina virtual del ambiente. El 29 de julio de 2026 Broadcom publicó el advisory VMSA-2026-0006 con dos fallas críticas en él. Cinco días después ya existía explotación activa a escala global.
Las dos fallas críticas del VMSA-2026-0006
La CVE-2026-59310 es una vulnerabilidad de directory traversal en el servidor de syslog de vCenter, con CVSS 3.1 de 9,8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) y clasificada como CWE-22. Un atacante con acceso de red a vCenter, sin ninguna credencial y sin interacción de usuario, logra ejecutar código arbitrario. Su compañera es la CVE-2026-59309, también 9,8 y con el mismo vector, un bypass de autenticación en el VMware Directory Service (vmdir) clasificado como CWE-303, implementación incorrecta de algoritmo de autenticación. Ambas fueron publicadas en la NVD el 30 de julio de 2026.
- VMware vCenter 9.1.x anterior a 9.1.0.0300, 9.0.x anterior a 9.0.2.0100 y 8.0 anterior a U3k
- VMware Cloud Foundation 9.1.x, 9.0.x y 5.x
- VMware vSphere Foundation 9.1.x y 9.0.x
- VMware Telco Cloud Infrastructure 3.0
- VMware Telco Cloud Platform 5.1.x, 5.0.x, 4.x y 3.0
La corrección está en VMware Cloud Foundation y vSphere Foundation 9.1.0.0300, en 9.0.2.0100 y en vCenter Server 8.0 U3k. No hay workaround oficial que reemplace al parche, lo que significa que la única respuesta real es actualizar.
Cómo se explota la falla
El componente vulnerable es el servicio de syslog del vCenter Server Appliance. Un servidor de logs es un blanco clásico y un poco irónico: su función es justamente recibir datos no confiables de fuentes externas y escribir esos datos en disco. Cuando la ruta del archivo de destino se arma a partir de contenido controlado por el atacante sin normalización, la secuencia de traversal escapa del directorio de logs y el servicio pasa a escribir donde el atacante quiera. Y un proceso que escribe en cualquier ruta del sistema, corriendo con privilegio alto, es ejecución de código a un paso indirecto de distancia.
# Concepto de la falla (CWE-22), no un exploit funcional.
# El destino del log se arma a partir de entrada externa:
/var/log/vmware/syslog/<valor_controlado_por_el_atacante>.log
# Sin normalizacion de la ruta, la secuencia de traversal escapa del directorio:
../../../../etc/cron.d/update
# Resultado: el cuerpo del mensaje de syslog se convierte en el contenido de un
# archivo en /etc/cron.d, y el propio cron del appliance lo ejecuta.
# La escritura arbitraria de archivo se vuelve ejecucion de comando, sin exploit de memoria.Vale notar lo que esta cadena no exige. No hay corrupción de memoria, no hay bypass de ASLR, no hay shellcode. Es validación de entrada ausente en una ruta de archivo, la misma clase de falla que existe desde los años 1990, en un producto de infraestructura crítica en 2026. Por eso la revisión de rutas de archivo sigue siendo un ítem obligatorio de checklist en pentest de aplicación.
Qué pasa después del primer comando
La telemetría publicada por QUIRSO, la empresa alemana de respuesta a incidentes que rastreó la campaña, muestra una operación bastante más organizada que un escaneo oportunista. Después del acceso inicial, el atacante descarga el backdoor con curl o wget, instala un implante que abre canal de comando y control por WebSocket, y asegura persistencia por varios caminos redundantes al mismo tiempo.
- Persistencia redundante: entradas de cron, servicios systemd e inyección de clave SSH, además de reverse_ssh, herramienta open source usada para mantener sesión reversa con la infraestructura del atacante
- Escalamiento: configuración de sudo sin contraseña y creación de cuentas administrativas propias en el appliance
- Robo de credenciales: extracción directa de vmdir, el directorio que guarda la identidad de todo el ambiente vSphere
- Movimiento lateral: descubrimiento de los hosts ESXi por la API REST y uso de la propia API de vSphere para operar sobre ellos
- Impacto final: despliegue de ransomware derivado de Babuk en los hosts ESXi, cifrando archivos con la extensión .babyk
Un detalle del análisis de QUIRSO merece atención de quien hace respuesta a incidentes: los investigadores sospechan que el ransomware pudo haber sido una distracción, no el objetivo real. El cifrado es ruidoso por naturaleza, obliga a la víctima a mirar el incidente. Cuando aparece al final de una cadena que ya incluía robo de credenciales de directorio y acceso a la API de virtualización, vale considerar la hipótesis de que la extorsión sirvió para encubrir lo que ya había salido del ambiente.
Cinco días entre el parche y la explotación masiva
QUIRSO detectó los primeros sistemas comprometidos comunicándose con infraestructura de comando y control el 3 de agosto de 2026, cinco días corridos después de la divulgación. La actividad ligada a la CVE-2026-59309 ya aparecía desde el 1 de agosto. En total fueron 361 direcciones IP únicas comprometidas en 47 países, con mayor concentración en Alemania (55), Estados Unidos (41), Turquía (38), Irán (26) y Francia (25). Hasta la publicación de este post ninguna de las dos fallas figuraba en el catálogo Known Exploited Vulnerabilities de CISA, un buen recordatorio de que la ausencia en el KEV no es evidencia de ausencia de explotación.
QUIRSO atribuye la campaña, con confianza moderada, a un actor con nexo chino, con base en artefactos en chino dentro de los scripts del atacante, reuso de investigación y herramientas de origen chino, victimología que excluye a China continental y patrón de actividad compatible con el huso UTC+08:00. La atribución siempre es probabilística y no cambia la respuesta técnica, pero ayuda a calibrar expectativas: un actor estatal con ese nivel de organización no desaparece del ambiente porque el ransomware fue contenido.
Triaje: cómo saber si ya fuiste comprometido
Si tu vCenter quedó expuesto y sin parche en cualquier momento entre el 29 de julio y hoy, aplicar la actualización resuelve la vulnerabilidad pero no deshace un compromiso anterior. La persistencia de esta campaña sobrevive al parche, porque ya no depende de la falla. El triaje mínimo es buscar los mecanismos de persistencia descritos, y debe venir antes de dar el caso por cerrado.
# Triaje en el vCenter Server Appliance (solo lectura, no altera nada).
# 1. Version instalada, para confirmar si esta corregido
vpxd -v
# 2. Tareas programadas sospechosas (el vector de persistencia mas directo)
ls -la /etc/cron.d/ /etc/cron.daily/
crontab -l
# 3. Servicios systemd creados o modificados recientemente
ls -lat /etc/systemd/system/ | head -20
# 4. Claves SSH inyectadas en cualquier cuenta
find / -name authorized_keys -type f -exec ls -la {} \; 2>/dev/null
# 5. Reglas de sudo sin contrasena agregadas
grep -rn NOPASSWD /etc/sudoers /etc/sudoers.d/ 2>/dev/null
# 6. Cuentas locales creadas despues de la fecha del advisory
ls -la /home/- Aplica el parche primero, pero trata parche y triaje como dos tareas separadas
- Saca vCenter de la exposición directa a internet, nunca debería ser alcanzable fuera de la red de administración
- Rota las credenciales de vmdir y las cuentas de servicio de vSphere si hay cualquier indicio de compromiso
- Revisa las cuentas administrativas del appliance y de los hosts ESXi buscando creación reciente
- Verifica que los backups de los hosts ESXi estén fuera del alcance de quien administra vCenter
Por qué la capa de virtualización merece alcance propio
En la mayoría de los alcances de pentest que recibimos, la capa de virtualización entra como infraestructura de apoyo, cuando entra. El foco va a la aplicación expuesta, a la API, al perímetro. Pero vCenter concentra tres cosas al mismo tiempo: identidad (vía vmdir), control de ejecución (vía API de vSphere) y acceso al disco de cada máquina virtual del ambiente. Comprometer un servidor de aplicación le da al atacante un servidor. Comprometer vCenter le da el data center.
El patrón que se repite en los últimos casos críticos es siempre el mismo: el blanco de mayor valor no es el sistema más visible, es el sistema que administra a los demás. Vale revisar hoy si tu alcance de prueba incluye el panel que controla todo, o si quedó clasificado como red interna y nunca llegó a ser probado.