Three Critical VMware Flaws Put vCenter and ESX Hosts at Risk

Broadcom has patched three critical VMware vCenter vulnerabilities, plus a fourth flaw in the ESX hypervisor. Two of the bugs score 9.8 out of 10 on the CVSS scale. That is close to the maximum possible. If your business runs vCenter Server or ESX hosts, this week’s patch is not routine. Treat it as urgent, not something to schedule for later.

What the VMware vCenter vulnerabilities actually are

The advisory is VMSA-2026-0006, published on 29 July. It covers five separate flaws, and two of them sit in vCenter itself. CVE-2026-59309 is an authentication bypass in the VMware Directory Service. An attacker just needs network access to vCenter. They need no valid credentials at all. They can walk past the login and reach the management plane directly. CVE-2026-59310 is a separate bug, a directory-traversal flaw in the vCenter syslog server. It lets that same kind of unauthenticated attacker run their own code on the server. Both bugs carry a 9.8 severity score.

The third critical flaw in this batch of VMware vCenter vulnerabilities sits lower in the stack, on the hypervisor. CVE-2026-47876 is an out-of-bounds write in the VMXNET3 virtual network adapter. It is rated 9.3. Security teams call this a VM escape. A user with admin rights inside one virtual machine can break out. From there, they can run code on the physical ESX host underneath it. That matters a great deal. A VM escape breaks the basic promise of virtualisation: that one compromised guest stays contained inside its own box.

Two lower-severity issues round out the list. CVE-2026-41703 is an out-of-bounds read. It can leak information or crash a host process. It scores 7.6 on ESX, but only 2.7 on Workstation and Fusion. CVE-2026-41709 is a logging gap on ESX. It lets administrative actions go unrecorded, which is handy for an attacker who wants to cover their tracks.

Who is affected

The list of products touched by these VMware vCenter vulnerabilities is long. It includes ESX, vCenter Server, Workstation, Fusion, VMware Cloud Foundation, vSphere Foundation, and the Telco Cloud Platform and Infrastructure products. Fixed builds are already out, including vCenter 9.1.0.0300, 9.0.2.0100 and 8.0 U3k, alongside matching ESX and Workstation or Fusion updates. Because Broadcom’s patches are cumulative, you do not need to install a chain of older updates first. Just apply the latest build for your branch.

Broadcom says it has no evidence that any of the five flaws have been used in a real attack yet. Take that at face value today, but do not relax. That kind of claim rarely stays true for long once a patch is public. Researchers often reverse-engineer a vendor’s fix within days and turn it into a working exploit. VMware infrastructure has also been a favourite ransomware target since the ESXiArgs campaigns, which showed how much damage one hijacked hypervisor can do to an entire estate.

Why this matters beyond the patch itself

What stands out here is the combination of bugs. Chain the login bypass with the code flaw in vCenter, and an attacker gets full control of the console. That console runs every virtual machine, datastore and network segment in a vSphere estate. They do this without stealing a single password. Add a VM escape on top, and the attacker does not even need a route into vCenter first. Compromising one under-patched guest VM, say through a web app flaw or a phished login, is enough to reach the host and everything else running on it.

Most businesses do not expose vCenter to the internet directly. So the real risk from CVE-2026-59309 and CVE-2026-59310 depends less on your firewall and more on how well your internal network segmentation actually holds up. That is exactly the question internal network penetration testing is built to answer. Can a foothold in an ordinary user segment actually reach a sensitive management interface like vCenter? Many businesses assume the answer is no, and have never checked.

What to do now

Fixing these VMware vCenter vulnerabilities starts with the patch itself. First, apply it to vCenter and ESX against VMSA-2026-0006 as soon as a maintenance window allows. Start with any vCenter instance that sits on a wider network segment than it strictly needs to. Next, check which of your VMs still use the VMXNET3 adapter, since that is the specific driver tied to the escape bug. After that, prioritise the hosts running VMs for less-trusted users or outside contractors. Then ask a simple question: who can actually reach the vCenter management interface today? If the honest answer includes more of the network than it should, that gap needs fixing regardless of this particular advisory.

None of this is exotic advice. It is the same discipline that applies to any serious infrastructure patch. Know your exposure. Patch the reachable systems first. Then use the incident as a reason to test the assumptions behind your network design, rather than just closing the ticket and moving on.

A familiar pattern for VMware

This is not the first time a vCenter or ESX flaw has forced businesses to move fast. The ESXiArgs ransomware campaigns showed how quickly attackers weaponise a known VMware bug once it goes public, often within days rather than weeks. They also showed how much damage one compromised hypervisor host can do, since it can take an entire cluster of guest VMs down at once. That history is why security teams treat VMware advisories differently from an ordinary software update. The blast radius of one host rarely stays limited to one host.

It is also why the small logging gap in CVE-2026-41709 deserves more attention than its low score suggests. On its own, a flaw that leaves ESX admin actions unrecorded does not let anyone in. But paired with any of the more serious bugs in this advisory, it means a business could be compromised with no reliable audit trail. There would be no way to prove what happened, or work out how the attacker got in. So fixing the access problem without fixing the visibility problem leaves a business patched, but still blind. That is the wider lesson in this batch of VMware vCenter vulnerabilities: patch the hole, then check whether you would even notice next time.