El 28 de octubre de 2026, CISA añadió CVE-2026-41709, el fallo de registro insuficiente de Broadcom VMware ESX, a su catálogo de vulnerabilidades explotadas conocidas (KEV). Ese mismo día, CrowdStrike informó de que el actor vinculado a China Warp Panda lo había usado como zero-day antes de la corrección de Broadcom del 29 de julio de 2026. El fallo puntúa solo 2,7 en CVSS, pero su razón de ser es cegar el rastro de auditoría en el host. Si el registro de auditoría de ESXi vive solo en el host, esa es la parte que conviene replantear.

Esto es lo que establecen las fuentes. El aviso de Broadcom VMSA-2026-0006 clasifica el problema con gravedad baja y lo encuadra en CWE-778. En sus propias palabras: «Un administrador malicioso podría aprovechar este problema para realizar determinadas operaciones sin que queden registradas.» Una fuente secundaria da el vector con privilegios altos requeridos, de modo que el atacante necesita antes derechos de administrador de ESXi. Broadcom no indica ninguna medida de mitigación; la solución es el parche, y atribuye el informe a Ian Barton, de CrowdStrike.

Esto es lo que nadie ha publicado. Ni Broadcom ni CrowdStrike dicen qué operaciones quedan sin registrar ni cómo funciona el bypass, y no hay lista de indicadores. CISA tampoco dio detalles sobre la explotación y fijó un plazo, el 11 de noviembre de 2026, para las agencias civiles federales de EE. UU. El fallo en sí no es nuevo; solo lo son las pruebas de explotación y su inclusión en el KEV.

La puntuación engaña porque CVSS califica un fallo de forma aislada. Según CrowdStrike, Warp Panda normalmente entra por dispositivos perimetrales expuestos a internet y salta a vCenter. En varios ataques, incluso a principios de 2026, usó este CVE para reducir de forma significativa la visibilidad del rastro de auditoría. Un fallo de gravedad baja es un mal indicador del daño cuando es el paso que borra las pruebas de los demás.

Por qué los logs del plano de gestión deben salir del host

Un log guardado en la propia máquina que se administra es tan fiable como la cuenta de administrador. Quien tenga esa cuenta puede detener el logger, editar el archivo o, como aquí, ejecutar operaciones que nunca llegan a él.

Un log que el administrador puede editar es un diario, no un rastro de auditoría.

ESX escribe cada mensaje de syslog en el archivo de log local y además lo reenvía a cada colector configurado. La copia remota es, por tanto, una segunda copia hecha en el momento de la generación, fuera del alcance de cualquier cosa que le ocurra después al host. Ese es el argumento a favor del reenvío de logs del hipervisor, y vale para cualquier hipervisor.

Hay un límite que conviene decir sin rodeos. Ninguna fuente que hemos leído indica si el bypass de CVE-2026-41709 afecta también a la copia enviada a syslog, así que no afirmamos que el reenvío neutralice este fallo concreto. Lo que el reenvío te da es un registro independiente, huecos que puedes ver comparando dos fuentes y pruebas que sobreviven a la vulneración del host.

Registro de auditoría de ESXi: cómo configurar el reenvío de logs del hipervisor

Dos ajustes avanzados hacen la mayor parte del trabajo. Syslog.global.logHost define los colectores remotos con el formato protocol://hostname|ipv4|[ipv6][:port], y si está en blanco no se reenvía nada. Syslog.global.certificate.checkSSLCerts obliga a comprobar el certificado cuando ESX envía a un host remoto. Los puertos por defecto son el 514 para UDP y TCP y el 1514 para TLS.

La documentación de Broadcom para la versión 9.1 indica que usar ESXCLI obliga a habilitar inicios de sesión por SSH, algo que califica de riesgo de seguridad y que no recomienda, y remite en su lugar a los ajustes avanzados del vSphere Client. A modo de referencia, una guía de terceros sobre TLS (no de Broadcom) usa estos comandos:

esxcli system syslog config set --check-ssl-certs=true
esxcli system syslog config set --loghost="ssl://logs.example.com:1514"
esxcli system syslog reload

La misma guía habilita también el conjunto de reglas de firewall de syslog en el host. Verifica la entrega en el colector después de cualquier cambio; un ajuste que parece correcto en el cliente no demuestra nada sobre lo que llega.

Los logs de auditoría a prueba de manipulaciones dependen del colector

Ten cuidado con la expresión «a prueba de manipulaciones». Ninguna fuente demuestra que el reenvío por sí solo lo consiga, porque un atacante con derechos de administrador puede cambiar logHost. La inmutabilidad es una propiedad del lado del colector: credenciales separadas que los administradores del hipervisor no tengan, almacenamiento de escritura única o bloqueado de otro modo, y una retención que no puedan acortar.

Después, vigila el propio pipeline. Un blog de un proveedor sugiere alertar ante cambios en la configuración de syslog, ante una recarga, ante un vmsyslogd detenido y ante un logHost modificado. Añade el complemento obvio: un host que se queda en silencio es un evento. Ante un fallo que oculta operaciones, el silencio merece la misma atención que una alerta ruidosa.

Las pautas de bastionado derivadas de CrowdStrike, tal como las resumen análisis de terceros, añaden los controles de alrededor para el bastionado de VMware ESX:

  • Vigila los inicios de sesión SSH de root y vpxuser.
  • Desactiva SSH donde puedas y aplica execInstalledOnly.
  • Restringe el tráfico de salida de ESXi y vCenter.
  • Pon autenticación multifactor delante de vCenter.

Cómo tratamos nuestro propio plano de gestión

Operamos nuestros datacenters nosotros mismos, y la misma regla se aplica a las personas que acceden a ellos. Solo el personal autorizado de DIVERSITY ubicado en la UE puede acceder a la infraestructura, y el acceso administrativo queda registrado y exige autenticación multifactor. Nuestras instancias cloud funcionan sobre KVM, así que este CVE no forma parte de esa pila. El principio de que las acciones de un administrador necesitan un registro que el propio administrador no controle vale para cualquier plano de gestión.

Si ejecutas ESX en tu CPD propio y quieres el colector en otro sitio, puedes alojarlo en una instancia cloud en el centro que elijas. MUN1, en Múnich, está en el hub para Alemania, Austria y Suiza, y AMS1, en Ámsterdam, es una puerta de entrada al Benelux; elige el que encaje con tu propia geografía y mantenlo separado del edificio del host. Private Link puede llevar los logs de tu ubicación a la nuestra, cifrados desde tu ubicación hasta nuestro centro. Nuestro equipo de Consultoría IT también realiza revisiones de arquitectura y salidas de VMware si la mejor respuesta es dejar de operar la plataforma.

Qué hacer esta semana

  1. Aplica el parche. Broadcom no indica ninguna medida de mitigación. Toma la compilación corregida para tu versión de la página vigente de VMSA-2026-0006, porque las fuentes secundarias enumeran cadenas de compilación distintas, y revisa las pautas para la versión 7.0 añadidas en una revisión posterior del aviso.
  2. Comprueba logHost. Confirma que no está en blanco en ningún host, que la comprobación de certificados está activada y que los mensajes llegan al colector.
  3. Separa el colector. Dale credenciales y almacenamiento que los administradores de ESX y vCenter no puedan modificar.
  4. Alerta ante cambios y ante silencio. Cubre las ediciones de la configuración de logging, un logger detenido y un host que deja de enviar.
  5. Revisa la vía de entrada. Audita SSH, el acceso a vCenter y los dispositivos perimetrales, porque ahí es donde CrowdStrike dice que empieza Warp Panda.

Una puntuación baja no impidió que este fallo se usara en intrusiones reales. Trata como prioritario cualquier fallo que elimine pruebas, y guarda una copia del registro en un lugar al que el intruso no pueda llegar.

Fuentes