Una falla crítica en VMware vCenter (CVSS 9.8) ya está siendo explotada en 361 servidores de 47 países para instalar puertas traseras SSH permanentes

Si tu empresa administra sus propios servidores virtualizados —no un solo VPS, sino un clúster completo de máquinas virtuales— es casi seguro que en algún punto de esa infraestructura hay una instancia de VMware vCenter. Es el panel de control central que le dice a los servidores físicos qué máquinas virtuales correr, dónde y con qué recursos. Por eso, cuando aparece una falla crítica en vCenter, no es un problema de "una web caída": es un problema de quién controla el centro de datos entero.

Eso es justo lo que pasó con CVE-2026-59310, una vulnerabilidad de directory traversal (path traversal) en el servicio de Syslog de vCenter que permite ejecutar código de forma remota sin necesitar ninguna credencial, solo acceso de red al servidor. Broadcom, el dueño actual de VMware, la reveló el 29 de julio y le puso la puntuación máxima de gravedad posible en la escala CVSS: 9.8 sobre 10. La descubrió QUIRSO, una firma alemana de ciberseguridad.

Cómo funciona el ataque

Una falla de path traversal ocurre cuando una aplicación no valida bien las rutas de archivo que recibe, y un atacante puede "salirse" de la carpeta donde debería quedarse encerrado —usando secuencias como ../../— para leer o escribir archivos en cualquier parte del sistema. En el caso de vCenter, eso es suficiente para lograr ejecución de código arbitrario en el servidor.

Los grupos que ya están explotando esta falla no se quedan en el acceso inicial. Según las firmas que rastrean la campaña, el patrón es siempre el mismo: primero la actividad de path traversal que confirma la explotación, después el despliegue de un cron job malicioso para sobrevivir a un reinicio, y finalmente la instalación de reverse_ssh, una herramienta de código abierto escrita en Go.

Lo que hace reverse_ssh es simple pero efectivo: en vez de que el atacante se conecte hacia el servidor comprometido (una conexión entrante que un firewall bien configurado podría bloquear o detectar), es el servidor comprometido el que se conecta hacia afuera, hacia la máquina del atacante. Esa conexión saliente suele pasar los controles de seguridad sin levantar sospechas, porque la mayoría de los firewalls están pensados para filtrar lo que entra, no lo que sale. Con eso, el atacante queda con acceso remoto persistente, capacidad de moverse lateralmente por la red interna y transferencia de archivos vía SCP/SFTP, todo camuflado como tráfico saliente normal.

Un ataque activo, no una advertencia teórica

Esto no es un escenario hipotético de laboratorio: la explotación arrancó el 3 de agosto, apenas días después de que Broadcom publicara el parche, y escaló rápido. Para el 4 de agosto ya había 151 IPs nuevas comprometidas; para el 5, el conteo llegó a 343; y para el 7 de agosto, la cifra confirmada fue de 361 servidores comprometidos en 47 países, con más de la mitad concentrada en Alemania, Estados Unidos, Turquía, Irán y Francia.

No es la primera vez que vCenter queda en la mira de actores sofisticados: grupos vinculados a espionaje estatal, como UNC5174, ya han explotado fallas similares en el pasado precisamente porque controlar vCenter significa controlar la infraestructura de virtualización completa de una organización, no solo una máquina.

Broadcom no ofreció ningún workaround para esta falla —la única opción es actualizar. Las versiones parchadas son vCenter 9.1.0.0300, 9.0.2.0100 y 8.0 U3k (o 8.0 U2f para quienes siguen en esa rama). Si tu equipo administra vCenter y todavía no aplicó el parche, esta no es una tarea para la próxima ventana de mantenimiento: con explotación activa y sin mitigación alternativa, cada día sin actualizar es un día con la puerta de entrada abierta.

Este tipo de incidente es también un recordatorio de por qué importa quién administra la capa de virtualización de tu infraestructura y qué tan rápido reacciona cuando sale un CVE crítico. Si administras tus propios servidores dedicados y corres tu propia capa de virtualización, la respuesta a fallas como esta depende enteramente de tu equipo y de qué tan rápido se entera y actúa — algo que vale la pena tener resuelto antes de que aparezca la próxima vulnerabilidad crítica de este calibre.