On March 4, 2025, Broadcom released emergency patches for three zero-day vulnerabilities in VMware ESXi, Workstation, and Fusion that were being actively exploited in the wild. The bugs — CVE-2025-22224, CVE-2025-22225, and CVE-2025-22226 — form an exploit chain that allows an attacker with local admin privileges on a virtual machine to escape the VM sandbox and execute code on the underlying hypervisor.
VM escape is the nightmare scenario for virtualization security. The entire security model of virtualization depends on the isolation between guest VMs and the host hypervisor. When that boundary fails, a single compromised VM can lead to the compromise of every VM on the host, plus the host itself.
The Three Vulnerabilities
CVE-2025-22224 — VCMI Heap Overflow (CVSS 9.3)
This is a Time-of-Check Time-of-Use (TOCTOU) vulnerability in VMware's Virtual Machine Communication Interface (VMCI). An attacker with local administrative access to a virtual machine can exploit this heap overflow to execute code in the VMX process on the host.
The VMX process runs on the hypervisor and manages the virtual machine. Compromising it gives the attacker a foothold on the host system.
CVE-2025-22225 — ESXi Arbitrary Write (CVSS 8.2)
This vulnerability allows an attacker who has already compromised the VMX process (via CVE-2025-22224) to perform an arbitrary kernel write on the ESXi hypervisor. This escalates from VMX process compromise to full kernel-level access on the hypervisor.
CVE-2025-22226 — HGFS Information Disclosure (CVSS 7.1)
An information disclosure vulnerability in the Host-Guest File System (HGFS) component allows an attacker with administrative access to a VM to leak memory contents from the VMX process. This provides the memory layout information needed to reliably exploit CVE-2025-22224.
The Exploit Chain
The three vulnerabilities chain together in a logical sequence:
- CVE-2025-22226 (info leak): Attacker reads VMX process memory from within the VM, obtaining addresses needed for exploitation
- CVE-2025-22224 (heap overflow): Using the leaked information, the attacker triggers the TOCTOU heap overflow to gain code execution in the VMX process
- CVE-2025-22225 (arbitrary write): From the VMX process, the attacker writes to the ESXi kernel, achieving full hypervisor compromise
The prerequisite is local admin on a VM, which is a common condition. In cloud environments, IaaS customers typically have root/admin on their VMs. In enterprise environments, application teams often have admin access to their assigned VMs.
Who Was Exploiting This
Microsoft's Threat Intelligence Center (MSTIC) was credited with reporting the vulnerabilities to Broadcom, suggesting they discovered the exploitation through their threat hunting operations. The specific threat actors were not publicly identified at the time of disclosure, but VM escape exploits of this sophistication are typically associated with:
- Nation-state actors conducting espionage
- Advanced ransomware groups targeting virtualization infrastructure
- Commercial surveillance vendors
Previous VMware exploitation has been attributed to Chinese state-sponsored groups (notably UNC3886) who have a documented history of targeting ESXi hypervisors for persistent access.
Affected Products
- VMware ESXi: Versions 7.0 and 8.0
- VMware Workstation: Version 17.x
- VMware Fusion: Version 13.x
- VMware Cloud Foundation: Versions 4.x and 5.x
- VMware Telco Cloud Platform: Multiple versions
The patched versions were ESXi 7.0 U3s, ESXi 8.0 U3d, Workstation 17.6.3, and Fusion 13.6.3.
The Virtualization Attack Surface
This exploit chain highlights several uncomfortable truths about virtualization security:
The VM boundary is not absolute. VM escape vulnerabilities have existed since virtualization began. The attack surface includes virtual hardware emulation, paravirtualized drivers, shared memory regions, and inter-VM communication mechanisms. Each of these is a potential escape path.
ESXi is a high-value target. A single ESXi host typically runs dozens of VMs. Compromising the hypervisor gives access to all guest VMs, their virtual disks (including encrypted ones, since the hypervisor holds the keys), network traffic between VMs, and the management plane.
Detection is nearly impossible from within guests. A compromised hypervisor can manipulate what guest VMs see. It can hide processes, intercept network traffic, and modify disk contents. Traditional security tools running inside VMs cannot detect hypervisor-level compromise.
Patching is operationally painful. ESXi patches require host reboots, which means migrating all VMs off the host first (vMotion), patching, rebooting, and migrating VMs back. In environments without sufficient spare capacity, this is a days-long process.
Remediation
Broadcom's advisory recommended immediate patching. For organizations unable to patch immediately:
- Reduce VM admin access: Limit who has local admin privileges on VMs. This reduces the attacker population that can exploit the chain.
- Network segmentation: Isolate ESXi management networks from general user networks and the internet
- Monitor VMX process behavior: Unusual VMX process activity (unexpected memory allocation, abnormal system calls) may indicate exploitation
- vSphere Lockdown Mode: Enable strict lockdown mode to limit ESXi management access
- Monitor for lateral movement: If an attacker escapes a VM, they'll likely attempt to access other VMs or the vCenter management plane
The Post-Broadcom Patch Landscape
Since Broadcom acquired VMware in November 2023, the patching and support landscape has changed significantly. License restructuring, support tier changes, and product bundle modifications have caused confusion among VMware customers. Some organizations have delayed patching due to uncertainty about their support entitlements or confusion about which patches apply to their license tier.
This is a dangerous situation when zero-days are being actively exploited. Organizations should verify their Broadcom support status and patch entitlements proactively, not during an emergency.
Long-Term Architectural Considerations
Repeated VM escape vulnerabilities suggest that organizations should:
- Not treat the VM boundary as a security boundary for high-sensitivity workloads: Use dedicated physical hardware for the most sensitive systems
- Implement hypervisor integrity monitoring: Tools that can detect unauthorized modifications to the hypervisor
- Consider hardware-based isolation: Technologies like AMD SEV-SNP and Intel TDX provide hardware-enforced VM isolation that doesn't depend solely on hypervisor software integrity
- Plan for hypervisor compromise in incident response: Include VM escape scenarios in tabletop exercises
How Safeguard.sh Helps
Safeguard.sh provides comprehensive visibility into your virtualization infrastructure, tracking ESXi versions, VM configurations, and patch status across your entire VMware estate. When Broadcom released the emergency patches for CVE-2025-22224/22225/22226, Safeguard.sh users could immediately identify every affected hypervisor and prioritize remediation based on exposure.
The platform's SBOM capabilities extend to infrastructure software, mapping the components and versions running on your hypervisors. Combined with Safeguard.sh's vulnerability correlation engine, this means new VMware advisories are automatically matched against your actual deployment, eliminating the manual version-checking process that delays patching.
Safeguard.sh's policy enforcement can also mandate patch timelines for critical infrastructure — ensuring that hypervisor patches don't languish in change management queues while zero-day exploitation continues in the wild.