Three Critical VMware Flaws: Auth Bypass, Code Execution, and VM Escape (VMSA-2026-0006)

Overview

Advisory: VMSA-2026-0006
Vendor: Broadcom (VMware)
Published: July 29, 2026
Affected Products: VMware vCenter Server, VMware ESX/vSphere ESXi, VMware Cloud Foundation, VMware vSphere Foundation
Exploitation Status: None observed in the wild as of publication, per VMware

VMware disclosed three critical vulnerabilities affecting its virtualization stack. Two live in vCenter's authentication and log-handling layers, while the third is a guest-to-host escape in the VMXNET3 virtual network adapter used by VMware ESX. This post covers all three, with emphasis on how the vCenter pair could realistically be chained and where the ESX escape sits as a separate, independent risk path.

The Three CVEs at a Glance

CVE-2026-59309: vCenter Authentication Bypass

Description: An authentication bypass in the VMware Directory Service (VMDir) component of vCenter. A malicious actor with network access to vCenter can bypass authentication entirely and gain unauthorized access to the system.

Attack Vector: Network, no privileges required, no user interaction required (AV:N/AC:L/PR:N/UI:N).

What this means in practice: VMDir is the identity and directory backbone that vCenter uses for Single Sign-On, holding user accounts, group memberships, and the trust relationships that decide who is allowed to log into vCenter and what they can do once inside. An authentication bypass at this layer means the flaw sits in front of, or undermines, the normal login and identity-verification checks rather than in some peripheral feature. A vulnerability class like this typically arises from a flaw in how a service validates session tokens, certificates, or credential exchange logic, letting a request that should be rejected get treated as authenticated instead. VMware has not published the specific root cause here, so the exact mechanism (whether it is a token validation flaw, a logic error in the SSO handshake, or something else) is not confirmed.

Why it matters: Because vCenter is the central management plane for an entire vSphere environment, an attacker who can reach it over the network and skip authentication has effectively skipped the front door to a system that can control every ESXi host, VM, and storage policy it manages. There is no privilege tier below "unauthenticated network attacker" for this one, which is what pushes the CVSS score to 9.8.

CVE-2026-59310: vCenter Directory Traversal to Code Execution

Description: A directory traversal vulnerability in vCenter's Syslog server. A malicious actor with network access can exploit this to execute arbitrary code.

Attack Vector: Network, no privileges required, no user interaction required (AV:N/AC:L/PR:N/UI:N).

What this means in practice: The Syslog server on vCenter accepts and processes log data, typically writing it to files on disk. A directory traversal flaw means the component does not properly restrict where those file paths can point, so a specially crafted input (using sequences like path-escaping characters) can cause the service to read from or write to locations outside its intended log directory. When a traversal flaw lets an attacker write to an arbitrary location, and that location happens to be somewhere the system will later execute (a startup script, a web-accessible directory, a configuration file that gets parsed), the result is arbitrary code execution rather than just an information leak. VMware's description confirms the outcome, code execution, but has not detailed the exact write target or execution trigger.

Why it matters: Like CVE-2026-59309, this requires nothing more than network reachability to vCenter. On its own it gives an attacker a foothold with code execution on the appliance; paired with an authentication bypass elsewhere in the same system, the practical difference between "needs no credentials" and "needs no credentials and now has code execution" collapses into a single, very short path to full compromise.

CVE-2026-47876: VMXNET3 Guest-to-Host VM Escape

Description: An out-of-bounds write vulnerability in the VMXNET3 virtual network adapter on VMware ESX. VMware explicitly characterizes this as a virtual machine escape.

Attack Vector: Local to the guest VM, requiring the attacker to already hold administrative privileges inside a VM that uses the VMXNET3 adapter. Non-VMXNET3 adapters are not affected.

What this means in practice: VMXNET3 is VMware's paravirtualized network adapter, and its device emulation logic runs partly on the ESX host to service network requests coming from inside the guest VM. An out-of-bounds write means the emulation code writes data past the boundary of a buffer it should be confined to, typically because a length or offset value supplied by the guest is not validated before being used. Because this emulation code executes with host-level privilege on behalf of the guest, corrupting memory here can let an attacker who controls what the guest sends redirect execution on the host itself, which is precisely what "VM escape" describes: code that was supposed to be confined to a guest VM instead runs in the context of the hypervisor host.

Why it matters: This is a fundamentally different threat model than the vCenter pair above. It does not require network access to a management system; it requires an attacker who has already achieved local administrative control inside a guest VM, through any means (a separate application compromise, stolen credentials, a malicious insider). From that starting point, this flaw is the difference between "I control one VM" and "I control the physical host and everything else running on it." In multi-tenant or shared-hosting environments, that distinction is the entire security model of virtualization breaking down.

Exploit Maturity Assessment

Exploit Status: No known exploit in the wild for any of the three CVEs.

Exploit Availability: Not public.

Source of Exploit: Not disclosed by VMware.

Exploit Reliability: Unknown. VMware has not published technical write-ups for any of these three CVEs beyond the advisory descriptions above.

Public PoC: No. No PoC exists at time of writing for any of the three CVEs.

Understanding the Chain: Why the vCenter Pair Matters Together

The two vCenter flaws are individually severe, but their combination is what should concern defenders most:

• Step 1, initial access: CVE-2026-59309 lets a network-positioned attacker bypass vCenter authentication outright. No credentials, no user interaction. This alone hands an attacker a foothold on the management plane for an entire virtual infrastructure.
• Step 2, code execution: Once inside, or independently, since CVE-2026-59310 is also described as exploitable by a network-positioned actor on its own, the directory traversal flaw in the Syslog server allows arbitrary code execution.
• Combined impact: An attacker who does not need valid credentials to reach vCenter, and can then execute arbitrary code on that same system, is looking at full compromise of the appliance that manages ESXi hosts, VM inventories, storage policies, and often SSO domains for an entire vSphere environment. vCenter compromise is traditionally one of the highest-value targets in enterprise virtualization because of the blast radius: a single vCenter instance can control hundreds of hosts and thousands of VMs.

Whether these two CVEs require each other to be useful is worth being precise about: each is independently critical and independently network-exploitable per the advisory's own attack vector description (AV:N/PR:N/UI:N for both). CVE-2026-59310 does not appear to depend on CVE-2026-59309 being exploited first. That said, the fact both were fixed in identical patch builds suggests they were discovered during the same assessment of vCenter's network-facing services, and a real-world attacker doing reconnaissance against an exposed vCenter would likely test both.

The VMXNET3 escape (CVE-2026-47876) sits on a separate attack path and should not be conflated with the vCenter chain. It requires the attacker to already have administrative privileges inside a guest VM, a materially different starting position than "network access to vCenter." Where it becomes relevant to defenders thinking about layered risk: an attacker who compromises a VM through some other means and escalates to local admin inside that guest now has a second, independent path to the hypervisor layer, distinct from and not reliant on the vCenter flaws. Organizations running mixed workloads with VMXNET3 adapters should treat this as its own priority, not something addressed simply by patching vCenter.

Example Attack Chain (vCenter path, illustrative, not confirmed in the wild)

Network access to vCenter management interface → authentication bypass via CVE-2026-59309 → arbitrary code execution via directory traversal in Syslog server (CVE-2026-59310) → control of the vCenter appliance → ability to manipulate connected ESXi hosts, VM configurations, and potentially credentials stored or brokered through vCenter → downstream impact across the managed virtual infrastructure.

MITRE ATT&CK Mapping

VMware has not published ATT&CK mappings for this advisory. The table below reflects a reasonable mapping based on the vulnerability mechanics described, not a vendor or MITRE-confirmed technique attribution for this specific advisory.

Patch and Mitigation

Patch Available: Yes, for all three CVEs. No workaround exists for any of them; patching is the only remediation path.

Mitigation Steps (given no workaround exists):

• Prioritize patching vCenter immediately given the unauthenticated, network-exploitable nature of CVE-2026-59309 and CVE-2026-59310.
• Restrict network access to vCenter management interfaces to trusted administrative networks only, as a compensating control while patching is scheduled.
• Review which guest VMs use the VMXNET3 adapter and prioritize ESX host patching for hosts running VMs with untrusted or lower-trust administrative access.

Indicators of Compromise

IOCs Available: No. VMware has not published IOCs, and there is no confirmed exploitation activity to derive them from. Any IOC list circulating for this advisory should be treated with skepticism until VMware or a credible incident response source publishes one.

Active Exploitation and Threat Actors

Exploitation Observed in the Wild: No, per VMware's advisory as of July 29, 2026.

No threat actor attribution, campaign details, or targeting information is available for any of these three CVEs at time of writing.

Vulnerability Timeline

Risk Assessment

Impact: Severe for the vCenter pair given the management-plane blast radius; severe but narrower for the VMXNET3 escape given its guest-admin prerequisite.

Likelihood: Currently low in the absence of public PoC or observed exploitation, but the unauthenticated network attack vector on the vCenter flaws makes this a high-value target for reverse engineering the patch diffs, which historically shortens time-to-exploit for vCenter authentication issues.

Overall Risk Level: Critical, driven primarily by the unauthenticated vCenter authentication bypass and code execution pair.

Remediation Recommendations

Immediate: Patch vCenter to 9.1.0.0300, 9.0.2.0100, or 8.0 U3k depending on your track. Patch ESX hosts running VMXNET3 adapters to the corresponding builds listed above.

Long-term: Segment vCenter management interfaces away from general network access. Establish a faster patch cadence for vCenter given its recurring status as a high-value, network-facing target for authentication and code execution flaws. Include VM escape scenarios in tabletop exercises given the demonstrated feasibility of the VMXNET3 issue.