Broadcom published VMSA-2026-0006 on July 29, 2026. It carries three critical vulnerabilities across vCenter Server and ESXi, two of them unauthenticated and remotely exploitable at CVSS 9.8, and none of them with a workaround. For most virtualization teams this is a patch-now advisory, but “patch now” is not a plan when vCenter is a single point of management for the estate and the maintenance window is contested.
Here is what is in the advisory and how to sequence it.
The three vulnerabilities
CVE-2026-59309 — authentication bypass in VMware Directory Service. CVSSv3.1 9.8. A remote, unauthenticated attacker with network access to vCenter can bypass authentication and gain access to the management platform. This is the one that should set your priority. There is no privilege prerequisite and no user interaction — network reachability to the vCenter service is the entire precondition.
CVE-2026-59310 — directory traversal in the vCenter Syslog server. CVSSv3.1 9.8. An attacker with network access can exploit this to execute arbitrary code on the vCenter appliance. Also unauthenticated.
CVE-2026-47876 — VM escape in the VMXNET3 virtual network adapter. CVSSv3 9.3. An attacker with administrator privileges inside a guest VM can execute code on the underlying ESXi host. The privilege prerequisite makes this lower priority than the two above in most environments — but read the next section before concluding that.
Broadcom states there are no workarounds for CVE-2026-59309 or CVE-2026-59310. Vendor updates are the remediation. At the time of publication there was no known evidence of exploitation or scanning in the wild and no public proof-of-concept, which is the window you are trying to patch inside rather than a reason to relax.
Fixed versions
| Product | Fixed version |
|---|---|
| vCenter 9.1.x | 9.1.0.0300 |
| vCenter 9.0.x | 9.0.2.0100 |
| vCenter 8.0 | 8.0 U3k |
| Cloud Foundation 5.x | 8.0 U3k (async patch) |
The Cloud Foundation path is an async patch rather than a bundled release, which is a common source of “we thought we were covered” — VCF environments do not pick this up through the normal VCF release cadence.
Why vCenter compromise is different from a normal RCE
The reason these two flaws deserve to jump the queue past other 9.8s in your backlog is blast radius rather than exploitability.
vCenter is not a workload. It is the control plane for the workloads. An attacker with vCenter administrative access can typically enumerate the entire virtual estate, clone or snapshot any VM (extracting its disk contents without ever touching the guest OS or triggering a single in-guest security control), deploy new VMs, move workloads across hosts, and manipulate or destroy backups that live inside the same virtualization stack.
That last point is the one that reframes the priority. Ransomware operators have spent several years moving up the stack precisely because encrypting at the hypervisor layer bypasses in-guest EDR entirely and takes down the recovery path at the same time. A vCenter authentication bypass is a direct route into that position.
The practical implication: this is a vulnerability where your in-guest security investments provide almost no compensating control. The controls that matter are network reachability to the management plane and the integrity of your backups.
Sequencing the work
1. Establish who can reach vCenter over the network, right now. This is the highest-value hour you can spend, and it is useful whether or not you patch tonight. Both critical flaws require network access to the vCenter service. If vCenter is reachable from general user VLANs, from VPN pools, or — worst case — from the internet, that exposure is the actual risk, and constraining it is faster than a change window in most organizations. A management plane reachable only from a jump host on a dedicated network materially changes your exposure while you schedule the patch.
2. Patch vCenter before ESXi. Two unauthenticated remote flaws outrank one that requires guest-admin privileges. vCenter is also a single appliance rather than a fleet, which usually makes it the faster change to land.
3. Then work the ESXi fleet for the VMXNET3 escape. The guest-administrator prerequisite is a real constraint, but do not read it as “internal only.” It means “any workload where someone can get admin in the guest” — which includes any internet-facing VM with an exploitable service, any multi-tenant or hosted environment where customers legitimately hold guest admin, and any development VM where developers hold local admin as a matter of routine. In a hosting or shared-tenancy environment, treat this as equivalent in urgency to the vCenter flaws, because the prerequisite is satisfied by design.
4. Confirm your backups are outside the blast radius. If your backup infrastructure authenticates to vCenter, stores its data on datastores managed by the same vCenter, or runs as a VM inside the cluster it protects, then a vCenter compromise reaches your recovery path. This advisory is a reasonable trigger to verify that at least one restore path does not depend on the compromised control plane.
5. Look for evidence of prior access. Absence of known in-the-wild exploitation at publication is not evidence that a given environment is clean, particularly if vCenter has had broad network exposure. Worth reviewing: vCenter SSO authentication logs for anomalous or unattributable sessions, newly created local accounts or permission grants, unexpected snapshot or clone operations, and any VM export activity out of pattern.
After the patch
Two follow-ups worth carrying beyond this advisory.
Management-plane isolation is the durable control. Both critical flaws are neutralized in practice by an environment where the vCenter management interface is not broadly reachable. Every future vCenter advisory of this shape will be too. If this advisory generates one architectural change, make it that one, because it retires an entire recurring class of emergency.
Note where your vCenter version sits in the support lifecycle. Environments still on 8.0 are consuming update-release patches; the further behind the current branch you sit, the more often the fixed version requires a larger jump than a point patch. That is a planning input for the next advisory, not this one.