CVE-2025-22224

What it actually does

This vulnerability is a time-of-check/time-of-use race condition in VMware ESXi and VMware Workstation that can result in an out-of-bounds write in the host-side virtual machine execution context. An attacker who already has local administrative privileges inside a guest virtual machine can abuse the flaw to execute code in the VMX process on the host. Because the VMX process mediates the running VM from the host side, successful exploitation can break the intended isolation boundary between guest and host and may allow host-level code execution in the context of that VM process.

Why it matters to the business

The flaw creates a high-impact virtualization escape risk: compromise of one virtual machine can potentially lead to code execution on the underlying virtualization host process, threatening workload isolation, confidentiality, and availability of co-resident systems. It is listed in CISA KEV and has active in-the-wild exploitation, so remediation should be treated as urgent even though exploitation requires administrative control of a guest VM first. Organizations relying on ESXi or Workstation for sensitive workloads, lab environments, developer endpoints, or shared virtualization infrastructure face increased risk of lateral movement, host compromise, service disruption, and incident response complexity. CISA’s KEV remediation deadline was 2025-03-25, so any remaining exposure is overdue.

How an attack unfolds

An attacker first gains administrative privileges inside a guest virtual machine through stolen credentials, malware, exploitation of an application in the VM, or abuse of legitimate admin access. From that privileged guest position, the attacker runs exploit code that repeatedly manipulates vulnerable VMware operations to win the TOCTOU race condition. The race causes VMware’s host-side handling to operate on data that changed after validation, producing an out-of-bounds write. If the attacker controls the write sufficiently, they can redirect execution or corrupt memory in a way that executes attacker-controlled code in the VMX process on the host. This does not require direct network access to the ESXi management plane if the attacker already controls a VM, making it especially dangerous in multi-tenant, shared, or high-trust virtualization environments. Active in-the-wild exploitation has been reported, so defenders should assume weaponized techniques exist and look for evidence of guest-to-host escape attempts as well as precursor guest compromise.

How to fix it

Apply the vendor-provided VMware fixes or update ESXi and Workstation to versions that address this vulnerability as soon as possible. Because no exact fixed versions were provided in the input, confirm the applicable patched build numbers from the official VMware/Broadcom security advisory for CVE-2025-22224 and ensure all affected ESXi hosts, Workstation installations, and managed images are upgraded. Where immediate patching is not possible, reduce exposure by restricting who can obtain administrative privileges inside VMs, limiting untrusted or internet-facing workloads on shared hosts, isolating high-risk VMs, disabling or removing unnecessary guest-to-host integration features, and increasing monitoring of VMX process behavior. Treat vulnerable systems as overdue for remediation because the issue is in CISA KEV with a 2025-03-25 due date and active exploitation reported.

How to confirm the fix worked

Validate remediation by inventorying all VMware ESXi and Workstation installations and comparing their exact build numbers against the vendor advisory’s fixed versions. Confirm that hypervisors and desktop virtualization endpoints have been rebooted or otherwise fully completed the update process where required. Re-scan with authenticated vulnerability scanning that can read VMware product versions rather than relying only on network banners. For ESXi, verify patched host build information through vCenter, ESXi shell, or host client inventory. For Workstation, verify the installed application version on endpoints and golden images. Also validate that no unsupported or unmanaged VMware installations remain in labs, developer systems, or isolated networks.

Typical attack path

1. Compromise or obtain local administrative privileges inside a virtual machine running on VMware ESXi or VMware Workstation.
2. Stage exploit tooling inside the guest operating system.
3. Trigger vulnerable VMware functionality from the guest while repeatedly manipulating race-condition timing.
4. Win the TOCTOU race and cause an out-of-bounds write in the host-side VMX process.
5. Execute attacker-controlled code in the VMX process context on the host.
6. Use host-side execution to tamper with the VM, collect sensitive data, move laterally, disable security controls, or attempt broader host compromise.

How to detect it

Look for evidence of both precursor guest compromise and guest-to-host escape behavior. Relevant sources include guest operating system security logs, EDR telemetry, VMware ESXi host logs, vCenter events, Workstation host logs, vmware.log files for affected VMs, syslog from hypervisors, and process telemetry for the host-side VMX process. Investigate unusual crashes, restarts, or abnormal memory faults in vmx-related processes, unexpected VM power operations, suspicious administrative activity inside guest VMs shortly before VMX instability, and host-side processes or files created by a VM-associated VMX process. On ESXi, review /var/log/vmkernel.log, /var/log/hostd.log, /var/log/vpxa.log, /var/log/syslog.log, and per-VM vmware.log files for abnormal VMX termination, segmentation faults, device emulation errors, or repeated error patterns around a single VM. On Workstation hosts, review VMware UI/log directories, Windows Event Logs or Linux syslog/journal logs, and EDR process lineage showing vmware-vmx spawning unexpected child processes or making unusual network connections. Because public, stable IOCs can vary by exploit implementation, prioritize behavioral detections: guest admin compromise followed by vmx crashes, unexpected host process execution from vmware-vmx lineage, and anomalous access to VM configuration or disk files.

• vmware-vmx
• vmx
• /var/log/vmkernel.log
• /var/log/hostd.log
• /var/log/vpxa.log
• /var/log/syslog.log
• vmware.log
• VMX has left the building
• vcpu-0
• PANIC
• Signal 11
• Segmentation fault
• Out of bounds
• out-of-bounds
• vmware-vmx.exe
• C:\ProgramData\VMware\hostd\
• C:\Users\Public\Documents\Shared Virtual Machines\
• /vmfs/volumes/

What your security team should do

• Prioritize emergency remediation of all VMware ESXi and Workstation systems because this vulnerability is KEV-listed and exploited in the wild.
• Identify VMs where untrusted users, contractors, customers, developers, or exposed workloads may have administrative privileges and prioritize their hosts first.
• Review recent guest administrative activity, suspicious tooling, and VMX process anomalies for signs of attempted guest-to-host escape.
• Temporarily migrate or isolate high-risk VMs from sensitive shared hosts until patching is complete.
• Ensure EDR, hypervisor logging, vCenter logs, and system logs are retained long enough to support retrospective investigation.
• Restrict access to VMware management interfaces and enforce least privilege for VM console, snapshot, device, and administrative operations.
• After patching, perform authenticated version validation and update asset inventory to include ESXi hosts, Workstation endpoints, templates, and offline images.