CVE-2026-59310: vCenter a ransomware ESXi en días

Hay una clase de vulnerabilidad que da miedo no por lo sofisticada, sino por lo simple: un servicio que recibe una ruta de archivo y no la valida. CVE-2026-59310 es exactamente eso —un path traversal en el servidor Syslog de VMware vCenter— y en cuestión de días pasó de un aviso de Broadcom a campañas reales que terminaron cifrando hipervisores ESXi con ransomware. El caso es un recordatorio incómodo de lo cerca que está, en una plataforma de virtualización, "escribir un archivo donde no debería" de "controlo todo tu datacenter".

CVE-2026-59310 es una vulnerabilidad de directory traversal en el Syslog Server de VMware vCenter que permite ejecución remota de código sin autenticación, con privilegios de root. La divulgó Broadcom el 29 de julio de 2026 con severidad crítica (CVSS 9.8). Un atacante con acceso de red escribe archivos arbitrarios en el appliance aprovechando que el servicio no sanitiza la ruta de destino, y desde ahí escala a control total del entorno virtual.

¿Por qué un fallo en el servicio de logs termina en ejecución como root?

CVE-2026-59310: del path traversal en vCenter al ransomware ESXi

Porque el Syslog de vCenter acepta datos con un componente de ruta que debería quedar confinado a su directorio de trabajo, pero no lo valida antes de usarlo. Un atacante manda secuencias tipo ../../ (o sus equivalentes URL-encoded) y escribe contenido en cualquier ubicación donde la cuenta de servicio de vCenter tenga permiso. No hace falta login: el servicio está expuesto y la escritura ocurre con los privilegios del proceso.

El detalle que convierte el "escribir un archivo" en "ejecutar comandos" es dónde se escribe. Según el análisis forense publicado, los atacantes dejaron archivos cron malformados dentro de /etc/cron.d. Cron los recogió y ejecutó como root, sin ningún evento de autenticación asociado. La firma de respuesta a incidentes QUIRSO lo resume así: "No había eventos de autenticación coincidentes, mientras que los comandos corrían como root. Esto respalda con fuerza que los atacantes usaron el path traversal del Syslog para escribir contenido en una ubicación donde cron lo ejecutaría".

Los artefactos dejados no disimulaban nada: cron jobs con nombres como zz-poc59310-syslog.log y zz-poc59310, que citan directamente el identificador del CVE.

¿Qué versiones de vCenter están afectadas y cuáles hay que instalar?

Están afectadas las ramas 9.1, 9.0 y 8.0 de vCenter Server, y la corrección llegó en versiones puntuales concretas. Broadcom no publicó workaround ni mitigación: la única defensa real es actualizar. Estas son las versiones parcheadas según el aviso:

Rama de vCenter	Versión con el fix
9.1	9.1.0.0300
9.0	9.0.2.0100
8.0	8.0 U3k o 8.0 U2f

Si corrés una versión anterior a esas, asumí que estás en la ventana de exposición. Verificá la build exacta en tu appliance (la que muestra la consola o el VAMI) y contrastala contra el aviso oficial de Broadcom antes de dar por cerrado el tema, porque los números de build cambian según el update path.

¿Qué tan rápido pasó de aviso a explotación masiva?

Cinco días. Broadcom publicó el aviso el 29 de julio de 2026 y, según QUIRSO, los primeros sistemas comprometidos empezaron a conectarse a infraestructura del atacante el 3 de agosto. A partir de ahí la curva fue casi vertical:

4 de agosto: 151 IPs víctimas nuevas. En un solo día apareció una oleada que multiplicó el conteo inicial.
5 de agosto: 343 de las 361 IPs finales ya comprometidas. Es decir, cerca del 95% del total ocurrió en las primeras 48 horas de explotación observada.
361 IPs en 47 países. QUIRSO mapeó víctimas en sectores de tecnología, investigación, educación y telecomunicaciones, con concentraciones en Alemania, Estados Unidos, Turquía, Irán y Francia.

El patrón se repite en cada vulnerabilidad crítica de infraestructura expuesta: la ventana entre "salió el parche" y "hay explotación en producción" se mide en días, no en meses. Publicar el aviso también le da al atacante el mapa.

¿Cómo persisten los atacantes una vez adentro?

Con varias capas de persistencia pensadas para sobrevivir a un reinicio o a una limpieza parcial. Una vez con ejecución como root, la campaña no dependió de un solo mecanismo, sino de redundancia:

Reverse SSH hacia afuera. Desplegaron utilidades de túnel SSH reverso (el framework open source reverse_ssh) que abren canales de comando y control salientes, esquivando reglas de firewall que solo filtran tráfico entrante.
Tareas disfrazadas de VMware. Trabajos con nombres que imitan a VMware volvían a habilitar SSH y colocaban claves del atacante en el authorized_keys de root, una y otra vez.
Un servicio de sistema propio. Un service llamado sys-9436d8.service reiniciaba los backdoors desplegados si algo los tumbaba.
Web shell camuflado. Escribieron una web shell JSP llamada vmware-perf-update.jsp dentro del directorio de la aplicación Perfcharts, haciéndola pasar por una actualización de performance.

¿Cómo se llega desde vCenter al ransomware sobre ESXi?

vCenter es el plano de control de toda la infraestructura virtual, así que comprometerlo da las llaves de los hosts ESXi que administra. Con ese acceso, la campaña dio el salto del appliance de gestión a los hipervisores y desplegó ransomware directamente sobre ellos. El encadenamiento observado fue:

Crear cuentas de administrador local en los hosts ESXi. Acceso propio, independiente de las credenciales legítimas.
Subir el ejecutable de ransomware por el datastore browser de vSphere. Una ruta "legítima" de la propia plataforma para plantar el binario.
Correr scripts que paran las VMs, lanzan el cifrado contra los volúmenes VMFS y remueven los agentes de alta disponibilidad de VMware. Primero desarman las defensas y la resiliencia, después cifran.

El ransomware es una variante derivada de Babuk. Los archivos cifrados reciben la extensión .babyk, y en los VMDK grandes el cifrado es parcial —apuntan a los primeros 512 MB del archivo— una técnica clásica para inutilizar la máquina virtual sin pagar el costo de cifrar terabytes enteros. QUIRSO atribuye la campaña, con confianza moderada, a un actor de habla china, sin vincularlo a un grupo con nombre propio.

¿Qué podés hacer hoy si administrás vCenter?

Lo primero y no negociable es parchear a una de las versiones corregidas; no hay mitigación que reemplace eso. Pero como la explotación ya lleva semanas activa, actualizar no alcanza: hay que asumir posible compromiso y buscar rastros. Acciones concretas:

Sacá las interfaces de gestión de internet. vCenter y ESXi no deberían tener acceso público directo; restringí la administración a redes aprobadas o detrás de VPN.
Revisá cuentas y sudoers nuevos. Buscá usuarios que no reconozcas, tanto en vCenter como en los hosts ESXi, y cambios recientes en permisos de sudo.
Auditá cron, servicios y directorios de aplicaciones web. Prestá atención a archivos en /etc/cron.d, services con nombres raros y JSP inesperados en directorios como el de Perfcharts.
Chequeá authorized_keys de root y el estado de SSH. Claves que no pusiste vos y SSH habilitado sin razón son señales directas.
Mirá conexiones salientes anómalas. Un appliance de gestión que abre túneles hacia IPs desconocidas es exactamente lo que buscaban ocultar.

Preguntas frecuentes

¿CVE-2026-59310 necesita credenciales para explotarse?

No. Es una vulnerabilidad sin autenticación: basta con acceso de red al servicio Syslog de vCenter. Por eso el aviso la clasifica con CVSS 9.8 y por eso la exposición pública del servicio es tan peligrosa.

¿Hay algún workaround si no puedo parchear ya?

No hay workaround oficial. Broadcom indicó que ninguna mitigación reemplaza al parche. Lo único que reduce el riesgo mientras coordinás la actualización es quitar el acceso público a las interfaces de gestión y limitarlas a redes de administración aprobadas.

¿Cómo sé si ya me comprometieron?

Buscá los indicadores del ataque: cron jobs sospechosos en /etc/cron.d (se vieron nombres como zz-poc59310), el service sys-9436d8.service, la web shell vmware-perf-update.jsp, claves SSH desconocidas en root y cuentas de administrador nuevas en ESXi. QUIRSO publicó una regla YARA de detección aunque reservó parte de los indicadores por coordinación con las fuerzas del orden.

¿Qué ransomware desplegaron sobre ESXi?

Una variante derivada de Babuk que cifra parcialmente los discos virtuales (primeros 512 MB de los VMDK grandes) y agrega la extensión .babyk. Antes de cifrar, los scripts paran las VMs y remueven los agentes de alta disponibilidad para maximizar el daño.

¿Por qué comprometer vCenter es tan grave?

Porque vCenter es el plano de control de todo el entorno virtual: administra los hosts ESXi, sus VMs y su almacenamiento. Un atacante con root en vCenter tiene un camino directo a los hipervisores, y de ahí a apagar, exfiltrar o cifrar toda la infraestructura, como demostró esta campaña.

La lección: la superficie de gestión es la joya

CVE-2026-59310 no destaca por su complejidad técnica —un path traversal es de manual— sino por lo que representa: en virtualización, el plano de control concentra tanto poder que un bug "simple" en un servicio secundario como el de logs alcanza para pivotear a todo el datacenter. La defensa no es un solo parche, es tratar a vCenter y ESXi como lo que son: activos que jamás deberían mirar a internet, que necesitan actualización agresiva y monitoreo de lo que escriben en disco. Si esta nota te resultó útil, el patrón de "de PoC público a root en minutos" que ya cubrimos en otros CVEs de infraestructura es lectura complementaria directa.

Fuentes: CybersecurityNews — VMware Syslog Path Traversal Becomes Root RCE, BleepingComputer — Critical VMware vCenter RCE flaw exploited for reverse SSH access, Infosecurity Magazine — vCenter CVE-2026-59310 exploited y SecurityWeek — Critical VMware vCenter Vulnerability in Attackers' Crosshairs.