Broadcom fixes authentication bypass and code execution in VMware vCenter

Broadcom published the security advisory VMSA-2026-0006 on 29 July 2026. The advisory fixes five vulnerabilities in VMware ESX, vCenter, Workstation and Fusion, and is rated Critical as a whole. Two of them, CVE-2026-59309 and CVE-2026-59310, carry a CVSS score of 9.8, and cover an authentication bypass and arbitrary code execution in vCenter respectively. A third, CVE-2026-47876 at 9.3, lets an attacker with administrative privileges inside a virtual machine execute code on the ESX host. Broadcom states that it has no information suggesting the vulnerabilities have been exploited, and that no workaround exists.

Updated 17 August 2026: CVE-2026-59310 is now being exploited in the wild. The German security firm QUIRSO has described a campaign that began five days after the vulnerability became public. QUIRSO estimates that 361 unique IP addresses across 47 countries have been compromised, and assesses with moderate confidence that the operator is Chinese-speaking. The attacker executed code as root on vCenter, installed a backdoor communicating over WebSocket, left JSP web shells behind, and created new administrator accounts in vSphere and on ESXi. The intrusion ended with ransomware derived from Babuk. Broadcom's original advisory stated that it had no information indicating exploitation. That is no longer the case.

What happens technically

CVE-2026-59309 sits in VMware Directory Service, the directory component of vCenter, and is described as an authentication bypass. The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H yields 9.8 points, and expresses that an attacker with network access can exploit the weakness without privileges and without any user action, with full impact on confidentiality, integrity and availability. The weakness type is classified as CWE-303, incorrect implementation of an authentication algorithm. CVE-2026-59310 sits in the vCenter syslog server, is a directory traversal classified as CWE-22, and carries the same vector and the same score. It lets an attacker with network access execute arbitrary code. Broadcom states in the questions and answers document accompanying the advisory that both flaws are in vCenter itself, and that they are present regardless of whether the organisation uses Enhanced Linked Mode or Integrated Windows Authentication. Turning those features off therefore does not help.

CVE-2026-47876 is an out of bounds write in the VMXNET3 virtual network adapter, classified as CWE-787 and scored at 9.3. Broadcom confirms explicitly that this is a virtual machine escape: an attacker who already holds local administrative privileges in a virtual machine using the VMXNET3 adapter can execute code on the ESX host. The vector begins with AV:L, meaning local access, which here is the inside of the virtual machine. Virtual machines using other network adapters are not affected by this flaw, but Broadcom advises against switching adapter types as a countermeasure and points to the fix being in ESX. The two remaining vulnerabilities are less severe. CVE-2026-41703 is an out of bounds read requiring virtual machine deployment privileges, and it can disclose information or stop the host process. It is scored at 7.6, while Broadcom records 2.7 for Workstation and Fusion, where the impact is limited to information disclosure. CVE-2026-41709 is an insufficient logging flaw in ESX scored at 2.7, letting an administrator perform certain operations without them being recorded. No workaround exists for any of the five, the fixes are cumulative, and Broadcom writes that the vulnerabilities also reach VMware Cloud Foundation, vSphere Foundation, Telco Cloud Platform and Telco Cloud Infrastructure, because those stacks contain ESX and vCenter.

What this means for you if you run vCenter and ESX

vCenter is the control layer beneath the virtual platform you run. Whoever gets past authentication there is not facing a single server, but everything the platform runs. Berigo's assessment is that the key question is not whether your vCenter is exposed to the internet. Such exposure is rare. The question is whether vCenter is reachable from your ordinary client network, because both critical vulnerabilities require nothing more than network access. A single compromised office machine is then enough to place the attacker at the control layer. Broadcom itself classifies this as an emergency change. The absence of observed exploitation is precisely the reason for you to use the window now.

The virtual machine escape is the second half of the story, and it lands on an assumption your architecture may rest on. Virtualisation is used to separate zones of differing sensitivity, and that separation assumes the hypervisor holds. With CVE-2026-47876 the separation depends on ESX being patched, not on how you drew the zones. The logging flaw is small in numbers and large in consequence for investigation. An administrator can act without leaving a trace, and your audit trail then fails exactly where you need it. If NIS2 covers your organisation, this is a concrete expression of the Article 21 requirements for vulnerability handling and for logging. We would add two practical traps. The first is unsupported versions, since Broadcom writes that vSphere 7 reached End of General Support on 2 October 2025, and that older versions should be presumed affected. The second is the upgrade restriction Broadcom calls back in time, where these fixes block later upgrades to certain VMware Cloud Foundation versions. If you are in the middle of an upgrade, weigh the order of work before you start.

Berigo recommends

• Treat the update as an emergency change, as Broadcom does, and move vCenter and ESX to the versions the advisory lists.
• Check whether vCenter is reachable from the client network, and restrict access to a dedicated management network. Both critical vulnerabilities require only network access.
• Plan the host updates around vMotion and rolling reboots, and check whether the environment qualifies for ESX Live Patch. Broadcom states that vCenter Quick Patch is not available for these updates.
• Map unsupported installations, in particular vSphere 7 and earlier, and raise them as a separate risk item. They receive no fix through the ordinary channels.
• If you are in the middle of an upgrade, check the upgrade restriction described in the advisory before installing, so that the fix does not block the path onwards.