Broadcom published security advisory VMSA-2026-0006 on July 29, 2026, disclosing five vulnerabilities across vCenter Server, ESXi, Workstation, and Fusion. Two of them are as bad as vSphere bugs get: unauthenticated, network-exploitable, CVSS 9.8 flaws in vCenter Server with no available workaround. A third is a VM escape that lets a malicious guest execute code on the hypervisor itself. None are known to be exploited in the wild yet, but vCenter critical patches have a well-established pattern of getting weaponized within days of disclosure, and the fix requires an actual upgrade — there’s nothing to toggle off in the meantime.

What happened

CVE-2026-59309 (CVSS 9.8) is an authentication-bypass vulnerability in the VMware Directory Service (vmdird), the LDAP-based identity store vCenter uses for single sign-on. A network-adjacent attacker who can reach vCenter’s management interface can send crafted requests that fully bypass authentication, gaining the same access a legitimate administrator would have — no credentials, no valid session, no user interaction. Because vmdird underpins SSO for the entire vSphere management plane, a successful bypass hands the attacker control over every vCenter-managed host, VM, datastore, and network object in the environment.

CVE-2026-59310 (CVSS 9.8) is a directory-traversal vulnerability in vCenter’s Syslog server component that leads to arbitrary code execution. Combined with CVE-2026-59309, an attacker doesn’t even need the traversal bug to get in — the auth bypass alone is sufficient — but the RCE gives a second, independent path to full compromise of the vCenter appliance.

CVE-2026-47876 (CVSS 9.3) is a different class of bug: an out-of-bounds write in the VMXNET3 virtual network adapter used by ESXi guests. An attacker who already has local administrative privileges inside a VM configured with VMXNET3 can trigger the flaw to execute arbitrary code on the ESXi host itself — a full VM-to-hypervisor escape. This one matters most in multi-tenant or shared-hosting environments where “just” compromising a single guest shouldn’t translate into compromising the host and every other VM on it.

Two lower-severity issues round out the advisory: CVE-2026-41703 (high-severity, affecting ESXi, Workstation, and Fusion) and CVE-2026-41709 (low-severity, allowing an ESXi admin to perform certain actions without them being logged — an anti-forensics concern more than a direct compromise vector).

Technical details

  • CVE-2026-59309 — vCenter Server, VMware Directory Service (vmdird) authentication bypass. CVSSv3.1: 9.8. Unauthenticated, network-based, no user interaction.
  • CVE-2026-59310 — vCenter Server, Syslog server directory traversal leading to RCE. CVSSv3.1: 9.8. Unauthenticated, network-based.
  • CVE-2026-47876 — ESXi VMXNET3 adapter out-of-bounds write, guest-to-host VM escape. CVSSv3: 9.3. Requires local admin inside the guest VM.
  • CVE-2026-41703 / CVE-2026-41709 — high/low severity, ESXi/Workstation/Fusion.
  • Fixed versions: ESXi 8.0 Update 3k (build 25595708); ESXi 9.0.2.0100 (build 25595025) / ESXi 9.1.0.0200 (build 25557999); vCenter Server 8.0 Update 3k; vCenter Server 9.0.2.0100 / 9.1.0.0300.
  • Workarounds: none. Broadcom states there is no mitigation short of patching for either vCenter CVE.
  • Exploitation status: as of publication, no confirmed in-the-wild exploitation or public PoC for any of the five CVEs.

Impact

vCenter Server is the single management plane for most enterprise vSphere deployments — compromise it and you control every host, VM, and datastore it manages. An unauthenticated attacker with nothing more than network access to the vCenter management interface (often reachable from a compromised jump box, VPN foothold, or misconfigured internal segmentation) can go from zero to full administrative control via CVE-2026-59309 alone. Historically, critical vCenter RCEs have moved from patch release to active exploitation within about a week; a late-2024 vCenter RCE followed that exact pattern, and Broadcom itself has noted the window has been shrinking. The VMXNET3 escape is lower-urgency for single-tenant shops but critical for hosting providers, labs, and any environment where VM guests are handed to less-trusted parties.

Mitigation

  • Patch vCenter Server first — upgrade to 8.0 Update 3k, 9.0.2.0100, or 9.1.0.0300 as applicable. There is no workaround for CVE-2026-59309 or CVE-2026-59310, so this is not optional or deferrable.
  • Patch ESXi hosts to 8.0U3k / 9.0.2.0100 / 9.1.0.0200 to close the VMXNET3 escape, prioritizing hosts running VMs for less-trusted or multi-tenant workloads.
  • Restrict network access to vCenter’s management interface to a dedicated management VLAN or jump host as defense-in-depth while patching rolls out — these are unauthenticated, network-exploitable bugs, so exposure surface matters even before a public exploit exists.
  • Review vCenter and vmdird logs for anomalous authentication events or SSO activity that doesn’t correlate with known administrator sessions, particularly around the disclosure date.
  • Inventory VMs using VMXNET3 in shared or multi-tenant clusters and prioritize their hosts for the ESXi patch cycle.

Sources: Broadcom VMSA-2026-0006, Rapid7 — Critical VMware vCenter Vulnerabilities, The Hacker News — Three Critical VMware Flaws, BleepingComputer — VMware fixes three critical flaws.