Three Critical VMware vCenter Flaws Patched — Auth Bypass, RCE, and VM Escape

Three critical flaws, one patch cycle, no workarounds for the worst two — the exposure spans the vCenter management plane and the boundary between virtual machines, and none of it needs a valid login to reach.

PALO ALTO, CALIF. — Broadcom on July 29, 2026 published security advisory VMSA-2026-0006, patching multiple flaws across VMware ESX, vCenter, Workstation, and Fusion — three of them rated critical — including an authentication bypass and a remote code execution issue in VMware vCenter Server and a virtual-machine escape in VMware ESX, the company that now owns the VMware portfolio said.

The three critical flaws map to the three impact classes operators fear most in a virtualization platform. As reported by The Hacker News, and detailed in an Emergent Threat Response (ETR) writeup from Rapid7, the two vCenter flaws each carry a CVSS score of 9.8 and can be triggered by an unauthenticated actor with network access to a vulnerable server. This piece lays out what was disclosed, the fixed versions, and what operators should verify — without reconstructing how any of the flaws work.

What Broadcom Disclosed

The advisory, VMSA-2026-0006, addresses several vulnerabilities spanning VMware ESX, vCenter, Workstation, and Fusion, three of which Broadcom designated critical. Two sit in VMware vCenter Server, the centralized control plane administrators use to manage ESXi hosts, virtual machines, and resource allocation across a vSphere environment. The third sits in VMware ESX itself. Broadcom, which acquired VMware and now maintains the portfolio, said it found no evidence that any of the issues have been exploited in the wild.

CVE-2026-59309, rated CVSS 9.8, is an authentication bypass in the VMware Directory Service of vCenter. Per Broadcom, a malicious actor with network access to vCenter may exploit the issue to bypass authentication and gain unauthorized access to the system — in Rapid7's phrasing, to the vCenter management plane. CVE-2026-59310, also CVSS 9.8, is a directory-traversal vulnerability in the vCenter Syslog service that an actor with network access can leverage to execute arbitrary code. Both are remotely exploitable and, critically, require no prior authentication; an attacker needs only network reach to the affected services.

The third critical flaw, CVE-2026-47876 (CVSS 9.3), is an out-of-bounds write in the VMXNET3 virtual network adapter of VMware ESX. Broadcom characterized it as a virtual-machine escape: an actor who already holds local administrative privileges inside a guest that uses the VMXNET3 adapter may execute code on the underlying ESX host. Two lower-severity ESX issues were patched alongside — an out-of-bounds read (CVE-2026-41703, CVSS 7.6) that could lead to information disclosure or denial of service, and an insufficient-logging flaw (CVE-2026-41709, CVSS 2.7).

The Three Impact Classes in Defender Terms

Read together, the three criticals cover the impact classes that define virtualization-platform risk. An authentication bypass removes the front door: it lets an unauthenticated actor onto the management plane that governs every host and guest below it. Remote code execution turns network access into control: no credential is needed to run code on the vCenter server. And a virtual-machine escape breaks the isolation promise that multi-tenant and consolidated environments are built on — the assumption that code confined to one guest stays there.

The two vCenter flaws are the more urgent pair because they are unauthenticated and remotely reachable, and because vCenter is a high-value target: compromise of the control plane can hand an attacker broad authority over the virtualized estate and its workloads. Rapid7 notes that management interfaces such as vCenter are commonly restricted to internal or dedicated management networks, which reduces internet exposure but does not help against an actor who has already gained a foothold inside the network. The ESX escape requires an existing administrative position inside a guest, a higher bar — but one that matters wherever untrusted or semi-trusted workloads share a host.

What vCenter Operators Should Verify

Broadcom states there are no workarounds for CVE-2026-59309 or CVE-2026-59310, which makes applying the fixed builds the primary remediation. For the two vCenter flaws, the fixed versions are: VMware Cloud Foundation and vSphere Foundation 9.1.x.x updated to 9.1.0.0300; 9.0.x.x updated to 9.0.2.0100; standalone VMware vCenter 8.0 updated to 8.0 U3k; and Cloud Foundation 5.x via an async patch to 8.0 U3k. Telco Cloud Platform and Telco Cloud Infrastructure deployments are directed to Broadcom's KB449886. The VMXNET3 escape (CVE-2026-47876) is fixed in the corresponding ESXi builds, including ESXi80U3k for the 8.0 line. Operators can treat this with the same urgency as recent unauthenticated, no-workaround patch events such as the Microsoft SharePoint deserialization RCE and the Splunk Enterprise critical fix.

Beyond patching, the verification checklist is straightforward. Confirm the running vCenter build against the fixed versions above rather than assuming a recent appliance is current. Inventory every vCenter reachable from user or workload networks, and confirm management interfaces are restricted to dedicated management segments — a control that narrows, though does not close, the exposure window. For the ESX escape, note which hosts run guests using the VMXNET3 adapter, particularly where those guests run untrusted code. Because Broadcom reports no exploitation and no public exploit code yet, the window to patch ahead of a working exploit is open but should not be assumed to last.

The Virtual-Machine Escape Category and Hypervisor Security

The virtual-machine escape is the flaw class that most directly threatens the model virtualization sells: strong isolation between guests sharing physical hardware. When an escape exists, code that is fully contained at the guest level can reach the host and, from there, potentially other guests on the same machine — collapsing a boundary that backup, tenancy, and segmentation strategies all quietly depend on. It rhymes with the broader pattern of isolation and virtualization-adjacent risk The CyberSignal has tracked, from critical flaws in the Veeam backup-and-replication stack to the recurring lesson that the layer administrators trust most is the layer worth watching most closely.

CVE-2026-47876 is not a hypervisor break from an unprivileged guest — it requires local administrative rights inside a virtual machine first, which limits who can reach it. But it is a reminder that the device-emulation surface a hypervisor presents to its guests, including virtual network adapters like VMXNET3, is exactly where escapes tend to originate. For defenders running consolidated or multi-tenant estates, the practical takeaway is to treat guest administrative access as a meaningful trust boundary and to keep host builds current, because an escape turns a compromised guest into a compromised host.

Open Questions

A few specifics remain open at publication. Broadcom and Rapid7 report no known exploitation or scanning and no public proof-of-concept code, but that status can change quickly for a target as valuable as vCenter — Rapid7 points out the product has appeared on CISA's Known Exploited Vulnerabilities catalog ten times previously, so attacker interest in it is well established. None of the three CVEs are on the KEV catalog as of this writing.

Rapid7 said unauthenticated vulnerability checks for the two vCenter flaws were expected in its July 30 content release, and Broadcom's advisory is the authoritative source for the full affected-version matrix and fixed builds. As proof-of-concept code, exploitation reports, or a KEV addition emerge, the urgency calculus will sharpen — but with no workarounds for the worst two flaws, the defensible posture today is to patch on the schedule reserved for unauthenticated, critical, remotely reachable issues.

The CyberSignal Analysis

The reported facts above come from Broadcom's advisory and its reporting; what follows is The CyberSignal's editorial reading. None of the judgments below are new reported facts.

Signal 01 — The Unauthenticated Pair Sets the Clock

Our reading is that the two vCenter flaws, not the escape, set the tempo for this cycle. Both are CVSS 9.8, both are reachable without a credential, and neither has a workaround — a combination that leaves patching as the only lever. That is the profile of a bug that gets weaponized fast once someone bothers, and vCenter's history on the KEV catalog says someone usually does.

The practical move is to route this through the same fast lane an organization reserves for unauthenticated, remotely reachable criticals, rather than a routine maintenance window. The absence of exploitation today is a scheduling advantage, not a reason to wait.

Signal 02 — Network Restriction Is Mitigation, Not a Substitute

The detail worth internalizing is Rapid7's caveat that keeping vCenter on a management network reduces internet exposure but does nothing against an attacker already inside. Our assessment is that segmentation buys time and narrows the blast radius, and it remains worth doing — but treating it as a reason to defer the patch inverts its purpose.

The organizations that fare best here are the ones that both segment and patch, and that can quickly answer which of their vCenter instances are reachable from workload or user networks. That inventory question is the one to resolve first, because it determines how much the segmentation control is actually worth.

Signal 03 — The Escape Reframes Guest-Admin Trust

The most durable takeaway is about the escape's precondition rather than its severity. CVE-2026-47876 needs administrative access inside a guest before it can reach the host, which means the interesting question is how loosely guest-admin rights are handed out in consolidated estates. Our view is that this flaw quietly reprices that access: in an environment with an unpatched escape, a guest administrator is closer to a host administrator than the org chart suggests.

We would treat the patch as the immediate fix and the trust question as the lasting one — asking who holds administrative rights inside guests that share a host, and whether that mapping matches the isolation the architecture is assumed to provide.

Sources