CVE-2025-22224: VMware ESXi and Workstation TOCTOU Race Condition Vulnerability

CVE-2025-22224 is a time-of-check time-of-use (TOCTOU) race condition in VMware ESXi and Workstation that can produce an out-of-bounds write. An attacker who already holds local administrative privileges inside a virtual machine can use it to execute code in the context of that VM’s VMX process on the underlying host. This matters because it turns a compromised guest into a path for host-level code execution, undermining the isolation that hypervisors are meant to provide.

Defenders should treat the issue as a guest-to-host escape risk and confirm exact product versions, patches, and any configuration caveats directly against the vendor advisory.

How it works

The vulnerability is classified as CWE-367, a classic TOCTOU race condition. In this pattern the software checks a condition (for example, the state or bounds of a resource) and later uses the result of that check; an attacker who can change the underlying state between the check and the use can cause the software to operate on unexpected data. Here the race leads to an out-of-bounds write.

According to the CISA summary, successful exploitation requires local administrative privileges on a virtual machine. From that position the attacker can race the vulnerable code path so that the write occurs outside intended bounds, ultimately allowing code execution as the VMX process that runs on the host for that virtual machine. No further exploit mechanics are provided in the public summary; any additional technical detail must be taken from the vendor advisory rather than assumed.

Am I affected? How to find it in your systems

VMware ESXi is commonly deployed as a bare-metal hypervisor in data centers, private clouds, and virtualization clusters. VMware Workstation is typically installed on desktop or laptop hosts used for development, testing, or nested virtualization. Both products are in scope for this CVE.

• Inventory every ESXi host and every Workstation installation. Use your configuration-management database, hypervisor management console, or endpoint inventory tools to list installed products and their build or version strings.
• Compare those versions against the fixed releases listed in the vendor advisory; do not rely on version numbers published elsewhere.
• Note any nested or nested-like configurations (for example, Workstation running inside another hypervisor) because the same guest-to-host path may still apply.
• For detection of possible exploitation, look for anomalous behavior of the VMX process on the host—unexpected child processes, unusual memory or file activity associated with a particular VM, or sudden privilege-related events. Because the attack starts from inside a guest that already has administrative rights, also review guest OS logs for signs of prior compromise. Specific log signatures are not supplied in the public summary, so treat any such telemetry as investigative leads and validate them against vendor guidance.

How to remediate

The primary remediation is to apply the vendor-supplied update for the affected ESXi and Workstation releases. Follow the installation and reboot procedures documented in the vendor advisory.

• After patching, verify that the new build or version string matches the fixed release listed by the vendor.
• If you operate the products as a cloud service, also follow the applicable requirements of BOD 22-01 as noted by CISA.
• Where the advisory lists additional hardening steps (for example, configuration changes that reduce the attack surface of the VMX process), implement those as well.
• If mitigations are unavailable for a given deployment, CISA’s required action includes discontinuing use of the product until a fix can be applied.

If you can't patch immediately

Until the vendor update can be installed, reduce exposure with compensating controls that limit an attacker’s ability to reach or abuse the vulnerable path.

• Segment management and production networks so that compromised guests cannot easily pivot to other hosts or management interfaces.
• Restrict who can obtain local administrative privileges inside virtual machines; enforce least privilege and multi-factor authentication for guest admin accounts.
• Where the product allows it, disable or tightly control features that increase the attack surface of the VMX process; confirm any such options against the vendor advisory.
• Deploy host-based monitoring that watches for anomalous VMX process behavior and alert on unexpected code execution or privilege transitions.
• If a web application firewall or virtual-patching capability is available in front of management interfaces, apply any vendor- or community-provided signatures that address this class of race-condition issues, understanding that they are temporary and incomplete.
• Increase logging verbosity for hypervisor and guest administrative actions so that any later forensic review has useful data.

If your data may have been exposed

Vulnerabilities that allow guest-to-host code execution can be used as a foothold for broader compromise, including data theft or ransomware deployment, even though ransomware use of this specific CVE is not documented. If you have evidence of exploitation or simply want to check whether credentials associated with your environment have appeared in known breach data, you can run a free exposure scan of your email addresses against public breach corpora. Treat any positive hits as a prompt for credential rotation and further investigation rather than definitive proof that this CVE was involved.