Nueve Días del Parche a 361 Víctimas

Broadcom publicó el aviso VMSA-2026-0006 el 29 de julio de 2026, revelando CVE-2026-59310 junto a un fallo complementario de omisión de autenticación, CVE-2026-59309, en VMware vCenter Server 8.0, 9.0 y 9.1. Las versiones corregidas estuvieron disponibles el mismo día: vCenter 9.1.0.0300, vCenter 9.0.2.0100 y vCenter 8.0 U3k o U2f, según la rama de actualización desplegada.

QUIRSO GmbH, una firma alemana de análisis forense digital y respuesta a incidentes, afirma que la infraestructura controlada por el atacante registró sus primeras conexiónes entrantes desde sistemas vCenter explotados el 3 de agosto de 2026, apenas cinco días después de publicarse el parche. Para el 7 de agosto, la firma había contabilizado 361 direcciones IP de víctimas distintas repartidas en 47 países, con aproximadamente la mitad concentrada en Alemania, Estados Unidos, Turquía, Iran y Francia. QUIRSO publicó una regla de detección YARA junto a sus hallazgos, aunque retuvo algunos indicadores de compromiso mientras coordinaba con las fuerzas de seguridad.

Una Función de Syslog Que Entrega Todo el Servidor

CVE-2026-59310 reside en la lógica de manejo de directorios del componente Syslog Server de vCenter. El propio aviso de Broadcom afirma sin rodeos que un actor malicioso con acceso de red a vCenter puede explotar el problema para ejecutar código arbitrario, y, de forma crítica, sin necesitar autenticación previa. Esa combinación, sin autenticación más ejecución de código a nivel de sistema, es lo que le valió a este fallo su puntuación de 9.8 sobre 10 y lo que convierte a cualquier instancia de vCenter accesible desde internet en un objetivo inmediato, no teórico.

vCenter no es una herramienta periférica. Es el plano de gestión de todo el parque de virtualización de una organización, la consola que aprovisiona, migra y controla cada máquina virtual que ejecuta una empresa. Un aviso del fabricante para este producto concreto nunca debería esperar en la misma cola que un parche de aplicación rutinario.

Por Qué reverse_ssh Supera la Regla de Cortafuegos Que Ya Tiene

En lugar de abrir un puerto a la escucha en el servidor vCenter comprometido, algo que la mayoría de la monitorización de red está diseñada para detectar, los atacantes detrás de esta campaña instalan reverse_ssh, una herramienta de código abierto en Go que hace que la máquina comprometida inicie una conexión SSH saliente de vuelta hacia la infraestructura del atacante. Como la conexión es saliente, puede eludir las políticas de cortafuegos y de red configuradas para bloquear el tráfico entrante no solicitado pero que dejan pasar sesiones salientes de aspecto normal, lo que da al atacante un punto de apoyo duradero e interactivo capaz de sobrevivir a una revisión sencilla de segmentación de red.

Para un dispositivo que ya se sitúa en el centro del parque de virtualización de una organización, este mecanismo de persistencia convierte un único servidor vCenter sin parchear en una cabeza de playa duradera en lugar de un golpe de una sola vez.

Tesis Original: La Brecha de la KEV Es Aquí la Verdadera Historia

La mayoría de la cobertura de vulnerabilidades mide la urgencia según si un fallo ha entrado en el catálogo Known Exploited Vulnerabilities de la CISA, y muchos programas de parcheo están construidos, formal o informalmente, alrededor de ese mismo disparador. CVE-2026-59310 rompe esa suposición. La telemetría independiente de QUIRSO y de la firma de seguridad Rapid7 documentó cientos de compromisos reales en 47 países dentro de la primera semana y media tras la divulgación, y sin embargo, en el momento de escribir esto, la CVE seguía sin aparecer en el catálogo de la CISA. Un flujo de trabajo de parcheo que trata la inclusión en la KEV como la señal para escalar un aviso de vCenter a estado de emergencia ya iba, por definición, semanas por detrás de los atacantes que encontraron y armaron este fallo.

La lección se extiende más allá de esta única CVE. Para software de nivel de infraestructura como una consola de gestión de hipervisor, la telemetría de una firma forense independiente o la propia puntuación de gravedad del fabricante deberían bastar para desencadenar un parcheo de emergencia por sí solas, sin esperar a una entrada en un catálogo gubernamental que, esta vez, sencillamente no llegó a tiempo.

Qué Deben Hacer Ahora los Operadores de vCenter

Cualquier organización que ejecute vCenter 8.0, 9.0 o 9.1 y que aún no haya aplicado las correcciones del 29 de julio debería tratarlo como un cambio de emergencia, no programado, y además confirmar que la interfaz de gestión no sea directamente accesible desde internet, algo que nunca debería ocurrir en primer lugar. Dado el método de persistencia saliente documentado aquí, monitorizar las conexiónes SSH salientes iniciadas por servidores de nivel de infraestructura, no solo el acceso entrante a ellos, forma ahora parte de una estrategia de detección completa frente a esta campaña concreta.

Para las entidades esenciales e importantes de la UE bajo NIS2 que operaron instancias de vCenter accesibles desde internet o expuestas de otro modo durante la ventana de explotación, este incidente encaja exactamente en las categorías para las que se redactó la directiva: ejecución remota de código sin autenticar sobre infraestructura con explotación activa confirmada y una posibilidad real de impacto en la confidencialidad, la integridad o la disponibilidad de todo el parque de virtualización.

Leer a continuación: Una Cadena de Dos Llamadas de Langflow Dio Root a 295 Atacantes  |  CVSS 9.6: fallo golpeó balanceadores 792 veces