VMware ESXi and Workstation, TOCTOU out-of-bounds write to VMX RCE (ESXi VMX Sandbox Escape)
VMware ESXi and Workstation contain a Time-of-Check Time-of-Use (TOCTOU) race condition vulnerability that leads to an out-of-bounds write. A malicious actor with local administrative privileges on a guest virtual machine can exploit the flaw to execute code as the virtual machine's VMX process running on the host. This constitutes a virtual machine sandbox escape from guest to hypervisor host.
Overview
CVE-2025-22224 is a critical-impact virtualization escape affecting VMware ESXi and Workstation, disclosed by Broadcom in advisory VMSA-2025-0004. It is a Time-of-Check Time-of-Use (TOCTOU) race condition (CWE-367) that leads to an out-of-bounds write. An attacker who already holds local administrative privileges inside a guest virtual machine can exploit the flaw to run code as the host-side VMX process, escaping the VM sandbox and reaching the hypervisor. NVD scores it 8.2 (HIGH) as the primary metric, while VMware/Broadcom rate it 9.3 (CRITICAL) as a secondary score reflecting an unprivileged-attacker assumption. The Microsoft Threat Intelligence Center reported the issue to VMware, Broadcom confirmed exploitation in the wild, and CISA added it to the Known Exploited Vulnerabilities catalog on March 4, 2025. No workarounds exist; patching is the only remediation.
Technical Details
The vulnerability is a race condition between the time a value is validated and the time it is used (TOCTOU), which an attacker can win to trigger an out-of-bounds write in the VMX process. VMX is the user-space host process that backs each running virtual machine and mediates virtual device emulation. By corrupting memory in VMX, an attacker with administrative control of the guest can achieve arbitrary code execution in the context of that host-side process, crossing the guest-to-host trust boundary. The NVD primary vector is local (AV:L), low complexity (AC:L), requires high privileges in the guest (PR:H), no user interaction (UI:N), with a changed scope (S:C) and high impact to confidentiality, integrity, and availability (C:H/I:H/A:H), producing a base score of 8.2. The changed scope reflects that the impact (the host VMX process and hypervisor) lies outside the security authority of the vulnerable component (the guest VM). Because the prerequisite is access inside a guest, internet-facing exposure is not required; any tenant or compromised VM on a shared host is a viable launch point.
Impact
- Out-of-bounds write in the host-side VMX process triggered from a guest virtual machine.
- Code execution on the ESXi/Workstation host as the VMX process, escaping the VM sandbox.
- Compromise of the hypervisor host and, by extension, every other virtual machine it runs (changed scope).
- In multi-tenant or consolidated environments, a single compromised guest can lead to full host and cross-tenant compromise.
- High impact to confidentiality, integrity, and availability of the host and co-resident workloads.
Mitigation
- Upgrade VMware ESXi 8.0 to build ESXi80U3d-24585383 (8.0 U3d) or ESXi80U2d-24585300 (8.0 U2d), as applicable to your update line.
- Upgrade VMware ESXi 7.0 to build ESXi70U3s-24585291 (7.0 U3s) or later.
- Upgrade VMware Workstation 17.x to version 17.6.3 or later.
- For VMware Cloud Foundation and Telco Cloud Platform/Infrastructure, apply the corresponding fixed ESXi async patch per VMSA-2025-0004 and the Broadcom KB guidance for your deployment.
- There are no workarounds; prioritize patching of all hosts, and after patching, treat any host that ran an unpatched build with hostile guests as potentially compromised and investigate accordingly.
Detection
Start with an authoritative inventory of hypervisor builds. Map every ESXi host and Workstation install to its current build number and compare against the fixed builds (ESXi80U3d-24585383, ESXi80U2d-24585300, ESXi70U3s-24585291, Workstation 17.6.3). Any host below the relevant fixed build is vulnerable. Prioritize hosts that run untrusted, multi-tenant, or internet-adjacent guest workloads, since those provide the in-guest foothold the exploit requires.
Detection is challenging because exploitation originates inside a guest and manifests on the host. On ESXi, monitor the VMX and hostd logs (vmware.log per VM and the host's hostd.log/vmkernel.log) for VMX process crashes, unexpected restarts, or core dumps coinciding with guest activity; a sudden VMX termination or panic tied to a specific VM can indicate an attempted or successful out-of-bounds write. Watch for unexpected processes or files appearing on the ESXi host, modifications under datastore or host filesystem paths that VMX would not normally write, and anomalous outbound connections from the host management interface.
Because the Microsoft Threat Intelligence Center reported this as part of an exploited chain, correlate host-side anomalies with signs of compromise inside guests: privilege escalation, new local administrators, or malware execution in a VM shortly before host-side VMX instability. Enable and centralize ESXi logging to a remote syslog collector so that evidence survives a host compromise, and alert on VMX core-dump generation and on changes to host accounts, SSH/shell access state, or installed VIBs.
Given the KEV listing and confirmed in-the-wild use, assume that any unpatched host exposed to a compromised or hostile guest may already be targeted. Before remediation, preserve vmware.log, hostd.log, vmkernel.log, and any VMX core dumps for forensic review. After upgrading, validate the running build on each host, audit the host for unauthorized changes (accounts, VIBs, startup scripts), and verify that virtual machines have not been tampered with. Maintain monitoring for repeated VMX crashes after patching, which would warrant deeper investigation.