Por Mid 
VMware vCenter arrastra desde el 29 de julio de 2026 una vulnerabilidad crítica de omisión de autenticación, CVE-2026-59309, con 9.8 en CVSS. Un atacante sin credenciales y con acceso de red al servidor puede saltarse por completo el inicio de sesión y hacerse con el plano de gestión de toda la infraestructura virtual.
Y hay un detalle que condiciona toda la respuesta: Broadcom afirma que no existe mitigación temporal. O actualizas, o sigues expuesto.
Resumen del aviso
- Boletín: VMSA-2026-0006, publicado el 29 de julio de 2026.
- CVE principal: CVE-2026-59309, 9.8 en CVSSv3.1, omisión de autenticación.
- Acompañante: CVE-2026-59310, salto de directorio en el mismo producto.
- Requisitos del atacante: ninguno. Sin autenticar, solo acceso de red.
- Mitigación: no hay. Solo actualización.
Qué falla en VMware vCenter
El fallo de VMware vCenter reside en el servicio de directorio que usa el producto para gestionar identidades y autenticación. Es la pieza que decide quién eres y qué puedes hacer, así que un defecto ahí no es un fallo más: es la puerta principal quedándose abierta.
La combinación de factores es lo que dispara la puntuación hasta 9.8. No hace falta cuenta previa, no hace falta que ningún usuario haga clic en nada y la complejidad del ataque es baja. Basta con alcanzar el servicio por red.
Conviene entender qué significa perder el control de VMware vCenter, porque no es equivalente a perder un servidor. Desde esa consola se administran los hipervisores, se crean y destruyen máquinas virtuales, se accede a sus discos y se manejan las credenciales de conexión con el almacenamiento y la red. Un atacante con ese acceso no necesita comprometer cada máquina virtual por separado: las tiene todas.
Alcance del boletín VMSA-2026-0006 en VMware vCenter
El aviso corrige cinco vulnerabilidades repartidas entre el servidor de gestión, el hipervisor y los productos de escritorio. Estas son las dos que afectan a VMware vCenter y que marcan la urgencia:
| CVE | Tipo | Gravedad |
|---|---|---|
| CVE-2026-59309 | Omisión de autenticación | 9.8, crítica |
| CVE-2026-59310 | Salto de directorio | Alta |
El resto del boletín cubre fallos en el hipervisor y en los productos de escritorio: una escritura fuera de límites en el adaptador de red virtual, una lectura fuera de límites y un problema de registro insuficiente. Menos graves, pero conviene aplicarlos en la misma ventana de mantenimiento.
Versiones corregidas de VMware vCenter
| Producto | Versión corregida |
|---|---|
| vCenter Server 8.0 | 8.0 U3k |
| Cloud Foundation / vSphere Foundation 9.1 | 9.1.0.0300 |
| Cloud Foundation / vSphere Foundation 9.0 | 9.0.2.0100 |
Comprueba la versión de tu VMware vCenter desde la interfaz de administración del dispositivo, en el puerto 5480, o directamente por consola:
vpxd -v
cat /etc/vmware/.buildInfoSin soluciones intermedias
En otros avisos de VMware vCenter se puede desactivar un servicio o cerrar un puerto mientras llega la ventana de mantenimiento. Aquí no. El fabricante indica expresamente que no hay alternativas para estas dos vulnerabilidades, así que lo único que reduce el riesgo mientras tanto es restringir por red quién alcanza el servicio.
Cómo responder si administras VMware vCenter
- Comprueba la versión de todos los servidores, incluidos los de laboratorio y los de delegaciones que nadie recuerda.
- Aísla el acceso de red. La consola no debería ser alcanzable desde la red de usuarios y muchísimo menos desde Internet. Restringe a una red de administración o exige VPN.
- Actualiza a la versión de la tabla. Es la única corrección real.
- Revisa los registros buscando accesos anómalos anteriores a la actualización.
- Rota credenciales de servicio y de integración si encuentras cualquier indicio.
- Verifica las copias de las máquinas virtuales críticas antes de tocar nada.
El punto dos merece énfasis en el caso de VMware vCenter. Una consola de gestión de virtualización publicada en Internet es difícil de justificar en cualquier escenario, y en este caso concreto es la diferencia entre un riesgo alto y uno inasumible.
Qué revisar en los registros de VMware vCenter
Actualizar VMware vCenter cierra la puerta, pero no responde a si alguien pasó antes. En el propio dispositivo hay varias rutas que conviene mirar.
/var/log/vmware/vpxd/vpxd.log: actividad del servicio principal./var/log/vmware/sso/: eventos de autenticación e inicio de sesión único./var/log/vmware/vsphere-ui/: acceso a la interfaz web.
Busca sesiones desde direcciones que no correspondan a tu red de administración, altas de usuarios o cambios de permisos, creación de máquinas virtuales fuera de proceso y exportaciones de discos virtuales. Este último punto es especialmente importante: descargar un disco virtual equivale a llevarse el servidor entero, y no deja rastro dentro de la máquina afectada.
Es un patrón que ya vimos hace unas semanas en el bypass de autenticación de N-able N-central: cuando cae una consola centralizada, el daño se mide por todo lo que esa consola gobierna, no por la máquina en sí.
Cómo actualizar VMware vCenter sin sustos
La actualización de VMware vCenter es un procedimiento conocido, pero con un servidor que gobierna toda la plataforma conviene no improvisar. Este es el orden que menos disgustos da.
| Fase | Qué hacer |
|---|---|
| Antes | Instantánea del dispositivo con las máquinas apagadas o en modo consistente, y copia de la base de datos embebida. |
| Comprobación | Verificar espacio libre en disco y estado de los servicios; una actualización con el disco lleno deja el dispositivo inservible. |
| Durante | Aplicar el parche desde la interfaz del puerto 5480 o con la utilidad de línea de comandos. |
| Después | Revisar que todos los servicios arrancan, que los hipervisores reconectan y que las integraciones de copias siguen funcionando. |
Esa instantánea previa es innegociable. Si algo sale mal a mitad de la actualización, revertir en cinco minutos frente a reconstruir el inventario entero es una diferencia enorme. Eso sí, bórrala en cuanto confirmes que todo funciona, porque una instantánea olvidada en VMware vCenter crece hasta llenar el almacén de datos y acaba causando el incidente que querías evitar.
Ten en cuenta también el orden respecto a los hipervisores: la recomendación general es actualizar primero el servidor de gestión y después los hosts, comprobando la matriz de compatibilidad del fabricante si vas a saltar de rama mayor.
VMware vCenter y la virtualización como objetivo
No es un caso aislado de VMware vCenter. La infraestructura de virtualización lleva varios años en el punto de mira de los grupos de ransomware, y por un motivo muy pragmático: cifrar los almacenes de datos de un hipervisor deja inservibles decenas de servidores de una sola vez, sin necesidad de desplegar nada dentro de cada sistema operativo.
Ya cubrimos en enero, junto a VMware vCenter, las vulnerabilidades explotadas en VMware ESXi, y el guion se repite con insistencia. La lección operativa es que el plano de gestión de la virtualización merece el mismo trato que un controlador de dominio: red separada, acceso restringido, doble factor, registro centralizado y parcheo en días, no en trimestres.
Añade además una consideración de resiliencia que se olvida con frecuencia: si tus copias de seguridad se orquestan desde la misma consola o viven en el mismo almacenamiento, un compromiso del plano de gestión se lleva por delante los datos y las copias a la vez. Guarda siempre un juego fuera de ese alcance.
Hay un último punto que conviene revisar mientras se está en faena, aunque no forme parte del boletín: las cuentas de servicio integradas. Las herramientas de copias, de monitorización y de aprovisionamiento suelen conectarse con permisos de administrador porque es lo que pedía el asistente de instalación hace años, y esas credenciales rara vez se rotan. Si alguna vez hubo acceso indebido a la consola, esas cuentas son el camino más cómodo para volver a entrar después de que hayas parcheado.
Aprovecha para inventariarlas, recortar sus permisos a lo estrictamente necesario y anotar cuándo se rotaron por última vez. Es un trabajo aburrido de un par de horas que cambia bastante el resultado del próximo aviso crítico, porque la mitad de la respuesta ya estará hecha.
Preguntas frecuentes sobre VMware vCenter
¿Hay explotación activa confirmada?
En el momento de escribir esto, el boletín documenta las vulnerabilidades y su gravedad, sin que el fabricante confirme explotación en curso. Dada la puntuación y que no requiere autenticación, lo prudente es tratarlo como si fuera cuestión de tiempo.
¿Puedo esperar a la próxima ventana de mantenimiento?
Con un 9.8 sin autenticación y sin mitigación disponible, no es recomendable. Si el calendario no da margen, al menos restringe el acceso de red al servicio para reducir la superficie mientras planificas la actualización.
¿Afecta también a los hipervisores?
Las dos vulnerabilidades críticas son del servidor de gestión. El boletín incluye además fallos que sí afectan al hipervisor y a los productos de escritorio, de menor gravedad, que conviene parchear en la misma intervención.
¿Cómo compruebo mi versión exacta?
Desde la interfaz de administración del dispositivo en el puerto 5480, o por consola con vpxd -v. Compara el resultado con la tabla de versiones corregidas y ten en cuenta que las ramas 8.0 y 9.x tienen numeración distinta.
Fuentes
- Broadcom — Aviso de seguridad VMSA-2026-0006
- Rapid7 — Análisis de CVE-2026-59309 y CVE-2026-59310
- NVD — CVE-2026-59309
- CISA — Catálogo de vulnerabilidades explotadas conocidas
Más avisos en nuestra sección de vulnerabilidades.
Información contrastada el 6 de agosto de 2026. Artículo con finalidad informativa y defensiva; no incluye detalles de explotación.