CVE-2024-37079

What it actually does

CVE-2024-37079 is a network-reachable heap overflow in VMware vCenter Server’s DCERPC protocol implementation. An unauthenticated attacker with access to the vCenter Server management network can send a specially crafted DCERPC packet that corrupts heap memory and may allow arbitrary code execution in the context of the vulnerable vCenter service. Because the CVSS vector is AV:N/AC:L/PR:N/UI:N with high confidentiality, integrity, and availability impact, successful exploitation can result in full compromise of the vCenter control plane without credentials or user interaction.

Why it matters to the business

Compromise of vCenter is a high-impact operational event because vCenter manages virtualization infrastructure, including hosts, clusters, workloads, snapshots, and administrative roles. An attacker who gains code execution on vCenter may be able to disrupt virtual machine operations, tamper with infrastructure configuration, access sensitive management data, pivot into ESXi hosts or guest environments, and impair backup or recovery operations. This vulnerability is listed in CISA’s Known Exploited Vulnerabilities catalog, has active in-the-wild exploitation, and has a KEV remediation deadline of 2026-02-13, making remediation urgent even though ransomware use is not currently indicated in the provided data.

How an attack unfolds

An attacker first identifies a reachable VMware vCenter Server management interface and confirms that DCERPC services are exposed from a vulnerable build. Because the flaw does not require authentication, the attacker can interact directly with the DCERPC implementation over the network. The attacker sends a malformed DCERPC request designed to trigger heap memory corruption. If exploitation is reliable against the target version and platform state, the corrupted heap can be shaped to redirect execution flow and run attacker-controlled code within the vulnerable service process. After initial code execution, the attacker typically establishes persistence, stages tools, enumerates vCenter privileges and connected ESXi inventory, steals credentials or tokens available to the service context, and attempts lateral movement into the broader virtualization and management environment. Failed attempts may manifest as service crashes, core dumps, abnormal restarts, or heap-corruption errors before successful exploitation.

How to fix it

Upgrade VMware vCenter Server to a vendor-supported fixed release that addresses CVE-2024-37079. Where exact package-level fixed versions are managed internally, prioritize all vCenter 7.x and 8.x appliances or Windows installations exposed to untrusted or broad internal networks. If immediate patching is not possible, restrict DCERPC and vCenter management-plane access to dedicated administrative networks, enforce firewall allowlists, block unnecessary inbound access from user subnets and the internet, and monitor closely for service crashes or suspicious child processes. Do not rely on authentication controls alone because exploitation is unauthenticated. After patching, rotate sensitive credentials and review vCenter administrative roles, sessions, plugins, and trusted integrations if exposure existed before remediation.

How to confirm the fix worked

Confirm the installed vCenter Server build is at or above a vendor-fixed release for its branch and that no vulnerable vCenter instances remain in asset inventory, vulnerability scanner results, CMDB entries, or external attack-surface monitoring. Validate that vCenter management and DCERPC-accessible services are not reachable from the internet or broad user networks. Run authenticated vulnerability scans or vendor compliance checks where possible rather than relying only on banner detection. Confirm patch installation through the vCenter appliance management interface, CLI version checks, or lifecycle-management tooling. Review firewall policy to ensure only approved administrative sources can reach vCenter management ports. After remediation, verify that relevant vCenter services are stable and that no new crash dumps, abnormal restarts, or heap-corruption messages appear.

Typical attack path

1. Discover internet-exposed or internally reachable VMware vCenter Server management endpoints.
2. Probe for DCERPC availability and infer whether the vCenter version is vulnerable.
3. Send specially crafted unauthenticated DCERPC packets to trigger the heap overflow.
4. Achieve code execution or cause repeated service crashes while tuning exploitation.
5. Execute post-exploitation commands in the context of the vulnerable vCenter service.
6. Collect local configuration, credentials, tokens, certificates, or inventory data useful for virtualization control.
7. Pivot to ESXi hosts, management systems, backup platforms, or guest workloads reachable from vCenter.
8. Establish persistence, deploy additional tooling, exfiltrate data, or disrupt virtual infrastructure operations.

How to detect it

To determine whether exploitation already occurred, correlate network, host, and application telemetry around vCenter. Review firewall, NetFlow, IDS, packet-capture, and load-balancer logs for unexpected inbound DCERPC traffic to vCenter, especially from internet addresses, user workstations, VPN pools, partner networks, or hosts that do not normally administer virtualization infrastructure. Inspect vCenter logs such as vpxd, vmon, appliance syslog, SSO, and directory-service logs for crashes, abnormal restarts, heap-corruption messages, segmentation faults, or unexplained service instability. Check Linux system logs, journald, core-dump locations, and appliance support bundles for crash artifacts around the same timestamps as suspicious network activity. Hunt EDR telemetry for unusual child processes launched by VMware service processes, such as shells, interpreters, download utilities, archive tools, credential-dumping utilities, or reverse-connection tooling. Review outbound network connections from the vCenter host to unfamiliar destinations, newly created local users, changes to vCenter roles or permissions, new SSO identities, suspicious plugins, unexpected scheduled tasks, and modified startup scripts. Because successful exploitation may leave limited application-layer evidence, absence of logs is not proof of non-exploitation; prioritize timeline correlation among DCERPC network activity, process execution, crashes, authentication changes, and administrative actions.

• DCERPC
• DCE/RPC
• ncacn_ip_tcp
• TCP/135
• segmentation fault
• core dumped
• heap corruption
• malloc(): corrupted
• double free or corruption
• /var/log/vmware/vpxd/vpxd.log
• /var/log/vmware/vmon/vmon.log
• /var/log/vmware/sso/
• /var/log/vmware/vmdird/
• /var/core/
• /storage/core/
• /bin/sh
• /bin/bash
• /usr/bin/curl
• /usr/bin/wget
• /usr/bin/python
• /usr/bin/perl
• /usr/bin/nc
• vpxd
• vmon
• vmdird
• vmafdd

What your security team should do

• Treat this as a priority-one remediation item for any reachable vCenter Server because it is unauthenticated remote code execution, has a 9.8 CVSS score, has active in-the-wild exploitation, and is listed in CISA KEV.
• Immediately inventory all VMware vCenter Server instances, including lab, disaster-recovery, management, and subsidiary environments.
• Patch or upgrade all affected vCenter instances to fixed vendor-supported releases; prioritize internet-exposed, partner-accessible, VPN-accessible, and flat-network deployments first.
• Until patching is complete, restrict access to vCenter management and DCERPC services using network segmentation, firewall allowlists, VPN controls, and administrative jump hosts.
• Search historical logs and network telemetry for DCERPC connections, malformed RPC activity, service crashes, core dumps, and suspicious process execution on vCenter hosts since at least the publication date of 2024-06-18.
• If exploitation is suspected, isolate the vCenter Server from nonessential networks, preserve forensic evidence, rotate credentials and certificates that may be exposed, and assess connected ESXi hosts and management integrations.
• Add detections for abnormal child processes, outbound connections, file writes, and authentication changes originating from vCenter service accounts or processes.
• Review vCenter administrative users, roles, sessions, SSO configuration, plugins, scheduled tasks, and trusted integrations for unauthorized changes.