El 30 de julio escribimos aquí sobre VMSA-2026-0006 y, entre los datos del aviso, copiamos una frase de Broadcom: no tenía información que sugiriera explotación in the wild de ninguno de aquellos cinco fallos. Rapid7, que analizó el aviso el mismo día, lo formuló aún más ancho: ni explotación ni escaneo para los dos 9,8 de vCenter. Las dos cosas eran ciertas el 29 de julio. Cinco días después, el 3 de agosto, los primeros vCenter comprometidos empezaron a conectar con la infraestructura del atacante.
Esto no es una corrección de aquel post: el dato era correcto y lo sigue siendo con su fecha delante. Lo que ha cambiado es el peso que le damos a ese tipo de frase cuando alguien la usa —y se usa mucho— para justificar que la ventana de mantenimiento puede esperar a septiembre. Operamos VMware y Proxmox en producción y no vendemos licencias de ninguno de los dos, así que aquí no hay nada que colocar. Hay un calendario, unos números con sus matices y una pregunta que casi nadie sabe responder en menos de media hora.
El calendario, día a día
El 12 de agosto, la firma alemana QUIRSO publicó lo que encontró a raíz de una respuesta a incidente: una campaña activa contra sistemas vCenter accesibles desde internet, atribuida de forma tentativa a un actor de tipo APT, que explota
La forma de esa curva importa más que el total. Hay un día de pico y una semana en la que ya está casi todo, sin goteo previo de meses. Quien planifique sus parches por trimestres está compitiendo contra una campaña que colocó el 95 % de sus víctimas conocidas en los siete días siguientes al aviso —y que a fecha del informe seguía sumando: dieciocho direcciones más entre el 6 y el 12 de agosto—.
Qué no dicen esos 361
Los propios investigadores ponen tres límites a su cifra, y nos parece la parte más honesta del informe:
- 361 IP no son 361 empresas. Lo dicen con todas las letras: de esas direcciones no se puede inferir el número de organizaciones víctima, porque una IP no equivale necesariamente a una empresa ni a un sistema físico. Puede haber varias detrás de una, y una empresa detrás de varias.
- Encontrar
- Los indicadores todavía no están publicados. QUIRSO dice que los indicadores propios del atacante y el material de detección adicional saldrán más adelante, coordinados con las fuerzas de seguridad para no interferir en una investigación en curso. De momento hay una regla YARA para cazar
Un número que viene con sus propios límites vale mucho más que un número redondo sin ellos. Lo decimos porque en los próximos días ese 361 va a aparecer en presentaciones comerciales convertido en «361 empresas hackeadas», y no es eso lo que dice el informe.
La frase del aviso que hay que aprender a leer
«En el momento de la publicación no hay constancia de explotación ni de escaneo». Esa formulación, la ancha, es de Rapid7; el aviso de Broadcom dice la mitad —que no tiene información que sugiera explotación in the wild— y es la que reprodujimos nosotros. Las dos eran verdad el 29 de julio. Lo que falla es la lectura que hacemos de ellas: se leen como un pronóstico cuando son una foto de la telemetría de quien escribe, el día que escribe. Su valor caduca prácticamente en el instante en que se imprime, porque el propio aviso es lo que pone a todo el mundo a mirar el mismo sitio.
Los investigadores lo dicen con la reserva por delante: aunque el atacante pudiera tener conocimiento previo del fallo, la fuerte correlación entre la fecha de divulgación y la del inicio de la explotación apunta a que la propia divulgación fue el punto de partida de la campaña. Es la asimetría de siempre, ahora con fechas encima de la mesa. El aviso avisa a los dos lados a la vez, y solo uno de los dos tiene que pedir una ventana de mantenimiento, coordinar con el proveedor de la aplicación de facturación y esperar al martes que viene.
Que nadie lo lea como una crítica a publicar avisos: sin ese documento no habrías podido parchear nada. Lo que no vale es usar el «no hay constancia» como argumento para retrasar. Nuestra regla, desde hace tiempo, es tratar esa frase como información sobre el pasado y calcular la urgencia con lo único que sí es una propiedad del fallo: si hace falta autenticarse, si hace falta interacción y desde dónde se puede llegar al servicio. Los dos 9,8 de vCenter de este aviso no piden credenciales; el resto es aritmética.
Las tres palabras que hacen todo el trabajo: «accesible desde internet»
El 9,8 del CVSS asume que el atacante tiene acceso de red al servicio, y quién tiene ese acceso lo decides tú. Por eso la campaña no va contra todos los vCenter del mundo, sino contra los que contestan desde internet: ese es el filtro que separa las 361 direcciones del resto del parque mundial, y es la única parte de la ecuación que está en tu mano una vez publicado el aviso.
La pregunta incómoda, entonces, no es «¿lo hemos parcheado?». Es «¿quién puede abrir una conexión TCP contra nuestro vCenter?». En la mayoría de sitios donde entramos, esa respuesta no está escrita en ninguna parte: se reconstruye mirando reglas de firewall que puso alguien que ya no está, una regla temporal de un proyecto de 2023 y una VPN que en realidad da acceso a toda la VLAN de gestión. Reconstruirla lleva una tarde. Tenerla escrita, y revisada, es literalmente el trabajo de Zero Trust: el plano de gestión no tiene privilegios especiales por ser interno, y quien no necesita llegar no llega.
Y el contrapeso honesto, que también está escrito en los análisis de este aviso: restringir las interfaces de gestión a una red interna o dedicada reduce la exposición a internet, pero no mitiga el riesgo de un atacante que ya está dentro de tu red. Sacar el vCenter de internet te saca del censo de esta campaña concreta; no te saca del problema. Dicho de otro modo: la exposición explica quién entró en agosto, no quién podría entrar el mes que viene desde un portátil ya comprometido. Ese matiz ya nos hizo escribir sobre la consola de gestión de otro fabricante, y aquí vuelve con fechas.
Qué mirar esta tarde si tienes vSphere
- La versión exacta, no la de memoria. Con PowerCLI, tras
- La exposición, medida desde fuera. En la LAN todo llega siempre, así que la prueba se hace desde una IP de internet: ¿contesta el vCenter? ¿Contesta el servicio de syslog, que es justo el componente del fallo? Si la respuesta a alguna de las dos es «no lo sé», ya has encontrado por dónde empezar.
- Si estuviste expuesto y sin parchear entre el 29 de julio y hoy, «ya está parcheado» no cierra el asunto. Toca mirar tareas de cron que nadie recuerda haber creado en el appliance y, sobre todo, conexiones salientes: un vCenter no tiene ningún motivo para iniciar sesiones SSH hacia internet. Ya lo escribimos con otro fabricante y el argumento no ha envejecido: aplicar el parche no expulsa a quien ya estaba dentro.
- Los registros de ese periodo, con reservas. En el post del 30 de julio dijimos que el fallo que menos puntuaba del lote —el de registro insuficiente en ESX— era el que decidiría si un informe posterior dice «esto es lo que hizo» o «esto es lo que creemos que hizo». Dos semanas después hay gente escribiendo exactamente ese informe. Si te toca, ahí está el detalle del aviso completo.
- La fecha y la hora de todo lo que hagas. Qué versión tenías, cuándo se aplicó el parche, quién lo aplicó y qué quedó pendiente. En un incidente esa línea temporal vale más que cualquier herramienta, y es lo primero que te van a pedir.
La distancia que de verdad importa
De todo este episodio, el número que nos preocupa no es 361, sino la distancia entre «se publica un aviso crítico de un producto que tenemos» y «alguien con permisos lo está mirando». Esta vez esa distancia tenía que ser menor de cinco días, en agosto y con media plantilla de vacaciones. En la mayoría de organizaciones no depende del equipo técnico, que suele enterarse el primer día, sino de que exista un turno con capacidad de decidir un cambio urgente sin esperar al comité de septiembre. Es la parte menos vistosa del soporte 24×7 y la que decide si sales en un recuento como este.
Lo cual no significa que hoy toque declarar una emergencia en todas partes. Si tu vCenter nunca ha contestado desde internet y parcheaste en la primera semana, no estás en la población de esta campaña, y un cambio de emergencia ahora solo te va a costar atención y errores. Lo decimos aunque suene raro viniendo de quien vende servicios de seguridad: no todo aviso de 9,8 es tu incendio. Y tampoco es un argumento para cambiar de hipervisor —Proxmox publica sus propios avisos, con sus reinicios y sus ventanas—, porque lo que se traslada de una plataforma a otra es el trabajo, no el reloj.
Fuentes (verificadas): la campaña activa contra vCenter accesible desde internet, las 361 direcciones IP víctima en 47 países, el primer contacto con infraestructura del atacante el 3 de agosto (cinco días después del aviso), el pico de 151 direcciones nuevas el 4 de agosto, las 343 de 361 alcanzadas el 5 de agosto, los cinco países más afectados (185 de 361), el uso de reverse_ssh, la advertencia de que una IP no equivale a una organización, la de que la presencia de reverse_ssh no es por sí sola prueba de actividad maliciosa y el aplazamiento de los indicadores por coordinación con las fuerzas de seguridad — informe de QUIRSO GmbH (12 de agosto de 2026) y la cobertura de The Hacker News, que es además la fuente del detalle de la tarea de cron que despliega la persistencia. La descripción de CVE-2026-59310 (directory traversal en el servidor syslog de vCenter, CVSS 9,8, sin autenticación), la fecha del aviso VMSA-2026-0006 (29 de julio de 2026), la frase «no hay constancia de explotación ni de escaneo en el momento de la publicación», las versiones corregidas y la observación de que restringir las interfaces de gestión a redes internas reduce la exposición a internet pero no mitiga a un atacante ya presente en la red: análisis de Rapid7. La lectura de la frase del aviso como foto y no como pronóstico, la pregunta sobre quién puede abrir una conexión al vCenter, el criterio de cuándo NO declarar emergencia y la regla de fechar todo lo aplicado son nuestros. Imagen: cronómetro deportivo (rawpixel, CC0).
¿Sabes quién llega hoy a tu plano de gestión?
En everyWAN mantenemos infraestructura de otros y llevamos la parte de seguridad de esos entornos. La respuesta a «quién puede llegar a vCenter, al hipervisor y a la consola de copias» no debería reconstruirse en mitad de un susto: se escribe una vez, se revisa y se aplica con Zero Trust, y luego hace falta alguien de guardia que la haga cumplir en agosto con soporte 24×7. Si quieres una opinión sin comisión detrás, cuéntanos qué tienes montado.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN