No known actor — no exploitation and no public PoC at the time of publicationhigh
vCenter, two 9.8 flaws on the control plane — and Broadcom says there is no workaround
On 29 July 2026 Broadcom published VMSA-2026-0006, covering five vulnerabilities across VMware ESX, vCenter, Workstation and Fusion. Two affect vCenter and both carry a CVSSv3.1 score of 9.8: CVE-2026-59309, an authentication bypass in the VMware Directory Service, and CVE-2026-59310, a directory traversal in the Syslog server leading to code execution. Neither requires credentials, and Broadcom states there are no workarounds for either. No in-the-wild exploitation and no public exploit code were known at publication — but vCenter has already appeared ten times in CISA's KEV catalog for other flaws.
The piece that holds everything else up
Every virtualised data centre has an implicit hierarchy, and it is rarely said out loud. At the top are not the application servers, nor the databases, nor the firewalls. At the top is the console that decides where all of them run. In a VMware environment that console is vCenter Server: it administers ESXi hosts, virtual machines, resource allocation, availability. Whoever controls vCenter has not compromised a system. They have compromised the place where decisions about all the other systems are made.
On 29 July 2026 Broadcom published advisory VMSA-2026-0006, gathering five vulnerabilities across VMware ESX, vCenter, Workstation and Fusion. Individual severities range from 2.7 to 9.8 on CVSS 3.1, and the bulletin as a whole is rated Critical. Two of the five affect vCenter, and those are the ones worth stopping on.
The two that matter
CVE-2026-59309 is an authentication bypass in vCenter's VMware Directory Service. A remote attacker with network access to the vulnerable service can bypass authentication controls and gain unauthorised access to the management plane. The Directory Service answers the question "who are you and what may you do" inside vSphere: a flaw there is not a way into a room, it is a way into the front desk.
CVE-2026-59310 is a directory traversal in vCenter's Syslog server that lets an attacker with network access execute arbitrary code. The operational irony is worth noting: the service that collects logs — the very tool meant to help you notice an intrusion — becomes the way to carry one out.
Both are network-vector, low-complexity, with no privileges required and no user interaction: that combination is what pushes the score to 9.8. And for both, Broadcom states there are no workarounds, which means the fixed release is the only remediation available.
What we do not know, stated plainly
At the time of Rapid7's analysis — 30 July 2026 — there was no known in-the-wild exploitation and no known scanning tied to these two CVEs, and no public proof-of-concept code. Neither appears in CISA's KEV catalog: the current version, 2026.07.29, does not list them.
That is a real difference from recent dossiers on flaws already under attack, and it should be said rather than glossed over: there is no attack under way here today, there is a window. Why the window closes fast is captured by one piece of context from Rapid7: vCenter Server has appeared in KEV ten times in the past for other vulnerabilities. It is a product attackers watch, and the gap between disclosure and exploitation on this class of product keeps shrinking.
The comfort that is not a fix
One argument will come up in every meeting over the next few days: vCenter is not exposed to the internet, it sits on the management network. In most serious organisations that is true, and it is good practice — the kind that holds even before you know about the flaw.
But read it for what it is. Rapid7 spells it out: restricting management interfaces to internal or dedicated networks reduces exposure to internet-based attacks, but does not mitigate the risk from an attacker who has already established access inside the organisation's network. And getting inside the network, in the typical 2026 attack chain, is the easy part: a credential stolen by phishing, an intercepted session, a compromised supplier.
Put differently: segmentation turns these two CVEs from a perimeter flaw into an escalation flaw. It does not defuse them. And when the target is vCenter, escalation goes very high, very fast.
- 01Any foothold in the networkstolen credential, supplier, appliance
- 02Network access to vCenterfrom the management network, if reachable
- 03vSphere control planeESXi hosts, virtual machines, backups, snapshots
What to do, in order
First: know which versions you run. Fixes are already out. For vCenter 9.1.x.x the fixed release is 9.1.0.0300; for 9.0.x.x it is 9.0.2.0100; for vCenter 8.0 it is 8.0 U3k. VMware Cloud Foundation 5.x moves to 8.0 U3k via an async patch. For Telco Cloud Platform (3.0, 4.x, 5.0.x, 5.1.x) and Telco Cloud Infrastructure (3.0), Broadcom points to knowledge base article KB449886: if you run those, your answer is there and not in the general table.
Second: treat this as an urgent patch, not a routine one. Not because an attack is under way, but because the cost of guessing wrong is asymmetric. If the window closes before an exploit lands, you performed scheduled maintenance. If it closes after, you are rebuilding trust in every virtual machine running on that infrastructure.
Third: use the occasion to check the management network as it actually is — not as documented. Who reaches it, from where, with what authentication. That check is useful today for vCenter and will be identical for the next advisory on a product you have not thought about yet.
A note on sourcing: the technical detail, fixed versions and the absence of workarounds come from the Broadcom advisory and Rapid7's analysis. The non-exploitation status is a snapshot as of 30 July 2026 and can change at any moment; when it does, the KEV catalog will be the first place to see it.
