VMware vCenter RCE Vulnerability (CVE-2024-37079) — Active Exploitation in CISA KEV, Urgent Patch Guide
TL;DR: VMware vCenter Server has a critical CVE-2024-37079 (CVSS 9.8) heap overflow in the DCERPC protocol implementation, allowing unauthenticated remote code execution. Network access is sufficient. It’s in CISA’s KEV catalog; federal patching deadline has passed. No workaround exists; the only fix is to patch: upgrade to vCenter 8.0 U2d, 8.0 U1e, or 7.0 U3r.
Affected and patched versions
| vCenter Server Version | Affected | Patched Version | Urgency |
|---|---|---|---|
| vCenter 7.0 — < 7.0 U3r | ✅ Yes | vCenter 7.0 U3r | 🔴 Critical |
| vCenter 8.0 — < 8.0 U1e | ✅ Yes | vCenter 8.0 U1e | 🔴 Critical |
| vCenter 8.0 — < 8.0 U2d | ✅ Yes | vCenter 8.0 U2d | 🔴 Critical |
| vCenter 6.5 / 6.7 | ⚠️ EOL | — | Migration required |
| VMware Cloud Foundation (VCF) 4.x, 5.x | ✅ Yes | VCF 5.1.1+ | 🔴 Critical |
⚠️ Pre-patch must-dos
- Take a vCenter snapshot (file-based or VM snapshot) — critical for rollback
- Config backup via VAMI:
https://<vcenter>:5480 → Backup → Backup Now(SFTP/FTPS target) - Don’t put ESXi hosts in maintenance mode — vCenter patch doesn’t touch ESXi
- Schedule during low-traffic window (patch takes 30-60 min, vCenter briefly offline)
- Inform vSphere Client users (no access during patching)
What’s the vulnerability? Why 9.8?
CVE-2024-37079 is an out-of-bounds write (heap overflow) in the DCERPC (Distributed Computing Environment / Remote Procedure Call) protocol implementation in vCenter Server. An attacker sends a specially crafted packet to vCenter’s TCP/2012 or TCP/2014 port over the network; heap memory overflow triggers, and remote code executes as the privileged user (typically root).
Why CVSS 9.8:
- Attack vector: network (AV:N)
- Attack complexity: low (AC:L)
- Privileges required: none (PR:N) — no authentication!
- User interaction: none (UI:N)
- Impact: Confidentiality + Integrity + Availability all high (C:H/I:H/A:H)
Patch step-by-step — vCenter Server Appliance (VCSA)
- Download patch from Broadcom Support Portal (no longer VMware portal):
https://support.broadcom.com→ vSphere → vCenter Server → 8.0 U2d patch ISO - Upload the
.isoto a datastore on one of vCenter’s ESXi hosts - Mount the ISO to vCenter VM’s CD/DVD drive in VM settings
- Log into VAMI:
https://<vcenter>:5480(userroot) - Go to Update tab → Check Updates → the CDROM option appears
- Click Stage and Install; accept EULA
- Pre-update check runs (~5 min); if no errors, click Install
- vCenter reboots (~10-20 min downtime); vSphere Client also briefly inaccessible
- Verify version in VAMI post-patch: build number should show 8.0.2.00400 (U2d) or similar
Post-patch verification
# vCenter version check (CLI)
ssh root@<vcenter>
vpxd -v
# Are new DCERPC service binaries loaded?
rpm -qa | grep vmware-vpxd
# Health check
service-control --status --all | grep -i stopped
# Nothing should be 'Stopped'
- Verify all clusters and hosts are visible in vSphere Client web UI
- HA/DRS functional: vMotion a test VM to another host
- vCenter Server logs error-free:
/var/log/vmware/vpxd/vpxd.log - External Identity Provider (AD FS, Okta) integration working
Detection: was I exploited?
CVE-2024-37079 is actively exploited. If you suspect pre-patch compromise:
- Check anomalous SSH sessions: scan
/var/log/secure*and/var/log/auth.logfor the last 30 days - Any newly created local users in vCenter: VAMI → Administration → SSO Configuration → Users
- Newly added scripts/binaries in vCenter VM filesystem:
find / -mtime -30 -type f ( -name "*.sh" -o -name "*.py" -o -perm -u+x ) 2>/dev/null - Unexpected outbound connections from vCenter in network logs, especially outside 443/80
- If in doubt, reinstall vCenter from scratch and do not restore old config — could harbor a backdoor
Common issues
- “Pre-update check reports ‘/storage/seat’ disk full.” SEAT (Stats, Events, Alarms, Tasks) DB partition is full. Clean or expand
/storage/seat(grow VMDK + LVM extend). - “Update CD-ROM not visible.” Check ISO mount. vCenter VM’s “Connect at Power On” — it must be “Connected” not just selected.
- “vSphere Client won’t open after patch.” Clear cache (try browser private mode). If certificate changed, refresh Trust Store.
- “Performance degraded after VCSA patch.” Check long-running operations in
/var/log/vmware/vpxd/profiler/. Usually a DB defrag is needed:vcenter-recovery-tool db-reindex.
Preventive recommendations (for the future)
- Keep vCenter management network on a separate VLAN; never directly internet-accessible
- Require vSphere Client access via VPN or bastion host
- Apply firewall whitelisting for vCenter VAMI (5480) and APIs
- Follow Broadcom Support Portal via RSS feed or security mailing list (VMSA-XXXX-XXXX advisories)
- Run automated weekly snapshot task (file-based config backup)
VMware / Broadcom vSphere support
Need help with vCenter patch planning, compromise detection, ESXi cluster health audit, or Broadcom Cloud Foundation migration? We have provided virtualization consulting across Turkey since 1998.




