CVE-2024-37079: VMware vCenter Server heap-overflow RCE, in CISA KEV
The short version: CVE-2024-37079 is a heap-overflow vulnerability in the DCERPC protocol implementation of VMware vCenter Server. An attacker with network access to vCenter can send a specially crafted packet to trigger it, potentially leading to remote code execution on the appliance that manages your ESXi hosts and virtual machines. It scores 9.8 and it's in CISA's Known Exploited Vulnerabilities catalog. Patch-and-verify. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice and on paper |
| CVSS v3.1 (NVD) | 9.8 — Critical · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | 22.38% · 97.43th percentile (2026-07-17) |
| In CISA KEV? | Yes — added 2026-01-23, remediation due 2026-02-13 |
| Known exploited? | Yes — listed in CISA KEV as known-exploited |
| Vulnerability type | CWE-787 out-of-bounds write / heap overflow in DCERPC → remote code execution |
| Requires authenticated session? | No — network access to vCenter is sufficient |
| Affected | vCenter Server 7.0 and 8.0; VMware Cloud Foundation 4.x and 5.x |
| Fixed in | The fixed vCenter 7.0 / 8.0 builds in VMSA-2024-0012 (and later); apply the matching Cloud Foundation async patches |
What you need to know
vCenter Server is the management plane for a VMware environment. CVE-2024-37079 is one of a family of memory-corruption flaws in vCenter's DCERPC protocol implementation: a crafted network packet overflows a heap buffer, and that corruption can be steered into code execution on the vCenter appliance.
Why it's a top-priority item:
- It's the control plane. Code execution on vCenter reaches every ESXi host and VM it manages.
- It's unauthenticated over the network. No credential required — only reachability, which is why vCenter should never be internet-facing.
- It's known-exploited. CISA added it to the KEV catalog, so treat it as operational risk, not a theoretical one.
How serious we see it
High — the 9.8 is warranted.
Unauthenticated, network-reachable code execution on the appliance that controls your virtual estate is top-of-queue, and KEV listing removes any doubt about whether it matters in the real world. The bounded, reassuring part is that it's narrow and fixable: it affects specific vCenter builds, Broadcom has published fixes, and you can determine quickly whether you're affected. The catch is the usual one — patched and clean are different questions, so verify exposure and hunt if vCenter was reachable.
Recommendations
Straight from Broadcom's advisory (VMSA-2024-0012) and CISA:
- Patch now. Upgrade vCenter Server to the fixed 7.0 / 8.0 builds named in the advisory, and apply the corresponding Cloud Foundation patches.
- Confirm exposure and hunt. Determine whether vCenter was reachable by untrusted hosts, and review for signs of exploitation.
- If compromised, respond. Rotate vCenter credentials and secrets, and investigate connected ESXi hosts and VMs.
- Harden exposure. Keep vCenter off the internet; restrict management access to trusted networks and enforce MFA.
- Confirm your exposure first. Verify whether you run an affected vCenter build at all.
How BreachRisk sees it
BreachRisk works from the outside in. From little more than your domain it discovers internet-facing VMware management surfaces, fingerprints the vCenter product and version, and flags exposure tied to KEV-listed vulnerabilities like this one — surfaced at the top of your results because it's actively exploited. We detect and prioritize the exposed, affected appliance; we don't exploit the memory-corruption bug.
The value of a continuous, attacker's-eye view is exactly this: a vCenter that should be internal but is reachable from the internet is already mapped, so you can go straight to patch-and-verify.