VMware patches a VM escape and two critical vCenter flaws

Broadcom published VMSA-2026-0006 on 29 July 2026, covering five vulnerabilities in VMware ESX, vCenter, Workstation and Fusion. Three are critical: an authentication bypass in VMware Directory Service, code execution through a vCenter Syslog server path-traversal issue, and an out-of-bounds write in the VMXNET3 virtual network adapter that can let code cross from a virtual machine to its host.

The advisory’s highest CVSS score is 9.8. The vendor has not reported exploitation in the wild and says the flaws were privately reported. There is no workaround for the three critical issues. Organizations therefore need the appropriate patches rather than a firewall rule or a single configuration change.

Five distinct flaws in one advisory

Broadcom’s official VMSA-2026-0006 advisory was published and updated on 29 July. Its matrix is:

CVE	Component	Score	Condition and consequence
CVE-2026-59309	vCenter / VMware Directory Service	9.8	a network-reachable attacker may bypass authentication
CVE-2026-59310	vCenter Syslog server	9.8	network access may lead through directory traversal to arbitrary code execution
CVE-2026-47876	ESX / VMXNET3	9.3	a VM administrator can execute code on the host
CVE-2026-41703	ESX, Workstation, Fusion	up to 7.6	VM deployment privilege may lead to memory disclosure or host-process DoS
CVE-2026-41709	ESX	2.7	a malicious administrator can perform selected actions without logging

These are not variants of one defect. They affect separate boundaries: vCenter identity, path processing, hypervisor isolation, memory safety and audit completeness. A shared advisory simplifies publication, but defenders should maintain five separate exposure hypotheses.

CVE-2026-59309: no login does not mean no access

VMware Directory Service is part of the vCenter identity plane. Broadcom describes CVE-2026-59309 as an authentication bypass that a malicious actor with network access to vCenter may exploit for unauthorized access. The CVSS vector has AV:N, PR:N and UI:N: it does not require an existing account or user interaction.

Practical priority therefore depends on reachability. vCenter should not be exposed to the public internet, but the flaw remains critical internally. A compromised administrator workstation, VPN host, management server or malicious system with a route to vCenter can become the starting point.

After patching, review login, token, role and configuration-change history. An authentication bypass may not look like a password attack. Detection should ask about sessions without the expected authentication chain, new accounts or roles, unusual API calls and access from systems that did not previously administer vCenter.

CVE-2026-59310: path traversal with an RCE consequence

The second vCenter flaw is in its Syslog server. Directory traversal occurs when input escapes an intended directory. The term alone does not determine impact: one case may expose a file, another may permit a write, and a specific context can place content where it will be executed.

Broadcom rates this scenario as arbitrary code execution by a network-reachable attacker. The public notice does not include an exploit payload or detailed chain. Defenders do not need one to prioritize: CVSS 9.8, no authentication and no workaround justify an emergency maintenance window.

Preserve Syslog, vCenter and operating-system telemetry before updating. Hunt for unusual path names, file changes, child processes, new outbound connections and service manipulation. Those are safe hypotheses derived from the vulnerability class, not vendor-issued indicators of compromise.

CVE-2026-47876: VM escape through VMXNET3

The most intuitive scenario concerns the VMXNET3 virtual network adapter. Broadcom confirms an out-of-bounds write in ESX. An attacker needs local administrative privileges inside a VM that uses VMXNET3 and may then execute code on the host.

This is not an unauthenticated remote attack against every ESXi server. It requires a compromised or malicious VM and administrator rights inside its guest OS. In hosting, VDI, lab, private-cloud or multi-team environments where tenants deploy their own images, however, that precondition can be realistic. Tenant-to-hypervisor isolation is exactly the control the organization cannot afford to lose.

The vendor states that non-VMXNET3 virtual adapters are not affected by this specific issue. That is not a recommendation to replace adapters at scale instead of patching. Changing adapter types can affect drivers, performance and availability, and Broadcom does not publish that action as a workaround.

The other two flaws still matter

CVE-2026-41703 is an out-of-bounds read. On ESX, a user with VM deployment privileges may disclose information or, more likely according to the vendor, cause a denial of service in the host process. On Workstation and Fusion, impact is limited to information disclosure. Different scores across products show how one code defect can have different consequences in different architectures.

CVE-2026-41709 concerns insufficient logging. Its severity is low, but it creates an investigative problem when combined with another access path. An administrator may perform selected actions without an audit record. Post-patch analysis therefore needs both state verification and an explicit record of evidence limitations during the exposure window.

Fixed versions and rollout order

The vendor matrix includes:

• vCenter 9.1: the current package containing the fixes is 9.1.0.0300;
• vCenter 9.0: 9.0.2.0100;
• vCenter 8.0: 8.0 U3k;
• ESX 9.1 for CVE-2026-47876: ESXi-9.1.0.0200-25557999;
• ESX 9.0: ESXi-9.0.2.0100-25595025;
• ESX 8.0: ESXi80U3k-25595708;
• affected Workstation and Fusion installations: 26H1 for CVE-2026-41703;
• VMware Cloud Foundation 5.x and Telco products require the paths or asynchronous patches listed in the response matrix.

Do not paste a number from this article into automation without checking product, edition and the current matrix. VMSA notices may change. Record the advisory ID, verification time and exact running build for every component.

A safe emergency-update plan

Updating vCenter and ESXi hosts requires an order, capacity plan and verified backups. A minimum workflow is:

1. inventory every vCenter, host, cluster, Workstation and Fusion installation in scope;
2. compare live builds with the current VMSA matrix;
3. protect a vCenter configuration backup and verify restoration access;
4. preserve logs and lists of accounts, roles, extensions and active sessions;
5. restrict management access to dedicated workstations and segments;
6. update vCenter in line with compatibility requirements, then cycle hosts through maintenance mode;
7. verify HA, vMotion, storage, networking, backup and monitoring;
8. read the build from every node rather than trusting a manager task status.

A cluster without spare capacity may be unable to evacuate VMs during maintenance mode. That is not a reason to abandon the patch; it is evidence that continuity planning and capacity reserve require an owner decision.

What to monitor during the exposure window

Public sources do not provide official IOCs and do not report active exploitation. Behavioural review can still include:

• new vCenter sessions, accounts, roles and tokens;
• API access from unusual management addresses;
• changes to hosts, datastores, networks, snapshots or logging settings;
• Syslog anomalies and unexpected path operations;
• processes or outbound connections absent from baseline;
• VM process failures after unusual privileged guest activity;
• differences between current configuration and the last trusted copy.

If evidence suggests compromise, do not reduce the task to patching. Isolate the management plane, preserve evidence, withdraw tokens and certificates, validate host integrity and consider rebuilding management components.

Architecture lesson: management is a separate security zone

vCenter is worth more than one VM to an attacker. It controls infrastructure, virtual networks, snapshots and administrative access. It belongs in a separate segment reachable through privileged workstations and phishing-resistant MFA, with identities separate from everyday email accounts.

A VM escape also demonstrates that a malicious virtual machine is a potential adversary to its host. Images, tenants and deployment roles are security boundaries. An IT security audit can validate actual vCenter reachability, segmentation, backups, service accounts and update resilience.

Use the advisory in technical-team cybersecurity training. Administrators should understand how exploit preconditions change practical risk without treating “requires VM access” as permission to delay the update.

Sources and inference limits

The primary source is Broadcom VMSA-2026-0006, dated 29 July, together with the VMware-maintained supplemental repository. SecurityWeek also reported the release that day.

The vendor does not report exploitation and provides no workaround. Detection hypotheses, operational ordering and segmentation advice are BreachRoad analysis. We omit payloads because today’s defensive priorities are the correct version, management-plane reachability and evidence that every node actually received the update.

Deployment evidence, not a completed task

A large cluster can report success even when one host was offline, disconnected or later restored from an older image. Export the exact version and build of every affected vCenter, ESXi host and dependent product after maintenance. Compare each value with the vendor’s fixed-build matrix and assign every exception an owner and deadline.

A useful evidence pack contains:

• component version and build;
• installation and restart time;
• cluster-health result;
• hosts absent during rollout;
• configuration-backup and recovery confirmation;
• management-interface reachability from unprivileged segments;
• administrative account, token and configuration-change review for the exposure window.

Do not rely on a scanner that sees only an HTTPS banner. Sound validation combines platform inventory, authenticated scanning and manual version checks. Store the result in the vulnerability-management process with any formal risk exception.

Where downtime is constrained, compensating controls reduce exposure but do not replace a patch. Remove public vCenter access, require a bastion, disable unused identities, restrict VM import and creation, and increase monitoring until maintenance. Prioritise environments reachable from less-trusted networks and clusters that host tenants with different trust levels.

The recovery plan should account for backup, NSX, automation and vendor-tool dependencies before management services restart. The Breachroad Academy develops the underlying trust-boundary knowledge, while our Active Directory security guide explains why virtualisation administrators should not use ordinary office identities.

The decisive metric after 29 July is not the number of closed tickets. It is the percentage of inventory with a verified fixed build and the absence of vCenter reachability from networks that do not need it.