VMSA-2026-0006: Broadcom Patches CVSS 9.8 vCenter Auth Bypass and RCE
Broadcom published security advisory VMSA-2026-0006 on July 29, 2026, patching five vulnerabilities across VMware vCenter, ESXi, and Cloud Foundation. Two of them carry CVSSv3.1 scores of 9.8 — the kind of number that means “drop what you're doing.” Both are exploitable by an unauthenticated attacker with nothing more than network access to vCenter. Broadcom explicitly states there are no workarounds for either.
What Got Patched
The headliner is CVE-2026-59309 (CVSS 9.8): an authentication bypass in the VMware Directory Service that vCenter uses for identity. An attacker with network reach to vCenter can exploit it to skip authentication entirely and walk straight into the management plane — no credentials required. From there, they have full administrative control over every virtual machine, datastore, and workload the vCenter instance manages.
Paired with it is CVE-2026-59310 (also CVSS 9.8): a directory traversal flaw in vCenter's Syslog server that allows unauthenticated remote code execution. An attacker who can reach the service over the network can execute arbitrary code on the vCenter appliance itself. Taken together, these two flaws give an unauthenticated attacker the ability to compromise vCenter and then issue commands at the hypervisor level.
The third notable CVE is CVE-2026-47876 (CVSS 9.3): an out-of-bounds write in ESXi's VMXNET3 virtual network adapter driver. This one requires local administrative access inside a guest VM, but if an attacker already has that foothold — through a compromised workload, for instance — they can escape the VM entirely and execute code on the ESXi host. That means one compromised tenant can potentially pivot to the hypervisor and affect neighboring VMs.
Two lower-severity ESXi flaws round out the advisory: CVE-2026-41703 (CVSS 7.6), an out-of-bounds read that can lead to information disclosure or denial of service, and CVE-2026-41709 (CVSS 2.7), insufficient logging that lets malicious administrators act without generating an audit trail.
What Needs Patching and to What Version
Broadcom's patches are cumulative, so you update to the following builds to address all CVEs in the advisory:
- VMware vCenter 8.0 → update to
8.0 U3k - Cloud Foundation / vSphere Foundation 9.1.x → update to
9.1.0.0300 - Cloud Foundation / vSphere Foundation 9.0.x → update to
9.0.2.0100 - Cloud Foundation 5.x → apply the async patch to
vCenter 8.0 U3k - Telco Cloud Platform / Infrastructure 3.0–5.1.x → see KB449886
The ESXi patches for CVE-2026-47876 target builds ESXi 9.1.0.0200-25557999, 9.0.2.0100-25595025, and ESXi80U3k-25595708. Note that vSphere 8.0 U3k temporarily blocks the upgrade path to VCF 9.1 — Broadcom has acknowledged this and is working on guidance, but it does not change the security calculus: patch first, sort out the upgrade path after.
Why vCenter Is Always at the Top of the Target List
vCenter isn't just another server. It is the single pane of glass that controls an entire virtual environment — every VM, every virtual disk, every snapshot, every network, and every credential stored in that environment. Compromise vCenter and you own everything it manages, often without ever touching the individual guest operating systems.
Attackers know this. In January 2024, Broadcom confirmed that Chinese state-sponsored threat group UNC3886 had been exploiting a vCenter zero-day (CVE-2023-34048) since late 2021, deploying backdoors directly onto ESXi hosts via malicious vSphere Installation Bundles. In late 2024, a separate critical RCE in vCenter (CVE-2024-37079, also CVSS 9.8) was being exploited in the wild within a week of the patch dropping. By early 2026, Broadcom confirmed real-world exploitation of that same CVE had prompted CISA to add it to the Known Exploited Vulnerabilities catalog. The pattern is consistent: critical vCenter patches get exploited, and the window between “patch published” and “attacks in the wild” has been shrinking.
Ransomware operators in particular love VMware environments. Rather than encrypting files one by one, they can shut down all VMs on a host and encrypt the entire VMDK datastore in one pass. Recovery time goes from hours to days if backups aren't tested and isolated.
What Businesses Should Do Right Now
If your organization manages its own VMware infrastructure — on-premises or collocated — treat VMSA-2026-0006 as an emergency change, not a scheduled maintenance item. Neither CVE-2026-59309 nor CVE-2026-59310 has a documented workaround, which means the only mitigation is the patch.
- Patch vCenter immediately. Target the builds listed above. Broadcom's updates are cumulative, so a single update covers all five CVEs in the advisory.
- Audit vCenter's network exposure. vCenter should never be reachable from the public internet — management traffic belongs behind a VPN or on a dedicated management VLAN with firewall rules restricting access to known administrative source IPs.
- Check for the VM escape risk. If you run a multi-tenant VMware environment or host workloads from multiple teams, prioritize the ESXi patch for CVE-2026-47876. A compromised guest that can escape to the hypervisor level can undermine isolation guarantees across the entire host.
- Verify your backup posture. Encrypted VMDKs are recoverable only if you have offline or immutable copies. Now is the time to confirm your last restore actually worked — not after an incident. This is why restores get drilled.
- If you use managed hosting, ask the question. Find out whether your provider has applied VMSA-2026-0006. A provider running unpatched vCenter is a shared risk across every customer on that infrastructure.
There is no confirmed exploitation of CVE-2026-59309 or CVE-2026-59310 in the wild at the time of writing, and no public proof-of-concept code exists yet. That window won't stay open indefinitely. The historical playbook for critical vCenter vulnerabilities runs roughly: advisory published, PoC emerges within weeks, active exploitation follows. Broadcom has done its part by shipping the fix. The rest is on operators.
