Broadcom Patches Critical VMware vCenter RCE and ESXi VM-Escape Vulnerabilities

Two of the vulnerabilities carry CVSS scores of 9.8 and can be exploited through network access to VMware vCenter, while a separate ESXi flaw could allow an attacker controlling a virtual machine to execute code on the underlying host.

Broadcom has released security updates for five vulnerabilities affecting VMware vCenter, ESX/ESXi, Workstation, Fusion and several VMware infrastructure platforms.

Three of the vulnerabilities are rated critical. The most serious include an authentication-bypass flaw and a directory-traversal vulnerability in vCenter, both carrying CVSS scores of 9.8.

A third critical vulnerability affects the VMXNET3 virtual network adapter used by VMware ESXi. Under specific conditions, an attacker who already controls a virtual machine could exploit the flaw to break out of the guest environment and execute code on the underlying host.

Broadcom disclosed the vulnerabilities on July 29 under security advisory VMSA-2026-0006 and published fixed versions for the affected products. The company has not provided workarounds for any of the five vulnerabilities.

At the time of disclosure, Broadcom said it was not aware of the vulnerabilities being exploited in real-world attacks.

Two critical flaws expose the vCenter management layer

The most immediately concerning vulnerabilities affect VMware vCenter Server, which organisations use to centrally manage ESXi hosts, virtual machines, permissions and other components of their VMware infrastructure.

The first vulnerability, tracked as CVE-2026-59309, is an authentication-bypass issue in VMware Directory Service.

According to Broadcom, an attacker with network access to a vulnerable vCenter instance may be able to bypass authentication and obtain unauthorised access to the system.

The vulnerability has been assigned a maximum CVSS score of 9.8 out of 10.

The second vCenter vulnerability, CVE-2026-59310, is a directory-traversal issue in the platform’s Syslog server.

Broadcom said an attacker with network access to vCenter could exploit the vulnerability to execute arbitrary code. It also carries a CVSS score of 9.8.

Both vulnerabilities are particularly important because Broadcom’s attack descriptions do not require the attacker to possess an authenticated vCenter account.

That does not automatically mean every vulnerable vCenter deployment can be compromised directly from the public internet. The attacker must still be able to reach the affected service over the network.

However, organisations that expose vCenter unnecessarily—or allow overly broad access from internal networks—face a more serious risk because exploitation could target the central management layer of their VMware environment.

A compromised vCenter server could potentially provide an attacker with access to valuable information and management capabilities across multiple hosts and virtual machines, depending on the privileges gained and the environment’s configuration.

Critical ESXi flaw could allow VM escape

Broadcom also patched CVE-2026-47876, a critical out-of-bounds write vulnerability in the VMXNET3 virtual network adapter.

VMXNET3 is a paravirtualised network adapter designed to provide high-performance networking for VMware virtual machines.

According to Broadcom, an attacker with local administrative privileges inside a virtual machine using VMXNET3 may be able to exploit the flaw and execute code on the underlying ESXi host.

The vulnerability has received a CVSS score of 9.3 and is described as a virtual-machine escape issue.

This vulnerability does not give an unauthenticated external attacker immediate control of an ESXi host.

The attacker must first obtain administrative control inside an affected virtual machine. The guest must also be configured with the VMXNET3 virtual network adapter. Broadcom confirmed that virtual machines using other virtual network adapters are not affected by this particular vulnerability.

Even with those prerequisites, the vulnerability is significant.

Virtualisation security depends heavily on the isolation boundary between a guest virtual machine and its host. An attacker who escapes that boundary could move from controlling one virtual machine to executing code at the hypervisor level.

In a successful attack, this could place other workloads running on the same host at risk and turn an initially isolated server compromise into a much broader infrastructure incident.

The flaw was reported to Broadcom by STARLabs SG researcher Nguyen Hoang Thach through Trend Micro’s Zero Day Initiative following work connected to Pwn2Own.

Two additional vulnerabilities affect VMware products

The advisory also includes two less severe vulnerabilities.

CVE-2026-41703 is an out-of-bounds read vulnerability affecting VMware ESX, Workstation and Fusion.

An attacker with permission to deploy virtual machines may be able to trigger the flaw, potentially causing information disclosure or a denial-of-service condition in the host process.

Broadcom rated the vulnerability as important for ESX, with a maximum CVSS score of 7.6. On VMware Workstation and Fusion, the impact is limited to information disclosure and the vulnerability is rated low severity.

The fifth vulnerability, CVE-2026-41709, is an insufficient-logging issue affecting VMware ESX.

Broadcom said a malicious administrator could exploit the flaw to perform certain operations without those activities being recorded in the expected logs.

The vulnerability carries a CVSS score of 2.7 and is rated low severity. However, gaps in administrative logging can still complicate investigations by reducing the evidence available to security and incident-response teams.

Which VMware products are affected?

Broadcom’s advisory covers the following products and platforms:

• VMware vCenter Server
• VMware ESX and ESXi
• VMware Workstation
• VMware Fusion
• VMware Cloud Foundation
• VMware vSphere Foundation
• VMware Telco Cloud Platform
• VMware Telco Cloud Infrastructure

The exact exposure varies by product and version. Not every vulnerability affects every product included in the advisory.

For example, the two CVSS 9.8 vulnerabilities specifically affect vCenter, while the VM-escape issue affects ESX environments using VMXNET3.

Broadcom has released patched versions for supported VMware 8.x and 9.x environments, along with product-specific remediation instructions for Cloud Foundation and VMware’s telecommunications platforms.

For vCenter 8.0, Broadcom lists vCenter Server 8.0 Update 3k as the fixed version.

For ESXi 8.0, ESXi 8.0 Update 3k addresses the critical VMXNET3 vulnerability. Broadcom has also published corresponding updates for VMware 9.0 and 9.1 product lines.

Administrators should use the response matrix in Broadcom’s advisory rather than relying only on a general version number, as the required update depends on the deployed VMware product and release branch.

Why this advisory deserves immediate attention

The importance of this disclosure comes from the combination of two separate attack paths.

The vCenter vulnerabilities threaten the management plane.

An attacker able to reach a vulnerable vCenter system could potentially bypass authentication or execute code without first compromising a virtual machine.

The ESXi vulnerability threatens the isolation layer.

An attacker who has already obtained administrative control of a VM could potentially use the VMXNET3 flaw to cross from the guest environment into the host.

These are different scenarios and should not be treated as a single attack chain without evidence. However, together they affect two of the most sensitive layers in a VMware deployment: the system used to manage the virtual infrastructure and the hypervisor responsible for isolating workloads.

VMware products are also attractive targets because compromising a virtualisation platform can give attackers leverage over many systems at once.

Ransomware groups and other advanced threat actors have repeatedly targeted virtual infrastructure during enterprise attacks because encrypting, shutting down or taking control of hypervisor environments can cause widespread operational disruption.

There is currently no evidence that these newly disclosed vulnerabilities have been exploited in those types of attacks. Still, their severity and the absence of temporary workarounds make delayed patching a risky choice.

What VMware administrators should do now

Organisations running affected VMware products should first identify the exact vCenter, ESXi, Workstation and Fusion versions currently deployed.

They should then compare those versions against the fixed releases listed in Broadcom advisory VMSA-2026-0006 and plan updates based on exposure and operational criticality.

Internet-facing or broadly accessible vCenter instances should receive the highest priority because the two critical vCenter vulnerabilities can be reached over the network without prior authentication.

Administrators should also review which virtual machines use VMXNET3. Disabling or replacing the adapter may cause operational or performance issues and Broadcom has not documented it as an official workaround, so organisations should not treat configuration changes as a substitute for installing the security update.

Because no vendor-supported workarounds are available, patching is the only remediation currently provided for the critical vulnerabilities.

Security teams should also review vCenter and ESXi access paths, confirm that management interfaces are not unnecessarily exposed, and examine recent administrative activity for anything inconsistent with normal operations.

Those reviews should be treated as a precaution rather than evidence of exploitation.

No active exploitation confirmed

Broadcom’s advisory confirms the vulnerabilities and the availability of security updates, but it does not report any known attacks exploiting them.

There is also no public evidence at this stage linking the flaws to ransomware groups, nation-state operators or other identified threat actors.

The vulnerabilities should therefore be described as critical security risks—not as actively exploited zero-days.

That distinction matters.

The vCenter issues are serious because they may allow unauthenticated network-level attacks, while the ESXi issue could enable a guest-to-host escape after an attacker already controls a VM. Neither scenario should be expanded beyond the conditions documented by Broadcom.

RootToHack analysis

The most important part of this advisory is not simply the number of vulnerabilities or their CVSS scores.

It is the location of the affected components.

vCenter represents concentrated control over the virtual environment. ESXi represents the boundary between individual workloads and the physical infrastructure underneath them.

A vulnerability in either layer can carry more operational risk than a flaw affecting a single conventional server.

The vCenter flaws are likely to present the more immediate exposure for organisations with reachable management interfaces because they require network access but no authenticated privileges.

The VMXNET3 flaw, meanwhile, is more relevant as a post-compromise escalation route. An attacker would first need administrative control inside a suitable VM, but successfully escaping to the host could dramatically increase the impact of that initial compromise.

Organisations should prioritise the flaws according to those real attack conditions—not simply place all five CVEs into the same patch queue.

For VMware environments exposed to untrusted networks, the vCenter updates should be treated as urgent. For environments running sensitive or multi-tenant workloads, the VM-escape vulnerability deserves similarly close attention because it undermines the isolation boundary those environments depend on.

Broadcom has released the fixes. With no workarounds available, the remaining question is how quickly organisations can safely deploy them before attackers begin examining the patches and developing reliable exploitation methods.