VMware patches multiple ESXi zero-days
- Broadcom shipped emergency fixes for three VMware ESXi zero-days after Microsoft found real-world exploitation that could let attackers break out of a guest VM. - The chain centers on CVE-2025-22224, CVSS 9.3, plus CVE-2025-22225 and CVE-2025-22226, which together can move an attacker from VMX to the host. - That matters because ESXi is the hypervisor layer — compromise there can expose every virtual machine on the server.
VMware ESXi is the software that lets one physical server run lots of virtual machines. That makes it incredibly efficient, but it also makes the hypervisor a high-value target — if someone breaks out of one VM and reaches the host, the blast radius gets much bigger. That is why Broadcom’s latest VMware advisory matters. It fixes three ESXi zero-days that were already being exploited in the wild, with Microsoft’s threat team credited for reporting them. ### What actually got patched? Broadcom’s advisory covers CVE-2025-22224, CVE-2025-22225, and CVE-2025-22226. The first is the headline bug — a critical TOCTOU flaw with a CVSS score of 9.3 in ESXi and Workstation that can let an attacker with local admin rights inside a guest VM execute code as the VMX process on the host. The second is an arbitrary-write flaw in ESXi, and the third is an information-disclosure flaw. Broadcom said it had evidence that all three had been exploited in the wild. (support.broadcom.com) ### Why is the VMX process such a big deal? Because VMX is the process that runs and manages a virtual machine on the host. If an attacker can jump from the guest into VMX, they have crossed the first wall. Broadcom says CVE-2025-22224 gets an attacker to code execution in that host-side process, and CVE-2025-22225 can then be used from within VMX to trigger an arbitrary kernel write that escapes the sandbox. Basically, this is the difference between “trapped inside one apartment” and “now holding keys to the building.” (support.broadcom.com) ### Does one bug do everything? Not quite. The important detail is the chain. Broadcom’s descriptions split the attack path into stages: guest admin privileges, then execution as VMX, then sandbox escape toward the ESXi kernel. CVE-2025-22226 adds an info leak that can help make the chain more reliable. So the danger is not just one isolated crash bug — it is a set of flaws that line up in a way defenders really hate. (support.broadcom.com) ### Who is exposed? Organizations running vulnerable ESXi hosts are the main concern, especially multi-tenant environments and internal virtualization clusters where a compromised VM could become a stepping stone. Workstation and Fusion were also affected by part of the issue set, but the host-level concern is sharpest on ESXi because that is the platform sitting underneath fleets of server workloads. Broadcom said there were no workarounds for these bugs — patching is the fix. (support.broadcom.com) ### Is this a full hypervisor escape? Broadcom’s wording is a little narrower than the scariest headlines, but the practical answer is close enough that defenders should treat it seriously. CVE-2025-22224 reaches VMX. CVE-2025-22225 is the sandbox-escape step. If an attacker can chain them, they can move from a guest VM toward control of the ESXi host. Once the host is in play, every VM on that server becomes part of the risk picture. (support.broadcom.com) ### Why does “zero-day” matter here? Because these were not just newly disclosed bugs. Broadcom explicitly said it had information suggesting in-the-wild exploitation. That changes the posture from routine patching to incident-response thinking — review exposure, patch fast, and assume attackers may already be testing for unpatched hosts. CISA’s KEV catalog exists for exactly this kind of situation, though the key fact here is Broadcom’s own exploitation note. (support.broadcom.com) ### What should admins do now? Apply the fixed ESXi builds Broadcom lists in the advisory and do not wait for a maintenance window if these hosts are internet-exposed or sit in sensitive environments. Also check for signs that a VM had unusual administrative activity, because the initial step requires strong privileges inside a guest. The catch is that once the host layer is threatened, containment gets harder fast. (support.broadcom.com) The bottom line is simple. A guest-to-host escape on ESXi is one of the worst classes of bugs a virtualization admin can get. Broadcom has patches out, there are no real workarounds, and the fact pattern already includes live exploitation. (support.broadcom.com)
