Broadcom released five patches on July 29, 2026 for vulnerabilities in VMware vCenter, ESXi, Workstation, and Fusion. Three of these flaws are rated critical, with CVSS scores up to 9.8, and allow an attacker to bypass authentication, execute arbitrary code on vCenter, or force a virtual machine escape to the ESXi host. The same fix introduces an unintended operational restriction: the inability to upgrade to VMware Cloud Foundation and vSphere Foundation 9.0 and 9.1 from earlier versions, a side effect that complicates administrators' roadmaps.
- Three critical vulnerabilities with CVSS 9.8, 9.8, and 9.3 affect vCenter and ESXi: authentication bypass, RCE, and VM escape
- No known exploitation at this time, but Broadcom does not indicate alternative workarounds to patching
- CVE-2026-41709 shows a CVSS score discrepancy between sources: 2.7 per HWUpgrade, 7.6 per SecurityAffairs
- The patch introduces a "back in time" restriction that blocks upgrades to VCF/vSphere Foundation 9.0 and 9.1 from prior versions
The Offensive Core: Authentication Bypass and RCE on vCenter
Two of the three critical flaws reside in vCenter, the centralized management console for virtualized infrastructure. CVE-2026-59309 is an authentication bypass in the VMware Directory Service with a CVSS of 9.8: an attacker with network access gains unauthorized system access. According to the Broadcom advisory cited by SecurityAffairs, "a malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system".
CVE-2026-59310, also rated CVSS 9.8, exploits a directory traversal in the vCenter Syslog Server to execute arbitrary code. Again, the attacker requires only network access, with no prior authentication. The Broadcom advisory, reported by SecurityAffairs, states the vector allows an attacker to "execute arbitrary code".
The combination of these two flaws exposes the infrastructure orchestration layer: whoever controls vCenter controls the cluster. The attack surface is network-exposed, with no privilege prerequisites or user interaction required.
VM Escape on ESXi: From Virtual Machine to Host
The third critical vulnerability, CVE-2026-47876 with CVSS 9.3, affects the VMXNET3 virtual network adapter on ESXi. It is an out-of-bounds write that allows an attacker with local administrative privileges on a virtual machine to execute code on the physical host. The Broadcom advisory, cited by SecurityAffairs, specifies that "a malicious actor with local administrative privileges on a virtual machine with VMXNET3 virtual network adapter may exploit this issue to execute code on the host".
The mechanism differs from the two vCenter flaws: here the attacker must already control a VM, but the result is hypervisor control. The CVSS 9.3 score reflects the severity of impact combined with the need for privileged local access. For multi-tenant environments or those with third-party managed VMs, the escalation chain is concrete.
The patched versions are, per HWUpgrade: vCenter 9.1.0.0300, 9.0.2.0100, and 8.0 Update 3k; ESXi 9.1.0.0200, 9.0.2.0100, and 8.0 Update 3k.
The Other Two Flaws and the Discrepancy on CVE-2026-41709
Beyond the three critical issues, Broadcom fixed CVE-2026-41703 and CVE-2026-41709. The first has differentiated impact by product: on ESXi it carries CVSS 7.6 for information disclosure and denial-of-service conditions, while on Workstation and Fusion it drops to CVSS 2.7 for limited disclosure.
CVE-2026-41709, related to creating virtual machines from the CLI without visibility in the GUI or logs, presents a discrepancy between sources. HWUpgrade reports CVSS 2.7, while SecurityAffairs indicates 7.6. The dossier does not resolve the conflict: the exact nature of the risk associated with this vulnerability remains to be verified.
Broadcom confirms through multiple sources — HWUpgrade, Field Effect, SecurityWeek, SecurityAffairs — that no in-the-wild exploitation has been observed at the time of publication.
The Operational Dilemma: Security or Roadmap?
The patches resolve the flaws but introduce a significant operational restriction. According to Broadcom, cited by HWUpgrade, a "back in time" restriction occurs when a patch updates a product to a branch that holds a newer build number than the desired upgrade. The practical result: it is currently impossible to upgrade to VMware Cloud Foundation and vSphere Foundation 9.0 and 9.1 from earlier versions.
This side effect is not a security vulnerability, but an infrastructure blocking condition. For administrators who had planned upgrades to the 9.x release, the choice narrows to two suboptimal options: remain on prior releases without the latest patch protections, or apply the patch and defer migration.
"A malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system" — Broadcom advisory, reported by SecurityAffairs
What to Do Now
Administrators must apply the patches in the versions specified by Broadcom: vCenter 9.1.0.0300, 9.0.2.0100, or 8.0 Update 3k; ESXi 9.1.0.0200, 9.0.2.0100, or 8.0 Update 3k. No documented workarounds exist for any of the five vulnerabilities, so patching is the only available control.
Upgrade planning for VCF 9.0 or 9.1 should be verified: if the environment is a migration candidate, the "back in time" restriction forces a revision of the timeline. Operators must check the current build level against the target release.
For CVE-2026-47876, the exposed surface of VMs with the VMXNET3 adapter and the administrative access profile on those machines should be assessed. No network workaround or microsegmentation guidance is documented.
On CVE-2026-41709, the CVSS discrepancy between sources suggests waiting for official clarification before definitively classifying its risk.
Analysis: The Forced-Patching Trap
The Broadcom-VMware case illustrates a structural tension in enterprise software: the speed of security remediation can conflict with product roadmap predictability. When a patch modifies the build number in a way that invalidates future upgrades, patching is no longer an isolated technical choice but an architectural decision. Administrators find themselves managing a trade-off the vendor did not resolve in advance.
The absence of workarounds for all five vulnerabilities amplifies the pressure: temporary mitigation with compensating controls is not possible. The only operational lever is the timing of application, which however impacts the availability of the upgrade path. For regulated infrastructures or those with constrained maintenance windows, the combination of high severity and operational rigidity constitutes a non-trivial project constraint.
Sources
- https://edge9.hwupgrade.it/news/security/broadcom-rilascia-patch-per-cinque-vulnerabilita-in-prodotti-vmware-di-cui-tre-definite-critiche_157153.html
- https://fieldeffect.com/blog/broadcom-patches-critical-vcenter-vulnerabilities
- https://www.securityweek.com/critical-vm-escape-vulnerability-patched-in-vmware-esxi/
- https://securityaffairs.com/196231/security/broadcom-patches-critical-vmware-esxi-vulnerability-enabling-host-code-execution.html
- https://resecurity.com/
Information has been verified against cited sources and is current as of publication.