VMSA-2026-0006 is the kind of advisory that is easy to read as routine and dangerous to treat that way. Broadcom published it on 29 July, fixing five separate vulnerabilities spread across vCenter Server, ESX and Cloud Foundation. Two of them, taken together, mean an attacker with nothing more than network access to vCenter can skip authentication entirely and then execute arbitrary code on the appliance that manages your virtualisation estate.
The two that matter most
CVE-2026-59309 is an authentication bypass in the VMware Directory Service, the component vCenter uses to handle identity and access. Broadcom rates it 9.8 out of 10, and the practical description is blunt: an attacker with network reach to vCenter can bypass authentication and gain unauthorized access to the management plane, no credentials required. CVE-2026-59310 sits alongside it at the same 9.8 severity, a directory traversal flaw in vCenter’s Syslog server that lets an unauthenticated attacker with network access execute arbitrary code directly on the vCenter appliance. Either one individually would justify emergency patching. Together they describe a single network-reachable service that can be fully compromised, and vCenter is not a peripheral system. It is the control plane for every VM, datastore and virtual network it manages.
A third flaw, CVE-2026-47876, rated 9.3, is an out-of-bounds write in the VMXNET3 virtual network adapter used by ESX. It requires local administrative privileges inside a guest VM, a materially higher bar than the vCenter pair, but it closes the gap between compromising a single virtual machine and escaping to the host underneath it. Two lower-severity issues, CVE-2026-41703 and CVE-2026-41709, round out the advisory.
No known exploitation yet is the reason to move now
Broadcom states there is no known evidence of active exploitation or a public proof-of-concept for any of the five flaws as of publication. It is worth being precise about what that means: it is not a signal to deprioritise this patch cycle, it is a description of the exact window in which patching still works as prevention rather than incident response. We have covered this pattern before with SharePoint’s CVE-2026-50522 and ADFS’s CVE-2026-56155, both of which moved from quiet advisory to active exploitation once a working proof-of-concept became public. The gap between disclosure and weaponisation has been shrinking across the board, and vCenter authentication bypasses are exactly the kind of high-value target that motivated researchers and criminal groups alike race to reverse-engineer first.
Why this carries extra weight for on-prem Europe
A significant share of European organisations, particularly in banking, healthcare, government and manufacturing, run VMware on-premises specifically because of data sovereignty and residency commitments that rule out shifting workloads to hyperscaler cloud. That choice concentrates enormous value in a single vCenter instance: control it, and you control every workload it touches, on infrastructure the organisation chose precisely to keep tightly held. An authentication bypass in that single control plane undercuts the sovereignty argument for keeping it on-prem in the first place, unless the patch actually gets applied before someone finds a way in without one.
If your organisation runs VMware vCenter or ESXi and needs help prioritising this patch cycle, reviewing how exposed your vCenter management interface actually is on your network, or building a faster path from vendor advisory to verified, deployed patch across your virtualisation estate, contact Excello Digital. We help European organisations keep on-premises infrastructure both sovereign and current.