2026-07-30 · view entry permalink →
VMSA-2026-0006 — VMware vCenter: unauthenticated Directory Service auth bypass and Syslog traversal RCE (both CVSS 9.8), plus a VMXNET3 guest-to-host escape
Broadcom published VMSA-2026-0006 on 2026-07-29, covering five vulnerabilities across VMware ESX, vCenter, Workstation and Fusion, and stating that they "were privately reported to Broadcom" with updates available to remediate them (Broadcom, 2026-07-29). Three national CERTs picked it up immediately: NCSC-CH on 2026-07-29 (NCSC Switzerland, 2026-07-29), NCSC-NL on 2026-07-29 (NCSC-NL, 2026-07-29), and BSI CERT-Bund, whose advisory is dated 2026-07-28 with a 2026-07-29 revision (BSI CERT-Bund, 2026-07-29).
Two of the five sit on vCenter and need no credentials. CVE-2026-59309 (CVSS 9.8) is an authentication bypass in the VMware Directory Service, and Broadcom's own attack-vector text is unambiguous about the prerequisite: "a malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system" (Broadcom, 2026-07-29). CVE-2026-59310, also CVSS 9.8, is a directory-traversal flaw in vCenter's Syslog server that reaches arbitrary code execution through manipulated file and directory paths (Broadcom, 2026-07-29). vCenter is the control plane for an entire virtual estate: an unauthenticated path into it is a path to every workload it manages, which is why an anonymous network-reachable bypass warrants out-of-cycle handling even with no exploitation reported.
The third flaw crosses the isolation boundary in the other direction. CVE-2026-47876 (CVSS 9.3) is an out-of-bounds write in the VMXNET3 virtual network adapter, and Broadcom scopes it precisely: "a malicious actor with local administrative privileges on a virtual machine with VMXNET3 virtual network adapter may exploit this issue to execute code on the host. Non VMXNET3 virtual adapters are not affected by this issue" (Broadcom, 2026-07-29). That precondition is the useful part of the triage: exposure is determined by adapter configuration rather than by ESX version alone, so the inventory question is which guests run VMXNET3 and how much you trust whoever administers them.
Two lower-severity issues complete the advisory. CVE-2026-41703 is an out-of-bounds read that Broadcom scores differently by product — 7.6 on ESX, where it says a denial of service of the host process is the more likely outcome than information disclosure, against 2.7 on Workstation and Fusion, where it restricts the impact to information disclosure (Broadcom, 2026-07-29). CVE-2026-41709 is insufficient logging on ESX that allows an administrator to act without the action being recorded (Broadcom, 2026-07-29) — minor as a vulnerability, but worth noting for anyone who treats ESX audit logs as a complete record during an investigation.
Two product families beyond the obvious ones are in scope and are easy to miss on a first read of the advisory: Broadcom lists VMware Telco Cloud Platform and VMware Telco Cloud Infrastructure as impacted, with their own knowledge-base fix path rather than the vCenter and ESXi build numbers below (Broadcom, 2026-07-29). Any telco operator running those stacks needs to follow that path rather than assuming the vSphere builds cover them.
Fixed builds differ per flaw and per track. vCenter takes 9.1.0.0300, 9.0.2.0100 or 8.0 U3k, with Cloud Foundation 5.x served by an async patch to 8.0 U3k; the VMXNET3 escape is fixed in ESXi-9.1.0.0200, ESXi-9.0.2.0100 and ESXi80U3k (Broadcom, 2026-07-29). Broadcom records no workaround for any of the five, which removes the usual option of mitigating while the maintenance window is arranged.
Nothing here is reported exploited. Broadcom states the vulnerabilities "were privately reported to Broadcom" and credits Atredis Partners, Nguyen Hoang Thach of STARLabs SG working with Pwn2Own held by the Zero Day Initiative, an independent researcher, and CrowdStrike (Broadcom, 2026-07-29), and none of the three national CERTs reports in-the-wild activity. What earns this out-of-cycle attention is the reachability profile rather than an exploitation signal: two anonymous network paths into a virtualization control plane, with no interim control available.
Detection on the vCenter side means watching the two named services rather than the appliance generally: authentication events from the Directory Service, where a successful bind that no operator session accounts for is the signal, and Syslog-server request logging, where path-traversal sequences in a requested file or directory path have no legitimate counterpart. For the guest-to-host escape the telemetry is host-side — hypervisor crash and process-fault records on ESX hosts running VMXNET3 guests, since a failed escape attempt is far more likely to surface as an anomalous fault than as a clean compromise. On hardening, NCSC-NL is the source that spells out the architectural control: access to ESX and vCenter should be made available only from a separated management environment and not reachable directly from the internet or external networks (NCSC-NL, 2026-07-29). Broadcom's own advisory offers no hardening section and records "Workarounds: None" against every one of the five.
A malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system.
A malicious actor with local administrative privileges on a virtual machine with VMXNET3 virtual network adapter may exploit this issue to execute code on the host. Non VMXNET3 virtual adapters are not affected by this issue.
Multiple vulnerabilities in VMware ESX, vCenter, Workstation, and Fusion were privately reported to Broadcom. Updates are available to remediate these vulnerabilities in affected Broadcom products.