Broadcom (VMware) ha actualizado su aviso de seguridad VMSA-2024-0012.1 con una nota especialmente relevante para equipos de infraestructura: hay indicios de explotación en la naturaleza (in the wild) de CVE-2024-37079, una de las vulnerabilidades críticas que afectan a VMware vCenter Server. La actualización del aviso está fechada el 23 de enero de 2026, por lo que el mensaje es inequívoco: parchear ya no es una recomendación, es una prioridad operativa.
El advisory agrupa tres CVEs: dos vulnerabilidades de heap-overflow en la implementación del protocolo DCERPC (asociadas a posible ejecución remota de código) y una vulnerabilidad de escalada local de privilegios derivada de una misconfiguración de sudo.
Qué se ha publicado exactamente
A nivel técnico y de impacto, el aviso cubre:
- CVE-2024-37079 y CVE-2024-37080 (Críticas, CVSS 9,8):
Vulnerabilidades de heap-overflow en DCERPC. Un actor con acceso de red podría desencadenarlas mediante paquetes especialmente diseñados, con riesgo de RCE (según evaluación del propio fabricante). - CVE-2024-37081 (Importante/Crítica en el advisory, CVSS 7,8):
Escalada local de privilegios: un usuario autenticado local sin privilegios administrativos podría elevar a root en el vCenter Server Appliance.
Además, la actualización del 23 de enero de 2026 añade una línea que cambia el contexto de riesgo: “Broadcom has information to suggest that exploitation of CVE-2024-37079 has occurred in the wild.”
Como señal adicional de criticidad operacional, el registro del NVD refleja que CVE-2024-37079 fue añadida al catálogo CISA KEV con fecha 23 de enero de 2026, con fecha límite de remediación fijada por CISA.
Tabla 1 — Resumen ejecutivo (lo imprescindible)
| Elemento | Detalle |
|---|---|
| Advisory | VMSA-2024-0012.1 (actualizado 23/01/2026) |
| Productos afectados | VMware vCenter Server; VMware Cloud Foundation |
| CVEs | CVE-2024-37079, CVE-2024-37080, CVE-2024-37081 |
| Impacto principal | RCE (red) en DCERPC + elevación local a root |
| Severidad | Crítica (hasta 9,8 CVSS); 7,8 para LPE |
| Explotación activa | Indicada para CVE-2024-37079 “in the wild” |
| Workaround | Para RCE (37079/37080) se indica que no es viable; para 37081 no hay workaround |
Tabla 2 — Versiones corregidas (matriz de respuesta del fabricante)
| Plataforma | Línea | CVEs cubiertas | Corrección indicada |
|---|---|---|---|
| vCenter Server | 8.0 | 37079/37080/37081 | vCenter 8.0 U2d |
| vCenter Server | 8.0 | 37079/37080 | vCenter 8.0 U1e |
| vCenter Server | 7.0 | 37079/37080/37081 | vCenter 7.0 U3r |
| Cloud Foundation (vCenter) | 5.x / 4.x | 37079/37080/37081 | KB88287 |
Por qué esto es especialmente delicado en vCenter
vCenter suele ser el plano de control del virtualizado: inventario, permisos, aprovisionamiento, redes virtuales, almacenamiento y operaciones. Eso hace que, incluso cuando el fallo “solo” afecta a un componente, el impacto potencial sea desproporcionado frente a otros servicios: una caída o una toma de control puede traducirse en pérdida de control operativo, interrupciones de servicio y movimiento lateral.
La clave aquí es la combinación de factores reconocidos en el advisory:
- Vector de red (para los CVEs críticos DCERPC)
- Severidad crítica (9,8)
- Indicios de explotación real (al menos para CVE-2024-37079)
Qué deberían hacer los equipos de sistemas (orden de prioridad)
- Inventariado inmediato
- Localizar todos los vCenter y entornos Cloud Foundation (incluyendo DR/BCP y laboratorios conectados a redes corporativas).
- Priorizar por exposición
- Aislar si existe cualquier ruta de red innecesaria hacia vCenter (segmentación, ACLs, bastión, VPN, salto administrado). Aunque el advisory hable de “network access”, la práctica segura es tratar vCenter como servicio solo de red de gestión.
- Aplicar el parche correcto
- vCenter 8.0 → U2d (o U1e si aplica a tu rama/caso)
- vCenter 7.0 → U3r
- Cloud Foundation 4.x/5.x → KB88287
- Verificación post-cambio
- Confirmar versión y estado de servicios, y revisar logs de integridad/operación.
- Mantener vigilancia reforzada tras el parche (las ventanas de explotación suelen intensificarse tras la difusión).
- Reducir riesgo operacional
- Revisar accesos privilegiados a VCSA, MFA donde aplique, y endurecimiento del plano de gestión.
- Alinear con procedimientos internos de gestión de vulnerabilidades (SLA crítico).
