I flagged VMSA-2026-0006 as a quick heads-up earlier today. Now that I have been through the actual advisory, I am upgrading it to a proper writeup, because this one is worse than the average VMware patch day. Broadcom has rated the advisory as a whole Critical, and two of the five bugs sit at CVSS 9.8.
It landed on 29 July 2026 and covers ESX, vCenter, Workstation and Fusion, along with everything that bundles them: VCF, vSphere Foundation, and the two Telco Cloud stacks. There are no workarounds. The fix is the patch.
If you run VMware Cloud Foundation or vSphere Foundation, this is squarely your advisory. Both are named on the impacted-products list. The fixed vCenter and ESX builds reach you through the VCF and VVF patch trains, so you apply them as a VCF or VVF async patch through SDDC Manager and vLCM rather than patching the components by hand.
Severity: Critical · Max CVSS 3.1 base score: 9.8 · Threat rating: Very High
A Critical, 9.8-rated advisory sits in the shortest patch window most vulnerability-management policies define, usually 14 days from disclosure. With two of these flaws unauthenticated and reachable over the network, I would treat that 14 days as the outer limit rather than the plan.
The short version
Two of these are unauthenticated, network-reachable flaws in vCenter. If an attacker can reach your vCenter over the network, they can get in without credentials. That is the kind of bug you patch this week rather than at the next maintenance window. The other three need some level of local access first, so they rank lower, but the vCenter pair is enough on its own to make this urgent.
The five CVEs
CVE-2026-59309, vCenter authentication bypass (Critical, 9.8). A flaw in the vCenter Directory Service. Anyone with network access to vCenter can bypass authentication and gain access. No login needed.
CVE-2026-59310, vCenter directory traversal (Critical, 9.8). This one sits in the vCenter syslog server. Network access to vCenter can be turned into arbitrary code execution.
CVE-2026-47876, ESX VMXNET3 out-of-bounds write (Critical, 9.3). A guest-to-host escape. A local admin inside a VM that uses the VMXNET3 adapter can run code on the ESX host underneath it. VMs on other adapter types are not affected.
CVE-2026-41703, out-of-bounds read (Important, 7.6 on ESX). Someone with VM deployment rights can trigger an out-of-bounds read, leading to information disclosure or, more likely, a denial of service on the host process. On Workstation and Fusion it drops to Low.
CVE-2026-41709, ESX insufficient logging (Low, 2.7). A rogue administrator could carry out certain operations without them being logged. Minor next to the rest, still worth closing.
Fixed versions
Patches are cumulative, so the build below for your line covers every CVE in this advisory. Match your platform, patch vCenter to that build first, then the hosts.
| Your platform | vCenter fixed build | ESX / ESXi fixed build |
|---|---|---|
| VCF / vSphere Foundation 9.1.x | vCenter 9.1.0.0300 | ESXi 9.1.0.0200 (25557999) |
| VCF / vSphere Foundation 9.0.x | vCenter 9.0.2.0100 | ESXi 9.0.2.0100 (25595025) |
| vSphere 8.0 | vCenter 8.0 U3k | ESXi 8.0 U3k (25595708) |
| VCF 5.x | Async to 8.0 U3k (KB88287) | Async (KB88287) |
On VCF 5.x this is an async patch to the 8.0 U3k line, documented in KB88287. If you run VxRail, hold for Dell’s matching bundle rather than patching vCenter out of band, or you will drop out of the supported VxRail matrix.
How I am handling it in the lab
Same routine I hand to clients, with the urgency dialled up for the two 9.8s.
Lock down vCenter access first. There is no workaround for the vCenter bugs, so the only interim control is exposure. If vCenter’s management interfaces are reachable from anywhere they have no business being, restrict that now, before you have even pulled the patch down.
Back up vCenter. Snapshot or file-based backup before you touch it. I have been burned enough times to treat this as non-negotiable.
Patch vCenter, then the hosts. vCenter to the fixed build for your line, then work the clusters host by host with vLCM. Doing hosts before vCenter has bitten me with compatibility warnings that were a pain to unwind.
Mind the VMXNET3 escape. CVE-2026-47876 only needs a local admin inside a guest, so any environment where you do not fully trust every VM admin should treat the ESX patch as part of the same push, not a follow-up for later.
Should you panic?
Closer to yes than usual. I have seen nothing yet to say these are being exploited in the wild, and none are on CISA’s KEV list at the time of writing. An unauthenticated auth bypass on vCenter is exactly the shape of bug that gets weaponised fast once the details are public, though. I would not sit on it.
Where to get the patch and the support documents
- VMSA-2026-0006, the full advisory on the Broadcom support portal, with the complete response matrix and every fixed-build download link.
- The supplemental FAQ for this advisory.
- Broadcom Support Portal for the patched builds.
- VMware Security Blog for the announcement and any follow-ups.
I will add my own notes once I have run the patches through the 9.0 and 9.1 labs. If you get there before I do and hit anything odd, drop a comment and let me know.