Latest VMware ESXi vulnerabilities #
On March 4th, 2025, Broadcom disclosed several vulnerabilities in all versions of its VMware ESXi, Workstation, and Fusion products. They also indicated that these are known to be exploited in the wild. Public information indicates that these vulnerabilities are potentially being leveraged by ransomware groups.
- CVE-2025-22224 is rated critical with a CVSSv3 base score of 9.3. Successful exploitation of this vulnerability would allow a local administrative user in a guest virtual machine to execute arbitrary code as the guest virtual machine's VMX process on a vulnerable host system. Impacts VMware ESXi and Workstation.
- CVE-2025-22225 is rated important with a CVSSv3 base score of 8.2. Successful exploitation of this vulnerability would allow a malicious actor with privileges within the VMX process to trigger an arbitrary kernel write leading to an escape of the sandbox. Impacts VMware ESXi.
- CVE-2025-22226 is rated important with a CVSSv3 base score of 7.1. Successful exploitation of this vulnerability would allow a local administrative user in a guest virtual machine to leak memory from the VMX process on a vulnerable host system. Impacts VMware ESXi, Workstation, and Fusion.
What is the impact? #
Upon successful exploitation of these vulnerabilities, an attacker with administrative rights in a guest virtual machine would be able to perform a VM Escape and execute code on the hypervisor host.
Are updates or workarounds available? #
VMware has released updates for supported versions of the impact products to address these vulnerabilities. All users are urged to update as quickly as possible. Users of unsupported version should review the download portals for their product to see if Broadcom has made patches available. They have reportedly done so for VMware ESXi 6.5 and 6.7. That said, Broadcom strongly encourages all customers using vSphere 6.5 and 6.7 to update to vSphere 8.
Product | Version | Fixed Version | Workarounds |
ESXi | 8.0 | None | |
ESXi | 8.0 | None | |
ESXi | 7.0 | None | |
ESXi | 6.7 | ESXi670-202503001 | None |
Workstation | 17.x | 17.6.3 | None |
Fusion | 13.x | 13.6.3 | None |
How to find VMware installations with runZero #
From the Asset Inventory, use the following query to locate assets running vulnerable versions of VMware ESXi:
os:"vmware esxi" AND (os_version:<6 OR (os_version:>6 AND os_version:<"6.7.0 build-24514018") OR (os_version:>7 AND os_version:<"7.0.3 build-24585291") OR (os_version:>8 AND os_version:<"8.0.2") OR (os_version:>"8.0.2" AND os_version:<"8.0.2 build-24585300") OR (os_version:>"8.0.3" AND os_version:<"8.0.3 build-24585383"))
Additionally, using the runZero VMware integration, use the following Asset Inventory query to locate virtual machines running inside VMware, which could be potential sources of exploitation:
source:vmware
Vulnerable versions of Workstation and Fusion can be found in the Software inventory using the following query:
vendor:vmware AND ((product:Workstation AND version:<17.6.3) OR (product:Fusion AND version:<13.6.3))
All versions of Workstation and Fusion can be found in the Software inventory using the following query:
vendor:vmware AND (product:Workstation OR product:Fusion)
Multiple CVEs (June 2024) #
Broadcom has disclosed a vulnerability in their ESXi product that involves a domain group that could contain members that are granted full administrative access to the ESXi hypervisor host by default without proper validation.
CVE-2024-37085 is rated medium with CVSS score of 6.8 and allows an attacker with sufficient Active Directory (AD) permissions to bypass authentication.
What is the impact? #
A malicious actor with sufficient Active Directory (AD) permissions can gain full access to an ESXi host that was previously configured to use AD for user management by re-creating the configured AD group ('ESXi Admins' by default) after it was deleted from AD. The three ways this can be exploited are:
1. Creating the AD group 'ESX Admins' to the domain and adding a user to it (known to be exploited in the wild)
2. Renaming another AD group in the domain to 'ESX Admins' and adding a new or existing user to it
3. Refreshing the privileges in the ESXi hypervisor when the 'ESX Admin' group is unassigned as the management group.
Are updates or workarounds available? #
Product | Version | Fixed Version | Workarounds |
ESXi | 8.0 | ||
ESXi | 7.0 | No Patch Planned | |
VMware Cloud Foundation | 5.x | ||
VMware Cloud Foundation | 4.x | No Patch Planned |
How to find potentially vulnerable systems runZero #
From the Asset Inventory, use the following query to locate systems running potentially vulnerable software:
os:ESXi
Additionally, using the runZero VMware integration, use the following query to locate virtual machines running inside VMware, which could be potential sources of exploitation:
source:vmware
Multiple CVEs (March 2024) #
On March 5th, 2024, VMware disclosed several vulnerabilities in its ESXi, Workstation, and Fusion products.
The vulnerabilities, reported as CVE-2024-22252, CVE-2024-22253, CVE-2024-22254, and CVE-2024-22255 allow code running inside virtual machines to access the host system in unauthorized ways.
The CVSS scores range from 7.1 (high) to 9.3 (critical); the vulnerabilities affecting ESXi are limited to high severity, but the vendor has indicated that taken together the vulnerabilities should be considered critical.
What is the impact? #
Upon successful exploitation of these vulnerabilities, an attacker who can execute code inside a virtual machine can access the host system and perform actions ranging from arbitrary code execution to sensitive information disclosure.
Are updates or workarounds available? #
VMware has released new versions of these products to address these vulnerabilities. All users are urged to update as quickly as possible.
How to find VMware installations with runZero #
From the Asset Inventory, use the following query to locate assets running potentially vulnerable versions of VMware ESXi or running VMware products:
os:ESXi
Additionally, using the runZero VMware integration, use the following query to locate virtual machines running inside VMware, which could be potential sources of exploitation:
source:vmware
Additional fingerprinting research is ongoing, and additional queries will be published as soon as possible.
CVE-2021-21974 (February 2023) #
In February 2023, popular hypervisor ESXi made the news due to fresh targeting by a new strain of ransomware. Known as ESXiArgs, this ransomware leveraged a 2-year old heap overflow issue in the OpenSLP service that can be used to execute remote code on exploitable targets (CVE-2021-21974). Many vulnerable public-facing ESXi servers had already been affected by this malware (at the time over 1,900 via Censys search results).
What was the impact? #
Targets of this new ransomware campaign were older ESXi servers running certain versions of 6.5, 6.7, or 7 releases and also had the OpenSLP service enabled (it has not been enabled by default in ESXi releases since 2021). Upon successful exploitation of CVE-2021-21974, the ESXiArgs ransomware encrypted a number of file types on the target system, including VM-related files with extensions .vmxf, .vmx, .vmdk, .vmsd, and .nvram. Ransom notes were saved as HTML files on compromised systems for admins and users to subsequently discover. While some of these ransom notes claim to have stolen data from vulnerable targets, no data exfiltration had been observed at the time.
VMware made patches available when the OpenSLP heap-overflow vulnerability was initially reported in 2021. The following ESXi releases had been patched against this attack vector and exploited by the ESXiArgs campaign:
- ESXi version 7+ (ESXi70U1c-17325551 and later)
- ESXi version 6.7+ (ESXi670-202102401-SG and later)
- ESXi version 6.5+ (ESXi650-202102101-SG and later)
VMware also offered patched releases for Cloud Foundation (ESXi), which included an ESXi component:
- Cloud Foundation (ESXi) version 4.2+
- Patching instructions for Cloud Foundation (ESXi) version 3.x can be found here
Patching (and also ensuring that your ESXi servers were running a supported, not end-of-life/end-of-support version) was the best course of action. If patching was not a near-term option, VMware recommended mitigation via disabling the OpenSLP service.