VMCI integer underflow enables out-of-bounds write in VMware ESXi, Workstation, and Fusion

VMware ESXi, Workstation, and Fusion contain an integer-underflow in VMCI (Virtual Machine Communication Interface) that leads to an out-of-bounds write. A malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine's VMX process running on the host. On ESXi, the exploitation is contained within the VMX sandbox whereas, on Workstation and Fusion, this may lead to code execution on the machine where Workstation or Fusion is installed.

The supplied evidence and Broadcom response matrix identify the following scope:

• VMware ESXi 8.0: versions in the listed branches are affected when less than ESXi80U3f-24784735 or less than ESXi80U2e-24789317, depending on the update line.
• VMware ESXi 7.0: versions less than ESXi70U3w-24784741 are affected.
• VMware Workstation 17.x: versions less than 17.6.4 are affected, and the response matrix lists 17.6.4 as the fixed version.
• VMware Fusion 13.x: the normalized record marks the branch as affected with lessThanOrEqual 13.6.4, while Broadcom's response matrix lists 13.6.4 as the fixed version. This is a boundary inconsistency that should be verified during asset assessment.
• VMware Cloud Foundation: 9.0.0.0, 5.x, and 4.5.x are recorded as affected. For 9.0.0.0, the response matrix lists fixed build ESXi-9.0.0.0100-24813472; for 5.x, the target is an asynchronous patch to ESXi80U3f-24784735; for 4.5.x, the target is an asynchronous patch to ESXi70U3w-24784741.
• VMware vSphere Foundation: 9.0.0.0 is recorded as affected, with fixed build ESXi-9.0.0.0100-24813472.
• VMware Telco Cloud Platform: 5.x and 4.x have target ESXi80U3f-24784735; 3.x and 2.x have target ESXi70U3w-24784741.
• VMware Telco Cloud Infrastructure: 3.x and 2.x have target ESXi70U3w-24784741.

Branches or versions not listed here should not be assumed to be unaffected solely from this evidence.

VMware ESXi, Workstation, and Fusion contain an integer underflow in VMCI, the Virtual Machine Communication Interface, leading to an out-of-bounds write. The advisory states that an attacker must have local administrative privileges within a virtual machine to drive malicious VMCI activity into the VMX process running on the host. On ESXi, exploitation is described as contained within the VMX sandbox. On Workstation and Fusion, the flaw may enable code execution on the machine where the product is installed. The record identifies CWE-787, but does not identify the specific VMCI message, field, operation, or memory layout involved. The supplied scoring metadata describes local access, low complexity, and no user interaction, but marks privileges as none while the narrative explicitly requires local administrative privileges in the virtual machine. This entry follows the explicit attack precondition in the advisory.

The issue is locally reachable from inside a virtual machine through VMCI activity. Broadcom states that the attacker has local administrative privileges on the virtual machine; the structured scoring metadata differs on the privilege requirement, so deployment context should be checked before automating exposure decisions. The supplied metadata describes low attack complexity and no user interaction. Broadcom says the issue was privately reported and credits Corentin BAYET of REverse Tactics in work associated with Pwn2Own. The supplied record marks public exploit status as false and does not establish a known-exploited status. Those fields do not prove that exploitation is impossible in a particular environment.

The flaw can cause an out-of-bounds write in VMCI and may result in code execution as the virtual machine's VMX process on the host. On ESXi, the vendor limits the described result to the VMX sandbox, so the available evidence is insufficient to conclude that the issue provides host escape or execution outside that sandbox. On Workstation and Fusion, the result may extend to code execution on the installed machine, with possible effects on that machine's confidentiality, integrity, and availability. The described attack requires local access from a virtual machine and local administrative privileges in the guest; the supplied metadata describes low complexity and no user interaction. Exploit reliability, the exact overwritten data, and the precise scope under each configuration are not established by the available evidence.

The flaw weakens the boundary between guest activity and the virtualization product's VMX process. For VMware ESXi, Broadcom states that exploitation is contained within the VMX sandbox, so the available evidence does not confirm escape from that sandbox or arbitrary code execution across the entire ESXi host. For VMware Workstation and Fusion, the flaw may lead to code execution on the installed machine, creating possible confidentiality, integrity, and availability consequences for that host. Cloud Foundation, vSphere Foundation, and Telco Cloud deployments require the corresponding ESXi or asynchronous patch target so that managed infrastructure is not left on an affected branch.

1. Apply the branch-specific fix: update VMware ESXi 8.0 to ESXi80U3f-24784735 or ESXi80U2e-24789317 according to the active update line, and update ESXi 7.0 to ESXi70U3w-24784741.
2. Update VMware Workstation 17.x to 17.6.4 and VMware Fusion 13.x to 13.6.4. Because the Fusion range in the normalized record differs from the fixed-release presentation in the advisory, verify the installed package status with Broadcom before closing the finding.
3. For VMware Cloud Foundation and vSphere Foundation 9.0.0.0, apply fixed build ESXi-9.0.0.0100-24813472 to the corresponding ESX component.
4. For VMware Cloud Foundation 5.x and 4.5.x, perform the asynchronous patches to ESXi80U3f-24784735 and ESXi70U3w-24784741, respectively. For Telco Cloud Platform, use ESXi80U3f-24784735 for 5.x and 4.x, or ESXi70U3w-24784741 for 3.x and 2.x. For Telco Cloud Infrastructure 3.x and 2.x, use ESXi70U3w-24784741.
5. Broadcom states that no workaround is available. Do not treat guest permission changes, disabling an unspecified component, or monitoring alone as a vendor-confirmed fix.
6. After patching, verify the actual build on each host or workstation, confirm completion of asynchronous patching, and continue reviewing guest administrative access until all affected assets are remediated.

1. Inventory deployments of VMware ESXi, Workstation, Fusion, Cloud Foundation, vSphere Foundation, Telco Cloud Platform, and Telco Cloud Infrastructure, then compare installed versions or builds with the affected branches and remediation targets in affected_summary.
2. Identify virtual machines where untrusted users or accounts have local administrative privileges, because this is the attack precondition stated by the advisory.
3. Review hypervisor and host telemetry for abnormal VMX process behavior, crashes, or unusual execution originating from a guest. Treat this as precautionary monitoring, not as a vendor-confirmed indicator.
4. No product-specific IOC or distinctive log event is established by the available evidence. Absence of suspicious logs does not prove safety, so version and build verification should take priority.