VMSA-2026-0006.1: Critical vCenter Auth Bypass and ESXi VM Escape Flaws You Need to Patch Now

Broadcom’s VMSA-2026-0006.1 advisory patches a set of critical VMware vCenter and ESXi vulnerabilities, two of them with a maximum CVSS score of 9.8, at the same time ransomware groups have been increasingly targeting Hyper-V and ESXi hosts specifically because encrypting a single hypervisor takes down every virtual machine it hosts at once. If you run VMware infrastructure and haven’t patched to the versions this advisory specifies, this is worth treating as urgent, not routine maintenance.

What’s actually in VMSA-2026-0006.1

The advisory covers five CVEs across VMware ESX, vCenter, Workstation, and Fusion. Three matter most for anyone running production virtualization infrastructure:

• CVE-2026-59309 (CVSS 9.8): an authentication bypass vulnerability in vCenter’s Directory Service. A malicious actor with only network access to vCenter, no valid credentials required, can exploit this to bypass authentication entirely and gain unauthorized access to the system.
• CVE-2026-59310 (CVSS 9.8): a directory traversal vulnerability in vCenter’s Syslog server. Network access alone is enough for a malicious actor to exploit this into arbitrary code execution.
• CVE-2026-47876 (CVSS 9.3): a VM escape vulnerability, an out-of-bounds write in the VMXNET3 virtual network adapter. This one requires the attacker to first have local administrator or root-level privileges inside a VM that uses VMXNET3, at which point they can execute code on the underlying ESX host itself, breaking out of the VM boundary entirely.

The two vCenter vulnerabilities are the more urgent pair precisely because they need no prior access at all, just network reachability to vCenter. The VM escape requires an attacker to already control a VM, but that is a realistic starting position, a compromised web application server or a VM breached through an unrelated vulnerability is a common real-world starting point, and VM escape is exactly the technique that turns “one VM is compromised” into “the entire host and every VM on it is compromised.”

Why VM escape and vCenter compromise both matter more than a typical CVE

Most vulnerabilities affect a single system. A vCenter authentication bypass affects every host and VM that vCenter manages, since vCenter is the central control plane for your entire virtual infrastructure. A VM escape breaks the fundamental isolation assumption that virtualization is built on, once an attacker can execute code on the hypervisor itself, every other VM on that host, regardless of how well-secured each individual VM is, becomes reachable too.

This combination is also exactly why ransomware groups have shifted focus toward hypervisor-level targets rather than individual servers. Encrypting a single ESXi host’s datastore can take down dozens of VMs in one action, which is a far more efficient attack than compromising each VM individually. Treat any hypervisor-level vulnerability, VM escape especially, with a higher urgency than an equivalent CVSS score on a single-purpose server.

Patch versions, confirmed directly from Broadcom’s advisory

# vCenter Server (CVE-2026-59309, CVE-2026-59310):
# Fixed in vCenter Server 8.0 Update 3k
# Fixed in VMware Cloud Foundation / vSphere Foundation 9.1.0.0300
# Fixed in VMware Cloud Foundation / vSphere Foundation 9.0.2.0100

# Check your current vCenter build:
# vCenter Server Management Interface -> Summary -> Build Number
# or via SSH to the vCenter Server Appliance:
vpxd -v

Confirm your actual patch level against the specific build numbers in Broadcom’s advisory directly rather than assuming a “recent” update covers this, VMware version numbering across vSphere, VCF, and vSphere Foundation branches is easy to mismatch against a specific advisory if you’re checking from memory rather than the advisory itself.

Immediate steps if you can’t patch right away

If patching vCenter or ESXi hosts requires a maintenance window you can’t get immediately, reduce exposure in the meantime:

• Restrict network access to vCenter’s management interface to only the specific administrative networks and jump hosts that need it, removing any broader network reachability, since both critical vCenter CVEs require only network access, not credentials.
• Review which VMs use the VMXNET3 adapter and are also exposed to less-trusted workloads or users, since CVE-2026-47876 specifically requires VMXNET3 to be in use.
• Increase monitoring on vCenter authentication logs and any syslog-related activity for the affected components while the patch is pending, so an exploitation attempt during the gap is more likely to be caught.

Frequently asked questions

Does patching ESXi alone cover CVE-2026-59309 and CVE-2026-59310?
No. Those two are vCenter-specific vulnerabilities, not ESXi vulnerabilities. You need to patch vCenter Server itself (or your VMware Cloud Foundation / vSphere Foundation deployment) to the versions listed in VMSA-2026-0006.1, patching only your ESXi hosts leaves these two unaddressed.

If I only run a single standalone ESXi host with no vCenter, am I exposed to all three of these?
The two vCenter vulnerabilities do not apply to you if you have no vCenter deployment at all. The VM escape vulnerability (CVE-2026-47876) does still apply if you run VMs using the VMXNET3 adapter, since that is an ESXi-level vulnerability independent of vCenter.

How urgently should I treat this compared to a normal monthly patch cycle?
Broadcom itself is treating these as emergency fixes given the CVSS 9.8 scores on the vCenter vulnerabilities and the fact that no authentication is required to exploit them. Combined with the current trend of ransomware groups specifically targeting hypervisor infrastructure, this is a patch-now situation for any internet-reachable or broadly network-accessible vCenter instance, not something to fold into your next scheduled maintenance window.