SURIQ
Read Broadcom's VMSA-2026-0006 as a flat list of five CVEs and you miss the point. Read it as an attack path and the priority is obvious: patch vCenter before anything else. The two critical vCenter flaws in this advisory are not two separate problems. One skips the login, the other runs code, and an attacker who can reach vCenter over the network does not have to choose. Put together, they place unauthenticated remote code execution on the single box that controls every host and every virtual machine you run.
Broadcom published the advisory on July 29, 2026, covering five vulnerabilities across VMware ESXi, vCenter, Cloud Foundation, vSphere Foundation, Workstation, and Fusion, as reported by The Hacker News. Three are rated critical. No exploitation has been reported. That last fact is the good news and the deadline at the same time.
Two vCenter flaws that add up to pre-auth code execution
CVE-2026-59309 is an authentication bypass in vCenter, scored CVSS 9.8. An attacker who can reach the service over the network can get past the login without valid credentials. On its own that is a serious access problem. CVE-2026-59310, also 9.8, is a directory traversal weakness that lets an attacker run arbitrary code on vCenter. On its own it needs a way in.
The desk's read is that these should be treated as one chain, not two line items. The first flaw supplies the access the second one needs. An unauthenticated attacker who can route packets to vCenter can bypass the login with the first bug and then execute code with the second, ending up with control of the management plane and no password spent along the way. None of the source coverage framed the pair as a single path, but that is how an operator should model the risk when deciding what to fix first.
Why vCenter first, and not the flashier VM escape? Because reachability decides urgency. vCenter is a network service that, in too many estates, sits on a management network a lot of things can touch. The two flaws that hit it need no prior foothold. We watched the same shape play out when a network attacker could took over VMware's Avi load balancer with no password two weeks ago, and when one missing setting exposed an OpenShift control plane. The management plane is the crown jewel, and it keeps being the softest reachable target.
| CVE | CVSS | Component | What an attacker gains | Precondition |
|---|---|---|---|---|
| CVE-2026-59309 | 9.8 | vCenter | Authentication bypass | Network access to vCenter |
| CVE-2026-59310 | 9.8 | vCenter | Arbitrary code execution | Network access to vCenter |
| CVE-2026-47876 | 9.3 | ESXi host (VMXNET3) | Code execution on the host (VM escape) | Local admin in a VMXNET3 guest |
The VM escape turns one compromised guest into a host takeover
CVE-2026-47876, scored 9.3, is the one that should worry anyone running shared or multi-tenant hosts. The bug lives in the VMXNET3 virtual network adapter, where a guest can trigger an out-of-bounds memory write. An attacker who already holds local administrative privileges inside a guest that uses that adapter can turn it into code running on the underlying ESXi host. Guests on other adapter types are out of scope, but VMXNET3 is a common default, so most running virtual machines qualify.
Here is the exposure translation the severity number hides. A VM escape collapses the boundary you are paying VMware to maintain. The precondition, admin inside a guest, sounds like a high bar until you remember what a guest often is: a low-value tenant workload, a lab box, a web server that a routine web bug already handed to an intruder. Once that one guest is theirs, this flaw promotes them from a single machine to the host, and from the host to every other virtual machine sharing it. In a co-located or multi-tenant rack, the blast radius is not one server, it is the neighbor's server too. We have seen the guest-to-host boundary fail before, when a guest reading its host's memory through QEMU broke the same trust line from the other direction.
No exploitation yet is not the all-clear
Broadcom says it has found no evidence any of these issues are being exploited, and no public proof-of-concept was circulating when the advisory landed, according to Security Affairs. Treat that as a countdown, not a reprieve. VMware's management and hypervisor stack is one of the most valuable targets in enterprise IT right now, because encrypting ESXi datastores lets a crew take down dozens of virtual machines from one place. Ransomware operators reverse-engineer high-value VMware patches quickly, and the historical gap between a critical VMware fix and working exploitation has been measured in weeks, not quarters.
The pattern is consistent across our coverage. The crews that hurt people most are not the ones burning zero-days, they are ransomware crews that live on unpatched infrastructure, and an entry point announced as a CVE is exactly what they wait for. We watched an auth bypass that became a ransomware front door follow that arc on a different vendor. A network-reachable vCenter auth bypass with a matching code-execution bug is the same kind of gift, on a bigger prize.
Patch order is the mitigation: vCenter, then hosts
The fix is the update, and the order is the strategy. For vCenter, the fixed build is 8.0 U3k. On Cloud Foundation and vSphere Foundation, the patched lines are 9.1.0.0300 and 9.0.2.0100. Check the advisory for the exact target that matches your release train, including the async patches for older Cloud Foundation deployments. Sequence the rollout by reachability:
- Patch vCenter first. Its two 9.8 flaws are network-reachable and need no foothold, so they are the first thing an outsider can touch.
- Patch the ESXi hosts next. The VM escape needs an attacker already holding admin inside a guest, a higher bar that buys you a little time the vCenter bugs do not.
- Update Workstation, Fusion, and the rest on their normal cadence once the server side is closed.
While the patch is in flight, close the reachability that makes the vCenter flaws easy. vCenter should not answer from a user or tenant network segment, and this advisory is a good reason to prove that today rather than assume it. If your management plane is flat with the rest of the estate, segmentation buys you as much risk reduction here as the update does. On the detection side, the signals worth watching are unexpected authentication successes against vCenter, new or unusual processes on ESXi hosts, and any guest suddenly touching host-level interfaces it never used before.
The severity math on this advisory is real, but it undersells the structure. Five CVEs is a patch cycle. Two chainable 9.8s on the box that runs your whole virtual estate, plus a VM escape that erases the guest-host boundary, is a management-plane emergency wearing a routine advisory's clothes. Patch vCenter before the attackers finish reading the same advisory you just did.