Critical VMware vCenter Vulnerabilities: Authentication Bypass and Remote Code Execution (CVE-2026-59309, CVE-2026-59310)

Published: 1 August 2026

On 29 July 2026, Broadcom published security advisory VMSA-2026-0006, addressing multiple vulnerabilities across VMware ESX, vCenter, Workstation, and Fusion. Two of them stand out: CVE-2026-59309 and CVE-2026-59310, both rated Critical with a CVSSv3.1 base score of 9.8, and both exploitable by an unauthenticated attacker with nothing more than network access to vCenter Server.

If you run vSphere, this is an emergency change, not something to schedule for the next maintenance window.

Why this matters

vCenter Server is the control plane of the entire virtual estate. It manages ESXi hosts, virtual machines, permissions, templates, and datastores from one place. An attacker who compromises vCenter effectively owns the datacenter: they can access or exfiltrate VM data, deploy ransomware at scale, create rogue accounts, and pivot laterally into every connected workload. vCenter has appeared on CISA’s Known Exploited Vulnerabilities list ten times before, so attackers actively hunt for exactly this class of flaw.

The vulnerabilities

CVE-2026-59309: Authentication bypass in the VMware Directory Service

The VMware Directory Service (vmdir) underpins vCenter Single Sign-On and identity infrastructure. A malicious actor with network access to vCenter can exploit this flaw to bypass authentication entirely and gain unauthorized access to the system. No existing account, credentials, or user interaction is required. CVSS vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

CVE-2026-59310: Directory traversal in the vCenter Syslog server

The Syslog component of vCenter contains a path traversal flaw. A remote attacker with network access can abuse it to execute arbitrary code on the vCenter appliance, turning the management server into a beachhead for further compromise. Same CVSS score and vector as above.

Affected products and fixed versions

Note that patches are cumulative. On the 9.1 branch, the fix was first shipped in 9.1.0.0200, but 9.1.0.0300 is the latest release to include it.

The bad news: no workarounds

Broadcom explicitly states there are no workarounds for either CVE. Patching is the only real remediation. As of the advisory date, there is no known exploitation in the wild and no public proof of concept, but with two 9.8-scored, pre-auth, network-reachable flaws in a product with vCenter’s track record, that window will not stay open for long.

Solution: how to remediate

1. Identify your current version

From the vCenter appliance shell, run:

Here vpxd is the vCenter Server management daemon binary, and the -v switch prints the installed version and build number so you can compare against the fixed versions above. You can also read the version from the VAMI interface at https://:5480.

2. Take a backup before patching

Use the built-in file-based backup in VAMI, or take a cold snapshot of the VCSA VM (powered off, with memory removed) to have a clean rollback point.

3. Apply the patch

For vCenter 8.0, update to 8.0 U3k via VAMI (Update section) or from the CLI:

software-packages is the VCSA update utility, and the --url switch tells it to pull the patch payload from the default Broadcom online repository instead of a locally staged ISO. If your appliance has no internet access, stage the patch ISO and use --iso it instead, which points the installer at the mounted ISO image.

For VCF 9.x environments, apply 9.1.0.0300 or 9.0.2.0100 through the SDDC Manager lifecycle workflow. For VCF 5.x, follow the async patching guide in KB88287.

4. Verify

After the update completes and services restart, run vpxd -v again and confirm the build matches the fixed release. Verify that SSO logins, host connectivity, and backup jobs are functioning normally.

5. Reduce exposure while you schedule the change

Since there is no workaround, use compensating controls until the patch lands:

• Never expose vCenter to the internet. Verify with an external scan that ports 443, 636, and 389 are not reachable from outside.
• Restrict management-plane access to a dedicated admin network or jump hosts, enforced by firewall policy.
• Monitor vCenter and vmdir logs for anomalous authentication events and unexpected syslog traffic.
• Review recently created accounts and permissions in SSO after patching, in case of prior compromise.

One caveat for vSphere 8 environments

The 8.0 U3k patch temporarily blocks the upgrade path to VCF 9.1 because 8.0 U3k is newer than the code baseline that the current 9.1 upgrade workflow accepts. If you are mid-migration to VCF 9.1, factor this into your planning, but do not let it delay the security patch. The security risk outweighs the inconvenience of the upgrade.

Also in the same advisory

VMSA-2026-0006 covers three more CVEs worth noting: CVE-2026-47876 (CVSS 9.3), an out-of-bounds write in the VMXNET3 virtual adapter that enables a VM escape from a guest with local admin privileges to the ESX host, plus CVE-2026-41703 (out-of-bounds read) and CVE-2026-41709 (insufficient logging). Patch ESXi alongside vCenter.

Final thoughts

Two unauthenticated, network-reachable, 9.8-scored flaws in the virtualization control plane, with no workaround, are about as serious as a vSphere advisory gets. Treat this as an emergency change: patch vCenter first, patch ESXi next, tighten management network access, and keep evidence of remediation for your compliance records.

References

• Broadcom advisory VMSA-2026-0006: https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017
• Supplemental FAQ: https://brcm.tech/vmsa-2026-0006
• vCenter 8.0 U3k release notes: https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/vcenter-server-update-and-patch-release-notes/vsphere-vcenter-server-80u3k-release-notes.html
• Async patching guide for VCF 5.x: KB88287