// 1 CRITICAL · 4 ZERO-DAY · 7 CVE · 6 EXPLOIT IN THE LAST 24H
Three critical vulnerabilities hit vCenter and ESXi. Two allow credential-less access; one enables escape from a virtual machine to the host. No workarounds exist for the two most severe vCenter flaws; immediate patching is the only documented mitigation.

Broadcom released security update VMSA-2026-0006 on July 29, 2026, addressing five vulnerabilities across the VMware portfolio, three of them rated critical. Two affect vCenter and allow, respectively, authentication bypass and remote code execution by an actor with mere network access; the third enables escape from a virtual machine to the ESXi host via the VMXNET3 paravirtualized network adapter. No workarounds exist for the two most severe vCenter flaws: the only documented mitigation is immediate patching.

Key Takeaways
  • CVE-2026-59309 and CVE-2026-59310 hit vCenter with CVSS 9.8: the first allows authentication bypass, the second arbitrary code execution via directory traversal in the Syslog server.
  • CVE-2026-47876, CVSS 9.3, is an out-of-bounds write in the VMXNET3 adapter that lets a local VM administrator execute code on the ESXi host.
  • Broadcom found no evidence of in-the-wild exploitation for any of the five vulnerabilities.
  • Patches cover specific versions of vCenter, ESXi, Workstation, and Fusion; for the two critical vCenter flaws, no alternative countermeasures to patching exist.

The Double Assault on vCenter: Authentication Nullified and Remote Code

The pair of vulnerabilities CVE-2026-59309 and CVE-2026-59310 exposes VMware's centralized management plane to maximum-severity risks. The first, discovered by Atredis Partners researchers Phil Brass and Matt South, affects the vCenter VMware Directory Service: an actor with network access to the system can completely bypass the authentication mechanism without valid credentials. The second flaw, also within the vCenter perimeter, resides in the Syslog server and exploits a directory traversal vulnerability to allow arbitrary code execution.

Both flaws carry a CVSS 9.8 score on the v3 scale, the highest in this advisory. Their combination is particularly insidious: the authentication bypass opens the door to the administration panel, while the directory traversal in the Syslog server provides a vector for payload execution on the underlying infrastructure. The common requirement is reduced to the bare minimum: network access to vCenter, with no prior privileges or user interaction needed.

"A malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system" — Broadcom, advisory VMSA-2026-0006 on CVE-2026-59309

VMXNET3 Back in the Crosshairs: Escape from VM to ESXi Host

The third critical vulnerability, CVE-2026-47876, represents a different but equally grave threat to the virtualization architecture. Discovered by Nguyen Hoang Thach of STARLabs SG in the Pwn2Own context, mediated by Zero Day Initiative, it is an out-of-bounds write in the implementation of the VMXNET3 paravirtualized network adapter. The flaw allows an actor who already holds administrative privileges inside a virtual machine to execute code on the ESXi host hosting it.

The CVSS 9.3 score reflects the severity of the compromise: the isolation between guest and host, a fundamental principle of virtualization, breaks down. This scenario is especially relevant for multi-tenant environments and cloud providers that rely on the VM/hypervisor boundary for workload separation. Broadcom's advisory specifies that the flaw affects only VMs configured with the VMXNET3 adapter; other network controllers are not affected.

What to Do Now

  • Apply the vCenter patches immediately to versions 9.1.0.0300, 9.0.2.0100, or 8.0 U3k, depending on the version in use; no workarounds exist for CVE-2026-59309 and CVE-2026-59310.
  • Update ESXi hosts to builds 9.1.0.0200-25557999, 9.0.2.0100-25595025, or 8.0 U3k-25595708 to close the VMXNET3 escape path.
  • Verify that virtual machines run the correct network adapter: only VMXNET3 is affected by CVE-2026-47876, but configuration verification is necessary to prioritize remediation.
  • Reduce the vCenter attack surface by applying network segmentation that restricts accessibility to authorized management systems only, given that both critical flaws require only IP connectivity.

The Other Two Flaws and Researcher Acknowledgments

Beyond the three critical issues, advisory VMSA-2026-0006 addresses CVE-2026-41703, an out-of-bounds read in ESX/Workstation/Fusion with impact on information disclosure or denial of service, rated 7.6 for ESX and 2.7 for Workstation/Fusion. The fifth flaw, CVE-2026-41709, discovered by Ian Barton of CrowdStrike, is a logging deficiency in ESX with a score of 2.7 that allows a malicious administrator to perform untracked operations.

Discovery credits reflect the maturity of Broadcom's bug bounty and responsible disclosure program: Atredis Partners for the vCenter flaws, STARLabs SG for the VMXNET3 escape, Maxim Suhanov for CVE-2026-41703, and CrowdStrike for the logging deficiency.

Why the Network Perimeter Is No Longer Enough

The technical reading of this advisory goes beyond a mere list of CVEs. The two vCenter flaws demonstrate that the virtualization management plane remains a high-intensity attack surface: the ability to bypass authentication with mere network presence dismantles the assumption that Layer 3 isolation is sufficient to protect administrative consoles. In environments where vCenter is reachable from potentially compromised internal segments, the flaw amounts to a master key.

Conversely, CVE-2026-47876 confirms that paravirtualized network hardware emulation remains a persistent battleground. VMXNET3 has been the focus of previous virtualization escape research; its return as a critical vector suggests that the complexity of paravirtualized drivers continues to outpace the defensive capabilities offered by traditional security audits. For organizations that rely on virtualization to segregate sensitive workloads, the VM/host boundary can no longer be considered impenetrable by default.

Sources

Information verified against cited sources and current as of publication.

Sources


Sources and references
  1. thehackernews.com
  2. securityweek.com
  3. cyberpress.org
  4. securityaffairs.com
  5. cybersecuritynews.com
  6. gbhackers.com
  7. support.broadcom.com
  8. resecurity.com