CVE-2025-22224

What is VMware ESXi?

VMware ESXi is Broadcom's bare-metal hypervisor, the most widely deployed enterprise server virtualization platform globally. ESXi runs directly on physical server hardware and hosts multiple virtual machines (VMs). Because ESXi has complete control over all VMs running on the host — including their memory, CPU, network, and storage — a vulnerability that allows code execution on the ESXi hypervisor (escaping from a VM) gives an attacker control over every VM on that host. In large deployments, ESXi hosts may run hundreds of VMs, including domain controllers, databases, and critical business applications.

Overview

CVE-2025-22224 is a critical TOCTOU (Time-of-Check Time-of-Use) race condition vulnerability (CWE-367, CVSS 9.3) in VMware ESXi and VMware Workstation. An attacker with local administrative privileges on a guest VM can exploit the race condition to trigger an out-of-bounds write in the VMX process — the per-VM process running on the ESXi host. Successful exploitation achieves code execution as the VMX process on the hypervisor, constituting a VM escape (Scope:Changed, S:C). The vulnerability was disclosed as part of VMSA-2025-0004 alongside CVE-2025-22225 and CVE-2025-22226, all confirmed as zero-days exploited in the wild. Microsoft Threat Intelligence confirmed nation-state exploitation.

Affected Versions

Technical Details

The vulnerability (CWE-367: Time-of-Check Time-of-Use Race Condition) is in the VMX process — ESXi's per-VM process that handles hardware emulation for guest VMs. A TOCTOU race condition occurs when a resource's state is checked at one point in time but may change before the check's result is acted upon. In this case, a specific memory region or device state is validated by the VMX process, then accessed again after the state has been modified by the guest VM (racing between the check and the use). This inconsistency causes an out-of-bounds write to memory outside the intended buffer, which the attacker can exploit to overwrite VMX process memory with attacker-controlled data, ultimately gaining code execution on the ESXi host.

The attack requires local administrative access inside a guest VM (e.g., Windows domain administrator or Linux root) — but not hypervisor-level credentials. This makes CVE-2025-22224 a particularly dangerous "guest-to-host" escape: an attacker who compromises any VM on the host can then escape to the hypervisor.

CVE-2025-22224 was part of a trio in VMSA-2025-0004:

• CVE-2025-22224 (this CVE): TOCTOU → OOB write → VMX process code execution (VM escape)
• CVE-2025-22225: Arbitrary write vulnerability (CVSS 8.3) — similar guest-to-VMX-process write primitive
• CVE-2025-22226: HGFS information disclosure (CVSS 7.1) — memory information leak across VMs

Discovery

Microsoft Threat Intelligence Center (MSTIC) reported all three VMSA-2025-0004 vulnerabilities to VMware/Broadcom. The reporting of multiple simultaneous related bugs by Microsoft's threat intel team indicates these were discovered through analysis of an active exploit chain in the wild.

Exploitation Context

Broadcom confirmed "information available that exploitation of these issues has occurred in the wild" — the standard acknowledgment of zero-day status. Microsoft Threat Intelligence confirmed nation-state actor exploitation of the three-CVE chain in targeted attacks against government and enterprise environments. CISA added all three CVEs to the KEV catalog on the same day as the Broadcom advisory (4 March 2025), indicating CISA had prior knowledge of active exploitation. The 21-day remediation deadline (25 March 2025) reflects the severity of confirmed exploitation of critical virtualization infrastructure.

Remediation

1. Apply VMSA-2025-0004 patches immediately: ESXi 8.0 U3d, 8.0 U2e, 7.0 U3s, Workstation 17.6.3, Fusion 13.6.3.
2. Patch all three VMSA-2025-0004 CVEs (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226) — all are addressed in the same update.
3. Prioritize internet-accessible or untrusted-guest ESXi hosts — environments where VMs from less-trusted sources run are at highest risk.
4. Enforce least-privilege inside VMs: do not grant unnecessary local admin rights within guest VMs; this raises the bar for the guest-side prerequisite.
5. Monitor ESXi logs for unexpected VMX process crashes, unusual memory access patterns, or signs of guest-to-host breakout.
6. vSphere deployments: check VMware vCenter for ESXi version compliance across all hosts in the cluster.