Two CVSS 9.8 vCenter Flaws: VMSA-2026-0006 Patch Priority

VMSA-2026-0006 patches two CVSS 9.8 vCenter Server vulnerabilities that let an unauthenticated network attacker bypass authentication or execute arbitrary code through a directory traversal flaw, alongside a CVSS 9.3 VMXNET3 bug that enables virtual machine escape to the ESX host. Broadcom issued the advisory on July 29, 2026, covering vCenter, ESX, Workstation, Fusion, Cloud Foundation, and VMware Telco Cloud, and any team operating VMware-based private or hybrid cloud should place vCenter patching at the top of its remediation queue.

The exposure spans the full virtualization control plane. CVE-2026-59309 targets the VMware Directory Service inside vCenter Server and lets an attacker with only network reachability fully bypass authentication, granting unauthenticated control of the management plane over every managed workload. CVE-2026-59310 abuses path traversal in the vCenter Syslog server to execute arbitrary code remotely, converting a logging subsystem into a beachhead for lateral movement across the data center. Both flaws carry a maximum CVSSv3 score of 9.8 because they require no credentials and no user interaction.

The Two CVSS 9.8 vCenter Flaws

An authentication-bypass flaw in a directory service is the worst-case scenario for a virtualization platform, because that service underpins identity for vCenter Single Sign-On and every connected solution. Once authentication is bypassed, the attacker inherits administrative authority over clusters, hosts, storage, and networks, and can snapshot, destroy, or exfiltrate any virtual machine in the inventory. The directory-traversal flaw in the Syslog server compounds the risk: environments that segment the management UI behind a jump host often leave the Syslog collector reachable on a separate port, so the two attack paths rarely share the same network chokepoint. Teams that map defenses across a layered security stack should verify that neither vCenter service is exposed to broad internal subnets.

No configuration workaround exists for either CVSS 9.8 issue. The advisory states that there is no mitigation short of applying the patched vCenter builds, which means network isolation is the only interim lever available while patches are staged. For organizations running vCenter behind a load balancer or reverse proxy, confirm that the Syslog listener is not published alongside the management UI, because a single exposed port is enough for an attacker to pivot from network access to arbitrary code execution. Privileged access management tooling that brokers vCenter sessions should also be reviewed, since a bypass of the directory service renders those brokers’ authentication checks moot.

VMXNET3 Escape to the ESX Host

CVE-2026-47876 affects the VMXNET3 virtual network adapter and is rated CVSS 9.3. A malicious actor with local administrative privileges inside a guest VM that uses the VMXNET3 driver can trigger an out-of-bounds write that executes code directly on the ESX host, breaking the hypervisor boundary that isolates tenants. In multi-tenant private cloud and managed-hosting designs built on vSphere, a single compromised guest becomes a stepping stone to full host takeover, at which point every co-located VM, its memory, and its credentials are within reach.

This is a virtual machine escape, the same class of risk that kernel privilege-escalation flaws such as Bad Epoll pose to Linux hosts, and it demands patch-now urgency rather than a scheduled maintenance window. Two companion ESX bugs round out the advisory: CVE-2026-41703 is an out-of-bounds read rated 7.6 that can cause information disclosure or denial of service of the host process, and CVE-2026-41709 is a low-severity insufficient-logging issue that lets an administrator perform certain operations without leaving an audit trail. The logging gap matters operationally, because an attacker who reaches the ESX host can cover tracks that your incident responders will need later.

Patch Matrix and Fixed Builds

Broadcom published fixed versions across the supported vCenter, ESX, Workstation, Fusion, and Cloud Foundation lines, and the Telco Cloud knowledge base lists the specific builds for telecommunications deployments. The table below summarizes the target builds and the CVEs each addresses, drawn from the advisory response matrix.

Remediation Checklist for Cloud Teams

Because the two vCenter flaws require no credentials and the VMXNET3 escape needs only a foothold inside one guest, containment before patching matters as much as the patch itself. Treat any vCenter instance reachable from a general-purpose network as presumed-compromised until it is patched and verified, and review audit logs for the full reporting window.

1. Inventory every vCenter and ESX instance, recording exact build numbers against the fixed versions in the matrix above.
2. Isolate vCenter management and Syslog interfaces behind jump hosts or zero-trust access proxies until patches land; block the Syslog port from general subnets immediately.
3. Patch vCenter first — the two CVSS 9.8 flaws need no credentials and have no configuration workaround.
4. Patch ESX hosts next, prioritizing any cluster running multi-tenant or untrusted workloads with VMXNET3 adapters.
5. Upgrade Workstation and Fusion from 25H2 to 26H1 on developer and lab machines.
6. Hunt for prior exploitation: review vCenter login events, Syslog service activity, and ESX host process lineage for anomalies since exposure began.
7. Re-enable and verify administrative logging after applying the CVE-2026-41709 fix, and confirm that audit trails now capture the previously unlogged operations.

The combined blast radius of this advisory is unusual: two flaws that hand over the management plane without credentials, one that breaks the guest-to-host boundary, and a logging gap that obscures the trail. Sequencing matters. Lock down network paths to vCenter and the Syslog collector today, stage the vCenter build overnight, and roll ESX fixes through the multi-tenant clusters before any lower-priority cluster. Document the before-and-after build numbers so the verification step is auditable, not anecdotal.

Sources

• Broadcom — VMware Telco Cloud response to VMSA-2026-0006 (KB449886)
• Cyber Security News — Critical VMware Flaws Allow Attackers to Bypass Authentication and Gain Access to the System