VMware Patches 3 Critical vCenter and ESXi Vulnerabilities — VM Escape and Unauthenticated RCE

On July 29, 2026, Broadcom disclosed 5 vulnerabilities across VMware ESXi, vCenter, Workstation, and Fusion. Three are critical, with CVSS scores ranging from 9.3 to 9.8. Two enable remote code execution on vCenter with zero authentication and zero user interaction. The third is a VM escape through the VMXNET3 paravirtualized network driver — a local admin inside a guest VM can break out and execute code on the ESXi host.

If your vCenter is reachable over the network, it’s vulnerable. If an attacker owns your vCenter, they own your ESXi hosts. If they own your ESXi hosts, they own every virtual machine you run. The attack chain is frictionless and complete.

The Three Critical Flaws

CVE-2026-47876 (CVSS 9.3) is a VM escape vulnerability in the VMXNET3 driver, VMware’s paravirtualized network controller. An attacker with local administrator privileges inside a guest VM can leverage this flaw to execute code on the ESXi host itself. This is the scenario every virtualization admin dreads: a single compromised VM becomes the beachhead for compromising the entire infrastructure. The exploit requires no user interaction inside the target VM and no special network configuration beyond the driver’s normal operation.

CVE-2026-41703 and CVE-2026-59309 / CVE-2026-59310 are remote code execution vulnerabilities targeting vCenter Server. The attack surface is brutally simple: a single crafted network request, without authentication and without any user interaction, is enough to run arbitrary code on the server. These three CVEs target services exposed by default on the vCenter management interface. CVE-2026-41703 serves as the primary entry point; CVE-2026-59309 and CVE-2026-59310 complete the exploitation chain by enabling privilege escalation and persistence respectively.

These vulnerabilities were discovered by Nguyen Hoang Thach of STARLabs SG through the Pwn2Own Vancouver 2026 competition run by the Zero Day Initiative (ZDI). Thach won the contest by demonstrating a full exploitation chain — from a guest VM to complete hypervisor control — proving these flaws are not just individually exploitable but can be chained together for deep compromise.

vCenter Is the Crown Jewel You Forgot to Guard

vCenter Server is often treated as an internal admin tool — an appliance you deploy, expose on the management network, and stop thinking about. That’s a fundamental mistake. vCenter holds full administrative privileges over every ESXi host it manages. It holds the authentication credentials, the VM encryption keys, the SSO configuration, the RBAC permissions, the audit logs, and the security policies for the entire cluster.

An unauthenticated RCE on vCenter means an attacker can, with a single network request:

• Create an administrator account on the vSphere infrastructure without triggering standard login audit trails
• Disable VM encryption and access cleartext data across the cluster
• Exfiltrate snapshots and backups to an external server
• Deploy malicious VMs across every ESXi host in the cluster
• Encrypt datastores for an infrastructure-wide ransomware demand
• Disable monitoring alerts to hide ongoing malicious activity

The ransomware scenario isn’t hypothetical — it’s documented. Ransomware groups targeting VMware ESXi are well-established: LockBit, BlackCat, and Akira have all developed ESXi-specific encryptors. Once vCenter falls, the attacker can orchestrate the encryption of every VM from a single control point, no need to compromise each ESXi host individually. It’s a force multiplier that turns a single network vulnerability into a datacenter-wide incident. The NCSC and CISA have both published joint advisories on ESXi-targeting ransomware, and the attack surface these CVEs expose fits that playbook exactly.

Patch Now — Don’t Wait for Active Exploitation

Broadcom has released patches for all affected versions of vCenter Server, ESXi, Workstation, and Fusion. As of July 29, 2026, no active exploitation has been confirmed in the wild. That’s the good news. The bad news: this situation is fluid.

Multiple signals argue for immediate patching rather than waiting:

• The technical details of these CVEs are publicly documented by the Zero Day Initiative, with enough specificity that a competent reverse engineer can reconstruct a working exploit
• The researcher demonstrated a fully functional exploit chain at Pwn2Own, proving real-world exploitability — not just theoretical
• The CISA is monitoring these vulnerabilities for potential inclusion in the KEV (Known Exploited Vulnerabilities) catalog, which would trigger mandatory patching deadlines for US federal agencies and, by extension, their contractors
• CVE-2026-47876 directly echoes CVE-2025-35079, a near-identical VMXNET3 VM escape patched in July 2025 that saw active exploitation within 72 hours of technical details going public

The July 2025 precedent is instructive. The earlier VM escape was disclosed under comparable conditions — coordinated disclosure, public PoC, available patch — and Shadowserver Foundation honeypots detected the first exploitation attempts three days after publication. Waiting until automated scanners light up your logs is not a defense strategy. It’s a race you’ve already lost.

Prioritize by Attack Surface

Patching should be sequenced by criticality:

1. vCenter Server first. The unauthenticated RCE flaws (CVE-2026-41703, CVE-2026-59309, CVE-2026-59310) are the most direct entry point. If your vCenter is reachable from anything other than a dedicated management network, patch immediately — compromise is possible with a single crafted HTTP request.
2. ESXi second. The VM escape (CVE-2026-47876) requires the attacker to already have local admin inside a guest VM — a higher bar, but not an insurmountable one in multi-tenant environments or after an initial compromise via phishing or a vulnerable web application.
3. Workstation and Fusion last, for developer workstations and lab environments.

The most likely attack chain for CVE-2026-47876 is a two-stage compromise: the attacker first gains admin access inside a VM (through a vulnerable web app, an exposed RDP endpoint, or a successful phishing campaign), then uses the VM escape to pivot to the ESXi host. In a virtualized datacenter, that VM might be running on the same cluster as your production servers. VM-to-VM isolation provides exactly zero protection against a hypervisor escape.

VMware’s VMXNET3 Problem

This patch cycle fits a worrying pattern. In January 2025, Broadcom patched an actively exploited zero-day in ESXi — a trio of CVEs (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226) that allowed an attacker with guest VM admin privileges to escape to the host. In July 2025, CVE-2025-35079 replicated the same scenario through VMXNET3, scoring 9.3 on the CVSS scale. In July 2026, CVE-2026-47876 hits the same component, with the same score.

The VMXNET3 driver sits at a critical boundary between the guest VM and the hypervisor. It manages shared packet queues, with data structures in memory that cross the virtualization boundary on every network I/O operation. Every input validation bug in this driver has VM escape potential, and three incidents in eighteen months on the same component suggests VMXNET3’s attack surface is not under control and deserves a thorough security audit.

For security teams, this pattern justifies going beyond reactive patching:

• Isolate vCenter on a physically separate management network or at minimum a dedicated VLAN with a bastion host and mandatory multi-factor authentication
• Restrict VM snapshots to backup service accounts only, and monitor for snapshots created outside scheduled backup windows
• Monitor vCenter audit logs for anomalous account creation, privilege escalation, role changes, and alert suppression
• Segment VMs by sensitivity tier onto separate ESXi clusters to limit the blast radius of a VM escape
• Disable VMXNET3 on VMs that don’t need paravirtualized network performance and can operate with the standard E1000E driver — fewer VMXNET3 instances mean a smaller attack surface

Verdict

Patch vCenter within 48 hours. The window is too short for a standard change management cycle. If your vCenter is exposed on a non-dedicated network, this is a drop-everything emergency: the unauthenticated RCE flaws require a single request to own your infrastructure, and the technical details are public.

If immediate patching is operationally impossible, apply these stopgap measures without delay: restrict network access to vCenter via a firewall or VPN with strong authentication, disable unused service accounts, and enable full vCenter API audit logging to detect abnormal activity. These measures are not substitutes for the patch — they shrink the attack surface while you schedule it.

The question isn’t whether public exploits will appear. The question is whether you’ll already be patched when they do.

References

• VMware Security Advisory VMSA-2026-0015, Broadcom, July 29, 2026.
• Pwn2Own Vancouver 2026 — VMware Exploit Chain, Trend Micro Zero Day Initiative, July 29, 2026.
• CISA Known Exploited Vulnerabilities Catalog, Cybersecurity and Infrastructure Security Agency.
• CISA/NCSC Joint Advisory — ESXi Ransomware, CISA and NCSC.
• VMware ESXi zero-day exploited by ransomware groups, BleepingComputer, January 2025.
• VMware Patches Critical VMXNET3 VM Escape (CVE-2025-35079), BleepingComputer, July 2025.
• Shadowserver Foundation — Internet Storm Center, Shadowserver Foundation.