vCenter es la sala de control de tu virtualización: desde ahí se enciende, se apaga, se mueve, se clona y se borra todo. El 29 de julio Broadcom publicó VMSA-2026-0006 y, entre los cinco fallos que corrige, hay dos de CVSS 9,8 que permiten entrar en esa sala sin credenciales y uno de 9,3 que deja saltar desde dentro de una máquina virtual al servidor que la ejecuta. La respuesta del propio aviso a «¿hay workarounds?» es de una sola palabra: no.
Operamos VMware y Proxmox en producción, hemos migrado empresas de VMware a Proxmox y también hemos recomendado quedarse donde estaban cuando tenía sentido. No somos resellers de ninguna de las dos ni vendemos licencias, así que este post no va de aprovechar el susto. Va de cuatro cosas concretas: qué hay dentro del aviso, en qué orden se aplica —que ha cambiado—, dónde están los parches si te quedaste con licencia perpetua y sin soporte, y el quinto fallo de la lista, ese que no va a salir en ningún titular porque apenas puntúa.
Los cinco fallos, sin adornos
Un apunte de precisión, porque importa: el aviso dice que las puntuaciones del lote van de 2,7 a 9,8 con CVSS 3.1, y confirma explícitamente el 2,7 de
Antes de discutir la ventana de mantenimiento
La conversación de esta semana en muchas empresas va a ser la de siempre: «no tengo ventana». Merece la pena separar las dos mitades del trabajo, porque no cuestan lo mismo ni de lejos.
- vCenter no para tus cargas. Lo dice el propio documento de preguntas y respuestas: actualizar vCenter no afecta a las máquinas virtuales ni a los contenedores en marcha; pierdes el vSphere Client —y el resto de vías de gestión— un rato. Es decir, la parte donde están los dos 9,8 es la barata.
- ESX sí exige reiniciar el host. Ahí está el trabajo de verdad: vMotion para vaciar cada host, reinicio escalonado («rolling reboot») por el clúster y apagado de las máquinas que no puedan migrar en caliente. Si tienes un clúster sin holgura de recursos, ese es tu cuello de botella real, no el parche.
- Live Patch sirve aquí. Estas actualizaciones de ESX son compatibles con Live Patch si tu entorno lo admite —está disponible desde ESX 8.0.3, conviene confirmarlo en las notas de versión y ojo con los hosts que usan TPM: solo son elegibles a partir de VCF 9.1—, lo que según Broadcom puede hacer el proceso «varios órdenes de magnitud» más rápido. El Quick Patch de vCenter, en cambio, no está disponible para estos parches: ahí toca método tradicional o RDU si lo tienes montado.
Traducido: la ventana que necesitas para tapar los dos fallos más graves es mucho más pequeña de lo que va a suponer el comité que la tiene que aprobar. Vale la pena decirlo en esos términos antes de que la reunión derive.
El orden que te sabías ya no es el único
Aquí está la parte del aviso que casi no se ha contado. La regla clásica era vCenter primero, hosts después. Broadcom reconoce ahora que ese requisito ha ido evolucionando y que a menudo se puede actualizar ESX antes que vCenter sin problemas; la comprobación se hace en la matriz de interoperabilidad de producto, cruzando tu versión de vCenter con la de ESX (y con vSAN, si lo usas).
Las dos estrategias que plantea el propio aviso:
· Si tienes muchos hosts: declara cambio de emergencia, actualiza vCenter primero y luego parchea clústeres en paralelo sin interrupción.
· Si no puedes reiniciar vCenter hasta el fin de semana: empieza ya por los hosts ESX, que son compatibles con un vCenter en versión anterior. Eso sí, termina o detén el parcheo de hosts antes de tocar y reiniciar vCenter.
Lo valioso de esas dos frases no es el orden en sí: es que dejan sin argumento a quien iba a aparcar el aviso hasta septiembre. Los parches, además, son acumulativos y no requieren aplicar nada previo, así que no hay una cadena de prerrequisitos que negociar.
Una advertencia que sí conviene leer entera si estás a mitad de un proyecto: estas actualizaciones de vSphere 8.0 y 9.0 provocan una restricción «back in time» que bloquea la actualización a VMware Cloud Foundation 9.x. Si tenías esa migración en marcha, hay que decidir con calendario en mano; la compatibilidad se restablece en versiones posteriores, como en restricciones anteriores del mismo tipo.
El escape de VM y una tentación que conviene evitar
La tentación, para quien no puede parchear ya, es cambiar el adaptador virtual: las VM con otro tipo de tarjeta no están afectadas por ese fallo. El aviso lo desaconseja con dos razones que compartimos: los adaptadores no paravirtualizados como
El fallo que nadie va a mirar
El quinto de la lista es
El CVSS puntúa el impacto sobre la confidencialidad, la integridad y la disponibilidad del sistema. No puntúa —porque no es su trabajo— tu capacidad de reconstruir después lo que pasó. Un fallo de registro no te tira nada abajo: te quita el testigo. Y encadenado con los otros cuatro cambia de tamaño. Si alguien entra por uno de los 9,8 y acaba operando como administrador, este 2,7 decide si tu informe posterior dice «esto es lo que hizo» o «esto es lo que creemos que hizo».
Ya escribimos sobre esto hace poco a propósito de otro fabricante: aplicar el parche no expulsa a quien ya estaba dentro. Aquí hay una vuelta más, porque lo que se degrada no es el sistema sino la prueba. Y las pruebas ya no son un asunto interno: cuando toca notificar un incidente bajo NIS2, o cuando el cliente grande manda su cuestionario de proveedor, lo que te piden son hechos con hora, no impresiones.
Nuestra regla cuando un aviso incluye un fallo de registro es corta: parchear, marcar el periodo de logs anterior al parche como poco fiable y no aceptar un «no se ve nada raro» de ese periodo como si fuera una revisión limpia. Un registro incompleto no es un registro tranquilizador; es un registro incompleto.
Si tu vSphere es antiguo, o ya no pagas soporte
Es la situación de mucha gente después de los cambios de licenciamiento de los últimos dos años, y es donde el aviso tiene la información más útil:
- vSphere 6.5 y 6.7: Broadcom no evalúa productos pasada su fecha de fin de soporte general, así que no aparecen en la matriz. La instrucción es asumir que están afectados.
- vSphere 7: afectado. Llegó a fin de soporte general el 2 de octubre de 2025; si tienes contrato de soporte extendido, los parches se piden por esa vía.
- vSphere 8: las actualizaciones de seguridad se construyen sobre Update 3. No es imprescindible estar en U3 para recibir el parche, pero es la versión sobre la que Broadcom recomienda estar.
- Licencia perpetua y contrato de soporte caducado: tienes derecho al parche igualmente. Desde el compromiso publicado el 15 de abril de 2024, todos los clientes —incluidos los que tienen el soporte vencido— acceden a los parches de las alertas críticas de seguridad de versiones soportadas de vSphere. Hace falta crearse una cuenta gratuita en el portal de soporte. Es el punto que más gente se pierde y justo el que más falta le hace a quien se quedó con licencias perpetuas.
- Sistemas integrados de terceros (VxRail, SimpliVity y similares): no apliques el parche de vSphere por tu cuenta. Esos fabricantes controlan el nivel de parcheo como parte de su cualificación; la guía te la tienen que dar ellos.
Para comprobar en qué versión estás sin pelearte con la interfaz, la vía rápida es PowerCLI:
Lo que este aviso no es
No es un argumento para migrar. Lo decimos nosotros, que llevamos meses escribiendo sobre el éxodo de VMware que no acabó de ser tal y que hacemos migraciones a Proxmox para quien las necesita. Proxmox publica sus propios avisos de seguridad y también hay que parchearlo, con sus reinicios y sus ventanas. Cambiar de hipervisor por un aviso de julio es cambiar de sitio el trabajo, no eliminarlo.
La decisión de plataforma se toma con una hoja de cálculo, un inventario y un calendario de renovación delante, y a veces la respuesta correcta es quedarse. Lo que sí dice este aviso, sin margen de interpretación, es más simple: si tienes vSphere, esta semana tienes trabajo.
Fuentes (verificadas): los cinco CVE con su componente y su efecto, la ausencia de workarounds, el carácter acumulativo de los parches, el impacto de actualizar vCenter y ESX, la compatibilidad con Live Patch y la no disponibilidad de Quick Patch, el cambio de criterio sobre el orden vCenter/ESX con la matriz de interoperabilidad, la restricción «back in time» hacia VCF 9.x, el consejo de no cambiar a e1000 (con el hasta 40 % de mejora de E/S de los adaptadores paravirtualizados), la no necesidad de actualizar VMware Tools, el estado de vSphere 6.5/6.7/7/8, el acceso a parches críticos para clientes sin soporte vigente desde el 15 de abril de 2024 y los comandos de PowerCLI — documento oficial «VMSA-2026-0006: Questions & Answers» de Broadcom (29 de julio de 2026) y el aviso VMSA-2026-0006. Puntuaciones CVSS de 9,8 (CVE-2026-59309 y CVE-2026-59310) y 9,3 (CVE-2026-47876), y desglose por CVE: The Hacker News y SecurityOnline (29 de julio de 2026); la horquilla 2,7–9,8 del lote y el 2,7 de CVE-2026-41703 en Workstation y Fusion están en el documento oficial. La lectura de por qué un fallo de registro se subestima al ordenar por CVSS, la regla de marcar como poco fiable el periodo de logs anterior al parche y el criterio sobre la ventana de mantenimiento son nuestros. Imagen: sala de control de misiones restaurada (Wikimedia Commons, dominio público).
¿Quién decide en tu empresa qué se parchea primero?
En everyWAN mantenemos infraestructura de otros y llevamos la parte de seguridad de esos entornos, así que un aviso como este no se despacha reenviando el boletín del fabricante: es saber qué versiones tienes, decidir el orden con criterio y dejar por escrito qué se aplicó, cuándo y qué quedó pendiente —que es justo lo que te van a pedir en un incidente o en una auditoría de continuidad. Operamos VMware y Proxmox, y no vendemos licencias de ninguno. Si quieres una opinión sin comisión detrás, cuéntanos qué tienes montado.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN