CVE-2025-22225

What it actually does

VMware ESXi has an arbitrary write flaw reachable from privileged execution within the VMX process, the per-VM process that mediates guest interaction with virtual hardware and the hypervisor. Successful exploitation can allow writes to sensitive kernel memory and break out of the VMX sandbox, undermining the isolation boundary between a virtual machine and the ESXi host. In practical terms, this can enable escalation from a compromised or malicious VM context toward hypervisor-level control, with potential access to host resources and other virtual machines.

Why it matters to the business

This vulnerability affects the virtualization layer, so a successful compromise can put multiple hosted workloads at risk from a single exploited VM. Because it is listed in CISA KEV, has active exploitation in the wild, and is identified as used in ransomware campaigns, organizations should treat it as urgent even though the EPSS score is currently low. If exploited, the operational impact can include unauthorized access to critical servers, disruption or encryption of multiple VMs, theft of sensitive data, and expensive recovery of hypervisor infrastructure. CISA’s KEV remediation deadline was 2025-03-25, so any remaining unpatched exposure should be considered overdue.

How an attack unfolds

An attacker typically begins by compromising a guest VM or obtaining sufficient privileges in a VM context that can interact with functionality handled by the VMX process. The attacker then triggers the vulnerable ESXi VMX code path using crafted operations against virtualized hardware or VM-controlled interfaces. The flaw allows an arbitrary write into kernel memory, which can be used to corrupt control structures, bypass VMX sandbox restrictions, and execute actions outside the intended VM boundary. Once the sandbox is escaped, the attacker may attempt to gain host-level control, access files backing other VMs, tamper with hypervisor configuration, deploy persistence, disable security tooling, or support ransomware activity against multiple virtualized workloads.

How to fix it

Apply the vendor-provided VMware/Broadcom security updates for the affected ESXi versions as the primary remediation. Where exact fixed versions are managed internally, upgrade every affected ESXi host to a build that includes the fix for CVE-2025-22225 and confirm the patch level against the relevant VMware security advisory. Because this vulnerability is in KEV and associated with ransomware activity, prioritize internet-exposed, management-plane-accessible, shared-production, and high-density virtualization clusters first. If immediate patching is not possible, reduce risk by isolating or powering down untrusted VMs, restricting who can create or administer VMs, disabling unnecessary virtual devices and guest-host integration features where feasible, limiting ESXi management access to hardened administrative networks, and increasing monitoring for VMX crashes, hypervisor instability, and suspicious host activity. Mitigations should be treated as temporary; patching is required to remove the vulnerable code path.

How to confirm the fix worked

Validate remediation by inventorying all ESXi hosts and confirming their installed build numbers are at or above the vendor-fixed builds for this advisory. Use vCenter Lifecycle Manager, ESXi command-line version checks, and configuration management inventory to verify there are no remaining vulnerable hosts or disconnected hosts that missed remediation. Confirm all hosts have been remediated after maintenance windows and that clusters do not contain mixed vulnerable and fixed nodes. Review vendor advisory mappings carefully because ESXi patch naming can differ by major release and update branch. After patching, monitor for abnormal VM behavior, VMX process crashes, host purple diagnostic screens, unexpected VM restarts, and unexplained changes to VM files or host configuration as a post-remediation assurance check.

Typical attack path

1. Compromise or gain privileged access inside a guest VM running on a vulnerable ESXi host.
2. Identify that the VM is hosted on a vulnerable ESXi build or infer vulnerability from exposed tooling, virtual hardware behavior, or environment reconnaissance.
3. Trigger the vulnerable VMX-handled code path through crafted guest activity or virtual device interaction.
4. Use the arbitrary kernel write primitive to corrupt memory and escape VMX sandbox constraints.
5. Escalate from the VM context toward ESXi host or hypervisor-level control.
6. Enumerate datastores, VM configuration files, snapshots, and other guest disks accessible from the host.
7. Deploy follow-on payloads, steal VM data, modify host settings, or stage ransomware across virtualized workloads.

How to detect it

Detection should focus on signs that a guest VM interacted abnormally with the hypervisor, followed by evidence of host-level access or tampering. Review ESXi vmkernel, hostd, vpxa, shell, auth, and system logs; vCenter Tasks and Events; and per-VM vmware.log files around suspicious VM crashes, resets, or host instability. Look for VMX process crashes, core dumps, purple diagnostic screens, unexpected VM power operations, unexplained changes to .vmx files, snapshot manipulation, unexpected datastore browsing, and access to other VM disk files. Correlate guest compromise timelines with ESXi host events: a VM exploit may appear as guest activity immediately before VMX faults or abnormal host events. Because exploitation may be used in ransomware campaigns, also hunt for mass VM shutdowns, suspicious encryption tooling on datastores, unauthorized SSH/ESXi Shell enablement, creation or modification of local ESXi accounts, changes to firewall rules, and abnormal use of command-line utilities such as vim-cmd, esxcli, vmkfstools, and PowerCLI from unfamiliar sources. If a host is suspected, preserve logs and memory/core artifacts before rebooting where operationally feasible.

• /var/log/vmkernel.log
• /var/log/hostd.log
• /var/log/vpxa.log
• /var/log/shell.log
• /var/log/auth.log
• /var/log/syslog.log
• vmware.log
• vmx-zdump
• vmx core dump
• /var/core/
• /vmfs/volumes/
• vim-cmd
• esxcli
• vmkfstools
• PowerCLI
• SSH login enabled
• TSM-SSH
• ESXi Shell
• UserVars.ESXiShellInteractiveTimeOut
• UserVars.ESXiShellTimeOut
• Cannot open the disk
• Dictionary problem
• A core file is available
• PANIC
• ASSERT
• Exception
• VMX has left the building

What your security team should do

• Treat this as an emergency hypervisor risk because it is in CISA KEV, actively exploited, and associated with ransomware campaigns.
• Immediately inventory ESXi versions and identify all hosts that do not contain the vendor fix for this vulnerability.
• Patch or upgrade affected ESXi hosts as a priority, starting with production clusters, shared service clusters, and hosts running high-value workloads.
• If patching requires downtime, create an accelerated maintenance plan and avoid leaving vulnerable hosts in active clusters longer than necessary.
• Restrict ESXi and vCenter management access to trusted administrative networks and enforce strong MFA-backed administrative access.
• Review guest VM administrative access, especially for untrusted, externally exposed, or lower-assurance workloads hosted on vulnerable clusters.
• Hunt for evidence of VM escape attempts, VMX crashes, suspicious ESXi shell usage, datastore tampering, and unauthorized VM disk access.
• Preserve relevant ESXi, vCenter, and VM logs before patching or rebuilding hosts where compromise is suspected.
• Assume a successful exploit may affect more than one VM on the same host and scope incident response at the cluster and datastore level, not only at the initial guest VM.
• For ransomware readiness, verify offline backups of critical VMs, backup immutability, restore procedures, and separation of backup credentials from virtualization administrators.