CVE-2024-37079

Think of VMware vCenter Server as the control room that manages your virtual machines. This vulnerability is like a weakness in one of the “communication doors” (DCERPC) where a crafted message can overflow memory and potentially let an attacker take control. Because CISA lists it as actively exploited, it’s a high-risk issue for organizations using these systems.

This matters to you if you operate VMware vCenter Server or VMware Cloud Foundation (which includes vCenter components). It’s relevant when an attacker can reach vCenter Server over the network, because the flaw is triggered remotely by sending specially crafted network packets. In practice, treat it as a risk when vCenter is reachable from untrusted networks (for example, the internet or other networks you don’t fully control), not only when you’ve already been hacked.

This is RED because CISA has confirmed real-world exploitation and added it to the KEV list. That means attackers are actively targeting vulnerable VMware vCenter Server deployments, including ransomware groups. You should patch to the fixed versions by the CISA due date to close the attacker’s path quickly.

1. Confirm exposure

   • Identify whether you run: VMware vCenter Server and/or VMware Cloud Foundation.
   • Record the exact version/patch level of vCenter Server (and the relevant Cloud Foundation/vCenter components).
   • Determine whether vCenter Server is reachable from outside your fully trusted admin networks (public internet, VPN entry points, partner/vendor networks, or any network where an attacker could gain network access).

2. Check whether you are on affected versions

   • If your version is not one of the fixed versions below, assume you may be exposed and validate against Broadcom’s security advisory for your exact branch.

3. Upgrade to the fixed versions (target state)

   • VMware Cloud Foundation: fixed in 5.2.
   • VMware vCenter Server: fixed in 8.0 U2d, 8.0 U1e, or 7.0 U3r.
   • Follow the official upgrade/patch procedure for your deployment topology (single site vs. multi-site) and any documented sequencing requirements for vCenter/Cloud Foundation components.

4. If patching is delayed (temporary containment)

   • Apply the vendor’s mitigations from Broadcom’s security advisory.
   • Reduce network reachability to vCenter Server immediately (only allow access from required management networks/bastions; block access from untrusted networks).

5. Due date and follow-up

   • CISA remediation due date for KEV: 2026-02-13.
   • After patching, verify vCenter services are healthy and that network exposure remains restricted.
   • Monitor for suspicious activity around vCenter/DCERPC-related traffic and any signs of attacker presence in your environment (for example, unexpected administrative actions or new scheduled tasks/automation—based on your internal monitoring practices).

Severity is critical (reported as 9.8) and this is tracked as a heap-overflow issue (CWE-787) in VMware vCenter Server’s DCERPC protocol implementation. The mechanism is that an attacker with network access can send specially crafted packets that trigger the overflow, which can lead to high-impact outcomes (including takeover-level effects).

Exploitation status: CISA KEV confirms real-world exploitation, added in 2026-01-23, with a remediation due date of 2026-02-13. This pushes the urgency above prediction-based risk models.

Exploit availability: the findings state no public exploit code is on record, but that does not reduce risk given confirmed exploitation.

Mitigation/patching: the vendor’s fixed versions are 5.2 for cloud foundation and 8.0 U2d / 8.0 U1e / 7.0 U3r for VMware vCenter Server, as listed in the patch findings. KEV means CISA has validated exploitation and expects organizations to apply mitigations or discontinue use if fixes/mitigations aren’t available.