Broadcom published VMSA-2026-0006 on 29 July, patching five vulnerabilities spread across VMware vCenter, ESXi, Workstation and Fusion. Two of them share the same maximum-but-one CVSS score of 9.8 and the same alarming property: neither requires an attacker to authenticate first. Coverage of the advisory lays out CVE-2026-59309, an authentication bypass in the VMware Directory Service that vCenter relies on for identity, alongside CVE-2026-59310, a directory-traversal flaw in vCenter's Syslog server that leads directly to remote code execution. A third critical issue, CVE-2026-47876, is a VM escape: an out-of-bounds write in ESXi's VMXNET3 virtual network adapter that lets an attacker with local admin rights inside a guest VM run code on the host itself, which SecurityWeek's reporting flags as the one multi-tenant environments should treat as most urgent, given what a single escaped guest can reach.
Two flaws, zero workarounds, one management plane
What separates CVE-2026-59309 and CVE-2026-59310 from a routine critical-severity patch cycle is that Broadcom hasn't published a workaround for either one. There's no configuration change, no mitigating control, no "disable this feature until you can patch" guidance - the only path off the vulnerable versions is the update itself. That's a deliberately narrow choice for a vendor to make, and it usually means the flaw sits close enough to the authentication core that a partial fix would be worse than no fix at all. Both land on vCenter, which is the single control point for an entire virtualised estate: an authentication bypass there isn't a foothold, it's the keys to every VM, datastore and network the vCenter instance manages.
This is the same shape of problem we've now written about three times this month in different products - Check Point's SmartConsole authentication bypass and Arista's VeloCloud Orchestrator command injection both handed an attacker the management layer rather than a single endpoint, and both carried the same "no password required" bluntness. vCenter is the highest-value version of that pattern we've covered yet, because unlike a single firewall console or SD-WAN orchestrator, it's the administrative layer for entire data centres. If your vCenter is reachable from anywhere other than a tightly scoped administrative network, these two CVEs are the argument for fixing that regardless of patch status.
No exploitation yet is a starting gun, not a stand-down order
Broadcom's own advisory is candid about what tends to happen next, noting that the pattern for critical vCenter vulnerabilities typically runs from advisory, to proof-of-concept within weeks, to active exploitation. Nothing about this disclosure suggests it will be the exception. vCenter's popularity as a target isn't accidental - security researchers and attackers alike know that a single working exploit against the management plane of a virtualisation platform this widely deployed is worth the reverse-engineering effort, and Broadcom's patch itself, once reverse-engineered, tells attackers exactly where the flaw lived. Waiting for confirmed in-the-wild exploitation before prioritising a fix has, in every comparable case this year, meant patching after the exploit was already circulating rather than before.
Fixed builds are available now: vCenter 8.0 should move to 8.0 U3k, Cloud Foundation and vSphere Foundation 9.1.x to 9.1.0.0300, the 9.0.x line to 9.0.2.0100, and ESXi to the corresponding 9.1.0.0200, 9.0.2.0100 or 80U3k builds. None of these are quick weekend changes for a large virtualised estate, which is exactly why the absence of a workaround matters - there's no interim step that reduces risk while the change window gets scheduled.
- Identify every vCenter, ESXi, Workstation and Fusion instance in your estate today and check its build number against the fixed versions in VMSA-2026-0006.
- Confirm vCenter is not reachable from the general corporate network, let alone the internet - there is no workaround for CVE-2026-59309 or CVE-2026-59310, so exposure reduction is your only interim control.
- Prioritise the ESXi VM escape fix (CVE-2026-47876) in any multi-tenant or shared-hosting environment, where a single compromised guest reaching the host has the widest blast radius.
- Treat this as an emergency change, not a routine patch cycle item - schedule the vCenter update ahead of your normal maintenance window given the lack of a mitigating control.
- Verify backup isolation and test a restore before you need it: an authentication-bypassed vCenter can be used to tamper with the same infrastructure your backups depend on.
Broadcom moved promptly once the flaws were found, and the fixes themselves are available today. The exposure that matters now is scheduling: a critical, workaround-free vCenter vulnerability sitting unpatched for a normal change-management cycle is exactly the gap the historical pattern says gets found. If you need help prioritising and sequencing an emergency patch across a large virtualised estate without breaking production along the way, email sales@halfteck.com.