Zero-Days in VMware: What You Should Know

Table of Contents

• Module 1: The VMware Zero-Day Vulnerability Chain (VMSA-2025-0004)
  • Advisory Overview and Affected Products
  • Understanding VM Escape and Why It Matters
  • CVE-2025-22224: Time-of-Check to Time-of-Use Heap Overflow in the VMX Process
  • CVE-2025-22225: Arbitrary Kernel Write via the VMX Process
  • CVE-2025-22226: HGFS Out-of-Bounds Read and Information Disclosure
  • The Full Exploitation Chain and Privilege Requirements
  • CVSS Scoring: Broadcom vs. NIST
  • Affected Products and Versions
  • Exploitation Status and Patch Availability
  • Risk Assessment and Mitigation Recommendations
  • Network Segmentation as a Defense-in-Depth Control
• Summary

Module 1: The VMware Zero-Day Vulnerability Chain (VMSA-2025-0004)

Advisory Overview and Affected Products

On March 4, Broadcom — which acquired VMware in 2023 — published a critical security advisory detailing three zero-day vulnerabilities affecting multiple core VMware products, including ESX, VMware Workstation, and VMware Fusion. Having three zero-days disclosed together in a single advisory is unusual; most disclosures involve a single flaw.

The most significant of the three is CVE-2025-22224, a critical flaw affecting ESX and Workstation. The other two vulnerabilities, CVE-2025-22225 and CVE-2025-22226, are rated high severity. Collectively, exploitation of these flaws can lead to:

• VM escape — breaking out of a guest virtual machine to execute code on the host
• Memory leaks — disclosure of sensitive data such as secrets or cryptographic keys from host or hypervisor memory
• Code execution on the host machine

An important mitigating detail: none of these vulnerabilities are remotely exploitable. An attacker must already have privileged (admin/root) access inside a virtual machine running on an affected hypervisor before any of these flaws can be leveraged. This means the risk is concentrated in post-exploitation activity rather than initial access — but it remains a serious concern for anyone managing virtualized environments, especially multi-tenant ones such as cloud providers or shared enterprise datacenters.

mindmap
  root((VMSA-2025-0004))
    CVE-2025-22224
      TOCTOU heap overflow
      Critical severity
      Affects ESX and Workstation
    CVE-2025-22225
      Arbitrary kernel write
      High severity
      Affects ESX only
    CVE-2025-22226
      HGFS out-of-bounds read
      Information disclosure
      Affects ESX, Workstation, Fusion

Understanding VM Escape and Why It Matters

One of the core security benefits of virtualization is isolation — the guarantee that a workload running inside one virtual machine cannot affect the host system or other virtual machines sharing the same physical infrastructure. This isolation is especially critical in cloud environments and enterprise datacenters where multiple customers or departments share the same physical hardware.

A VM escape occurs when that isolation boundary fails: an attacker inside a guest VM breaks out and executes code directly on the host system. This is considered one of the most dangerous scenarios in virtualization security, because gaining control of the hypervisor potentially compromises every other virtual machine running on the same host. From there, an attacker could steal data, deploy malware, or disrupt entire services.

VM escape is not something an attacker can do immediately — it is fundamentally a post-exploitation technique:

1. The attacker must first compromise a guest VM (e.g., via phishing, exploiting a vulnerable web application, or using stolen credentials).
2. The attacker must typically escalate privileges to admin or root inside that VM.
3. Once inside with sufficient privileges, the attacker searches for flaws — such as arbitrary file writes or memory corruption bugs — that let them interact with the hypervisor in ways that should not normally be possible.

The number of hoops an attacker must jump through is significant, but the payoff can be substantial: in a multi-tenant environment, escaping from a single VM could expose data from dozens or even hundreds of others.

flowchart TB
    subgraph Host["Physical Host / Hypervisor"]
        VMX1["VM 1 - VMX Process"]
        VMX2["VM 2 - VMX Process"]
        VMX3["VM 3 - VMX Process"]
        Kernel["ESX Kernel / vmkernel"]
    end
    VMX1 -->|Isolated by design| Kernel
    VMX2 -->|Isolated by design| Kernel
    VMX3 -->|Isolated by design| Kernel
    Attacker["Attacker with local admin in VM 1"] -->|Exploits TOCTOU flaw| VMX1
    VMX1 -->|VM Escape| Kernel
    Kernel -->|Isolation broken| VMX2
    Kernel -->|Isolation broken| VMX3

CVE-2025-22224: Time-of-Check to Time-of-Use Heap Overflow in the VMX Process

CVE-2025-22224 is a critical time-of-check to time-of-use (TOCTOU) vulnerability affecting ESX and Workstation.

A TOCTOU vulnerability occurs when a system checks the state of a resource (such as a file or a socket), and before that resource is actually used, its state changes — potentially leading to unexpected behavior or a security issue. In this case, the TOCTOU condition leads to an out-of-bounds write (heap overflow), which allows an attacker with local admin privileges inside a virtual machine to execute code as the virtual machine’s VMX process running on the host.

The VMX process is the host-side process responsible for managing a given virtual machine’s execution — gaining code execution in that context is a direct step toward breaking out of the VM boundary.

CVE-2025-22225: Arbitrary Kernel Write via the VMX Process

CVE-2025-22225 affects VMware ESX only and is classified as high severity. It allows an attacker who already has privileges inside the VMX process (for example, having exploited CVE-2025-22224) to perform an arbitrary write to the kernel.

An arbitrary write vulnerability occurs when an attacker can write data to any location in memory or on disk, rather than being restricted to specific, authorized locations. Because this flaw exists at the kernel level, an attacker who has already reached the VMX process can manipulate the ESX hypervisor itself — effectively completing the breakout from the virtual machine and gaining control over the host system.

VMware rates this as high severity because of the significant risk it poses in multi-tenant environments, where an attacker could use it to escalate privileges and affect other virtual machines running on the same host.

CVE-2025-22226: HGFS Out-of-Bounds Read and Information Disclosure

The third vulnerability affects ESX, Workstation, and Fusion. The flaw resides in the HGFS (Host-Guest File System) component and is caused by an out-of-bounds read — a memory error that occurs when a process accesses data outside its allocated buffer.

Note on transcript clarity: During the discussion, the third CVE was momentarily referred to verbally by the same number as the second one before the CVSS breakdown clarified it as a distinct identifier. Based on the CVSS scoring discussion later in the material (a 7.1/6.0 information-disclosure flaw distinct from the arbitrary-write vulnerability), this HGFS out-of-bounds read issue is CVE-2025-22226, consistent with the publicly documented VMSA-2025-0004 advisory.

This type of out-of-bounds read can lead to unintended exposure of sensitive information from memory — potentially revealing secrets, cryptographic keys, or other critical data. An attacker with admin privileges inside a virtual machine could exploit this flaw to leak memory from the VMX process that manages virtual machine execution, gaining insight into the underlying hypervisor or exposing data belonging to other virtual machines. As with the other two flaws, this is a significant concern in multi-tenant environments.

The Full Exploitation Chain and Privilege Requirements

Bringing the three vulnerabilities together illustrates how an attacker could progress from a compromised guest VM to a fully compromised host and, potentially, to other tenants sharing that host:

sequenceDiagram
    participant A as Attacker
    participant VM as Guest VM (Local Admin)
    participant VMX as VMX Process (Host)
    participant Kernel as ESX Kernel
    participant Other as Other VMs on Host

    A->>VM: Gain local admin/root (phishing, stolen credentials, web app exploit)
    VM->>VMX: Trigger TOCTOU race condition (CVE-2025-22224)
    VMX->>VMX: Out-of-bounds write in heap memory
    VMX->>VMX: Attacker code executes as the VMX process on the host
    VMX->>Kernel: Arbitrary write to kernel memory (CVE-2025-22225)
    Kernel->>Kernel: Hypervisor integrity compromised (VM escape achieved)
    VMX->>VMX: Out-of-bounds read via HGFS (CVE-2025-22226)
    VMX-->>A: Leak memory contents, secrets, cryptographic keys
    Kernel->>Other: Attacker pivots to other VMs sharing the host

At every stage, the critical prerequisite is that the attacker already holds local admin or root privileges inside a guest virtual machine. None of these three flaws can be triggered remotely or without that initial foothold — the danger they represent is in what happens after an attacker has already breached a VM, not in providing the initial breach itself.

CVSS Scoring: Broadcom vs. NIST

CVSS scores help cut through the fear, uncertainty, and doubt (FUD) that often surrounds vulnerability disclosures, providing a level-headed way to assess risk when the vulnerabilities are complex, local access is required, and the potential impact is significant.

Notably, Broadcom (as the Certifying Naming Authority for these CVEs) scored CVE-2025-22224 higher than NIST’s National Vulnerability Database. Both parties agree on several base metrics: the attacker must have local access, attack complexity is low, no user interaction is required, and there is a high potential impact to confidentiality, integrity, and availability.

Where the two assessments diverge is on the privileges required metric:

• Broadcom assesses privileges required as None — treating the attacker as effectively unauthenticated prior to the attack, which pushes the score upward.
• NIST assesses privileges required as High — reflecting that the attacker needs significant, privileged control of the vulnerable system (full access to settings and files) before the flaw can be exploited, which pushes the score downward.

Since exploitation genuinely requires local admin privileges inside the VM, the NIST assessment arguably makes more sense on its face — but there could be reasonable explanations for Broadcom’s higher rating:

• Downplaying risk could slow patching. If the vulnerability’s significance were understated, organizations might deprioritize patching, which is a particular concern here because these flaws have already been exploited in the wild.
• Reputational and trust considerations. If Broadcom were seen to understate a vulnerability’s severity and were called out by security researchers, it could damage customer trust and reputation.

For CVE-2025-22225, Broadcom similarly assessed privileges as required, which pushed the score down from what would otherwise be a critical rating to 8.2 (High); NIST has not yet published its own assessment for this CVE. For CVE-2025-22226, the score is lower for both parties (7.1 Broadcom / 6.0 NIST) primarily because the impact affects only confidentiality — consistent with its classification as an information-disclosure vulnerability rather than one affecting integrity or availability.

flowchart TD
    A["CVSS Base Score Divergence"] --> B{"Privileges Required metric?"}
    B -->|"Broadcom rates: None"| C["Attacker treated as unauthenticated -> higher score"]
    B -->|"NIST rates: High"| D["Attacker already needs significant local privileges -> lower score"]
    C --> E["CVE-2025-22224: Broadcom 9.3 Critical"]
    D --> F["CVE-2025-22224: NIST 8.2 High"]

Affected Products and Versions

The scope of affected products is broad, since all three vulnerabilities ultimately trace back to the ESX hypervisor codebase:

flowchart TD
    Start["Is a given product affected by VMSA-2025-0004?"] --> ESX{"Does it include the ESX hypervisor?"}
    ESX -->|Yes| ESXAffected["Affected by all 3 CVEs\nESX, vSphere, Telco Cloud Foundation, Telco Cloud Platform"]
    ESX -->|No| Workstation{"Is it VMware Workstation 17.x?"}
    Workstation -->|Yes| WSAffected["Affected by CVE-2025-22224 and CVE-2025-22226"]
    Workstation -->|No| Fusion{"Is it VMware Fusion 13.x?"}
    Fusion -->|Yes| FusionAffected["Affected only by CVE-2025-22226"]
    Fusion -->|No| Other{"Is it vCenter, SDDC Manager, NSX, or Aria Suite?"}
    Other -->|Yes| NotAffected["Not affected by this advisory"]

Exploitation Status and Patch Availability

As of this recording, no public proof-of-concept exploit code or published indicators of compromise had been observed for these three vulnerabilities. The only real fix is to patch to the latest supported version of the affected product. There are no effective workarounds that fully mitigate any of the three flaws — patching is the only complete remediation.

Risk Assessment and Mitigation Recommendations

Because patching is not always immediately possible across every organization, and because response timelines vary depending on organizational circumstances, a layered set of interim risk-reduction steps is recommended for organizations that cannot patch right away:

1. Assess the risk. Determine the extent of exposure to these vulnerabilities, what the potential impact would be if the organization were victimized, and what controls are already in place to detect or stop a potential attack.
2. Enhance security monitoring until patches can be implemented, with particular attention to:
   • Increases in administrative activity, or admin activity occurring at unusual times of day.
   • Unusual crash activity, which may indicate attempts to manipulate memory.
   • The specific systems and data to monitor should be informed directly by the risk assessment above.
3. Strengthen access controls:
   • Identify and remove dormant admin accounts that are no longer needed.
   • Apply the principle of least privilege to limit administrative access to only what is required.
   • Enforce strong authentication measures for privileged accounts.
4. Review basic cyber hygiene practices, since exploitation requires an attacker to have already gained access and elevated privileges:
   • Are systems being patched regularly?
   • Are antivirus/endpoint protection products kept up to date?
   • Is multi-factor authentication in use for privileged access?
5. Review network segmentation options as a longer-term activity (see the next section for detail).

flowchart TD
    A["Can you patch immediately?"] -->|Yes| B["Apply the latest VMware security patch"]
    A -->|No| C["Assess risk: exposure, impact, existing controls"]
    C --> D["Enhance security monitoring: admin activity, unusual crashes"]
    D --> E["Strengthen access controls: remove dormant admin accounts, least privilege, strong authN"]
    E --> F["Review basic cyber hygiene: patching cadence, AV, MFA"]
    F --> G["Evaluate network segmentation to limit lateral movement"]
    G --> H["Patch as soon as possible"]

Network Segmentation as a Defense-in-Depth Control

Network segmentation is one of the most effective ways to limit the impact of a successful VM escape, even though it cannot prevent the escape itself. While segmentation does not stop an attacker from breaking out of a virtual machine and reaching the hypervisor or host, it does significantly reduce the attacker’s ability to:

• Move laterally through the broader environment.
• Exfiltrate data from other resources or tenants sharing the same infrastructure.

Because this is a structural, architectural control rather than a quick fix, it is best treated as a longer-term hardening activity worth pursuing alongside — not instead of — patching.

Summary

Broadcom’s March 4 security advisory disclosed three zero-day vulnerabilities affecting core VMware virtualization products — ESX, Workstation, and Fusion, along with any products that bundle the ESX hypervisor (vSphere, Telco Cloud Foundation, Telco Cloud Platform). None of the three flaws are remotely exploitable; all require an attacker to already hold local admin or root privileges inside a guest virtual machine, meaning the danger lies squarely in post-exploitation activity rather than initial access.

Key technical points:

• CVE-2025-22224 (Critical, Broadcom 9.3 / NIST 8.2) — a TOCTOU race condition causing an out-of-bounds heap write, letting an attacker execute code as the host’s VMX process.
• CVE-2025-22225 (High, Broadcom 8.2, ESX only) — an arbitrary kernel write reachable from the VMX process, completing the VM escape by compromising the hypervisor itself.
• CVE-2025-22226 (High, Broadcom 7.1 / NIST 6.0) — an out-of-bounds read in the HGFS component, leaking memory contents (potentially secrets or cryptographic keys) from the VMX process.

Chained together, these three flaws describe a full path from a compromised guest VM to host-level compromise and, in multi-tenant environments, potential exposure of other tenants’ virtual machines on the same physical host. The CVSS scoring divergence between Broadcom and NIST centers almost entirely on how each party weighs the “privileges required” metric — a useful reminder to read the full CVSS vector, not just the headline score, when prioritizing patching.

At the time of disclosure, no public proof-of-concept or indicators of compromise were available, and there is no effective workaround — patching to the latest supported version is the only complete remediation.

Mitigation Checklist

• Identify every ESX host, vSphere deployment, Telco Cloud Foundation/Platform instance, Workstation 17.x install, and Fusion 13.x install in the environment.
• Prioritize patching to the latest VMware-supplied fix for all affected products.
• If immediate patching is not possible, complete a formal risk assessment of exposure and potential impact.
• Increase monitoring of administrative activity, especially unusual timing or volume.
• Monitor for unusual VM/host crash activity that could indicate memory-manipulation attempts.
• Remove dormant or unnecessary administrative accounts.
• Apply least-privilege access to virtualization management resources.
• Enforce strong authentication (including MFA) for all privileged accounts with VM/hypervisor access.
• Confirm baseline cyber hygiene: regular patch cadence, updated endpoint protection, MFA enforcement.
• Evaluate and strengthen network segmentation to limit lateral movement and blast radius in the event of a VM escape.
• Track vendor and NVD updates for any future proof-of-concept releases or confirmed in-the-wild exploitation.

Search Terms

zero-days · vmware · know · vulnerability · briefings · networking · systems · security · affected · chain · exploitation · mitigation · process · products · vmx