Recent searches
Search options
3 different VMware zero days, under active exploitation by ransomware group
CVE-2025-22224, CVE-2025-22225, CVE-2025-22226
VMware ESXi
VMware Workstation Pro / Player (Workstation)
VMware Fusion
VMware Cloud Foundation
VMware Telco Cloud Platform
(Exploitation actually ESXi)
You may want to escalate patching this as it allows virtual machine to hypervisor escape - e.g. from some dumb VM to the whole VMware private cloud estate.
VMware have set the Attack Vector to Local, which brings down the CVSS score - but you don't need to be locally at a VM to do the attack, you can do it over the internet if you have access to any VM.
If you change it to Network, you get 10
Good catch by @TomSellers - although VMware doesn't list ESXi 6.7 as vulnerable, it is - they've published a patch for it: https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/6-7/release-notes/esxi-update-and-patch-release-notes/vmware-esxi-67-patch-release-esxi670202503001.html
I think what's happening here is 6.7 is under premium (paid) extended support where they publish patches for high severity vulns for $$
This also tends to indicate it applies to other unsupported versions. The forum post suggested that vuln worked on ESXi 5.x - no patch is available that far back.
I think this may be a big problem for many orgs.
Another good catch by @TomSellers - VMware's website advisory has less detail than their github for some reason.
Their github: https://github.com/vmware/vcf-security-and-compliance-guidelines/tree/main/security-advisories/vmsa-2025-0004
According to their Github, additional VMware ESXi versions are impacted (e.g. 6.5, 6.7) and older versions are likely impacted but no patches available.
An in the wild exploit for RCE hypervisor escape across every supported (and unsupported) product like this is unprecedent.
Quick mspaint.exe diagram on this, calling it ESXicape
- Have access to something like a Windows 11 Virtual Desktop system in VMware, or a Linux box or some such?
- Use ESXicape, a chain of three zero days, to gain access to the ESXi Hypervisor.
- Use that to access every other VM, and be on the management network of VMware cluster
One you have this level of access, traditionally you'll see groups like ransomware actors steal files and wipe things. #ESXicape
Does anybody know anybody at VMware Security who could have a look at the #ESXicape knowledge base article please?
It's missing 6.5 and 6.7, which are definitely vulnerable and have patches available on Broadcom's site. They're also listed in the VMware Github advisory, but have been missed off the support site. It's causing people to not patch.
Both VMware and Microsoft have declined to comment about #ESXicape, when asked about number of victims and who has the exploit.
A new twist on #ESXicape - you need local admin rights to escape the VM to the hypervisor, right?
Slight issue - VMware Tools, installed inside VMs, allows local user to local admin privilege escalation on every VM due to vuln CVE-2025-22230
“A malicious actor with non-administrative privileges on a Windows guest VM may gain ability to perform certain high-privilege operations within that VM.”
Discovered by Positive Technologies, who US claim hack for Moscow.
@GossiTheDog How can you attack this via network? The advisory says that you need to execute code on the VM, so it is local.
@waldi @GossiTheDog how do you connect to a VM (in almost any cases)?
@waldi @GossiTheDog From a remote connection. You're technically correct (the best kind), but I agree with Kevin that it should have been a network attack vector.
But that would make it a 10, which gives them bad publicity 
@jtig @GossiTheDog No, this is the definition. Just because you can use ssh does not elevate the access vector to Network. Otherwise Local will not longer exist.
Common problem with vuln scores, a chain of low priority vulns can add up to a high priority. @GossiTheDog @waldi @jtig
@GossiTheDog What exactly do you mean with "you can do it over the internet if you have access to any VM".
Do you mean there needs to be an attacker service running on the VM or that just having a service like a webserver running inside such a VM is enough? (As long as said webserver is accessible from external).
Also to what extend would such a service have to be compromised first?
@GossiTheDog The Broadcom advisory doesn't include it but they've published a patch for ESXi 6.7.
Selfish plug: We added it to our remediation table on our blog https://www.runzero.com/blog/vmware-esxi/
In the Github version of the Advisory FAQ they actually state that ALL unpatched versions are vulnerable though they indicate that they haven't tested most unsupported versions. Here are few snippets from the link below:
You are affected if you are running any version of VMware ESX, VMware vSphere, VMware Cloud Foundation, or VMware Telco Cloud Platform prior to the versions listed as “fixed” in the VMSA.
For a definitive list of affected versions, please refer to the VMSA directly. If there is any uncertainty about whether a system is affected, it should be presumed vulnerable, and immediate action should be taken.
Does this impact VMware vSphere 6.5 or 6.7?
Yes. A patch has been released for ESX 6.7 and is available via the Support Portal to all customers. ESX 6.5 customers should use the extended support process for access to ESX 6.5 patches.
Products that are past their End of General Support dates are not evaluated as part of security advisories, and are not listed in the official VMSA. Broadcom strongly encourages all customers using vSphere 6.5 and 6.7 to update to vSphere 8.
@GossiTheDog Wonderful news to read during evening.... *le sigh* time to plan patching with team.
@GossiTheDog Thanks Kevin. Gonna forward this to some people that I know use VMware.
@GossiTheDog This might be because 6.5 and 6.7 are not longer general supported.
@GossiTheDog Broadcom's press team don't even reply to requests for interviews or comment any more; no guarantee there *is* anyone left in the security team
@marypcbuk @GossiTheDog they absolutely still exist.
@vmstan @GossiTheDog good to know; it would certainly help if Broadcom's press team gave some proof of life as well!
@marypcbuk @GossiTheDog that I have no idea about.
@GossiTheDog they kept it off on purpose. The GitHub page even says so. It's weird though and is very confusing for those who actually might have a legit reason to run 6.5 and 6.7.
--------------
Products that are past their End of General Support dates are not evaluated as part of security advisories, and are not listed in the official VMSA. Broadcom strongly encourages all customers using vSphere 6.5 and 6.7 to update to vSphere 8.
@GossiTheDog
The answer is “yes”.
@GossiTheDog thereby confirming it’s not going to be a good time for many
@GossiTheDog also one way around it is to migrate to OpenShift virtualization using easy migration tools 
@GossiTheDog can't say the first thing I would do would be loop legal in when making a change or a commit to a code repository 
i mean it would for me in this instance but it would be notifying them what i published unless i was instructed otherwise
@GossiTheDog @TomSellers didn’t 5.5 already have an unfixed escape in it?
@GossiTheDog I mean this is just CVSS being wacky as normal and only looking at what’s possible in the OOTB config, not as commonly deployed
I just came here to ask you why these vulnerabilities are rated so critical if they can't be remotely exploited. Looks like you partially answered my question, but can you say more, please? Isn't it pretty much always game over when a threat actor has unauthorized access to a VM connected to your network? What's the scenario you're envisioning that makes these CVEs such a threat?
@dangoodin @GossiTheDog The threat actor doesn't need to be unauthorized, they could be merely unwitting - eg. a VDI user. It's not clear here (nor technically required) that a VM escape from a guest OS require root level privileges in the guest OS; it merely requires the right sequence of events and code paths to be possible to influence and escape into the outer process context the VM virtual CPUs run in.
@dangoodin@infosec.exchange @GossiTheDog@cyberplace.social I can't speak for Gossi but what I can say after reading through this the first thing that comes to mind here is virtual networking. I know VMWare is not that bad to setup virtual networks for. One of the things that I always do is make a virtual switch for my "management" vms (such as vCenter). Given that some of these allow you to modify vmx (and given that vmx controls a lot of things such as what network devices are passed to a vm) I would assume this allows a wide variety of things.
@dangoodin@infosec.exchange @GossiTheDog@cyberplace.social vCenter isn't exactly known for being robust or hardened. I'm unsure if there's any vCenter bugs that can be actively exploited but that allows you so much access if you can get into that just by joining your vm to the management network. Not to mention the ability to just take down a host by overallocating resources to yourself. Have you seen ESXi when its available cpu is over-utilized? shit turns into a brick and can barely be interacted with. I also agree with the other commentators, I'm not sure how common ESXi is in VPS offerings (all of mine typically identify as QEMU or OpenStack) but the risk is there too. Especially if you can escape your own network.