A network-reachable VMware vCenter has two critical flaws: one lets an attacker bypass authentication in the Directory Service, and the other lets an attacker execute code through directory traversal in the Syslog server. Both carry a 9.8 CVSS score in Broadcom’s five-CVE advisory. Administrators of vCenter, ESXi, Cloud Foundation and related VMware products need to match their installed branches to the component-specific fixes.

Broadcom published the advisory July 29, added express patches August 3 and updated the 7.0 guidance August 19. Its Cloud Foundation 9.1 patch catalog was updated October 29. For an older cluster, start with the product and component actually installed, then follow its row in the advisory. Broadcom says the vulnerabilities were privately reported and lists no workaround for the five issues.

Network access reaches vCenter

The vCenter pair has the same network-access prerequisite but different effects. For CVE-2026-59309, the VMware Directory Service authentication bypass gives a malicious actor unauthorized access to vCenter. For CVE-2026-59310, traversal in vCenter’s Syslog server can lead to arbitrary code execution. Broadcom credits Phil Brass and Matt South of Atredis Partners for both reports. A management interface reachable from a user or untrusted network deserves priority because the advisory’s stated entry condition is network access to vCenter. Restrict that access to administrative networks and approved management hosts while scheduling the patch.

The guest-to-host path is different. CVE-2026-47876 is an out-of-bounds write in ESX’s VMXNET3 virtual network adapter. Broadcom says an actor with local administrative privileges inside a VM using VMXNET3 may execute code on the host. Broadcom states, “Non VMXNET3 virtual adapters are not affected by this issue.” The score is 9.3. Broadcom credits Nguyen Hoang Thach of STARLabs SG, working with Pwn2Own, for the report. Inventory VM adapter types and guest administrative access to scope this host risk; patch the ESXi host on the matching branch. A guest adapter inventory identifies where that attack prerequisite exists, while host build inventory identifies where the fix is installed.

The other two fixes matter

CVE-2026-41703 concerns an out-of-bounds read in ESX, Workstation and Fusion. An actor with VM deployment privileges could expose information or, more likely on ESX, cause a host-process denial of service. Broadcom limits Workstation and Fusion impact to information disclosure and scores those desktop products 2.7, versus a maximum 7.6 for the ESX issue. CVE-2026-41709 lets a malicious ESX administrator perform certain operations without those operations being logged; Broadcom scores it 2.7 and credits Ian Barton of CrowdStrike. This logging gap complicates a retrospective review of administrator activity on an unpatched host. Treat a clean operation log as one input, and use independent change and access records when investigating an affected system.

Match components to fixed builds

For vCenter 8.0, Broadcom’s matrix lists 8.0 U3k and the 8.0 U2f express patch for the two critical vCenter issues. The vCenter 8.0 U3k release notes identify ISO build 25600417 and confirm fixes for CVE-2026-59309 and CVE-2026-59310. On Cloud Foundation and vSphere Foundation 9.1.x, the matrix recommends vCenter 9.1.0.0300; the authentication bypass was first fixed in 9.1.0.0200, and Broadcom says fixes are cumulative. For 9.0.x vCenter, use 9.0.2.0100. A 7.0 installation with extended support needs Broadcom Support’s patch guidance. Cloud Foundation 5.x uses an async patch to 8.0 U3k; telco branches use the advisory’s KB449886 guidance.

For ESXi 8.0, the VMXNET3 fix is ESXi80U3k-25595708 or the ESXi80U2f-25626445 express patch. The ESXi U3k release notes identify build 25595708 and say the patch is live-patchable for clusters managed with vSphere Lifecycle Manager images. For a vSphere Update Manager baseline, the release notes require a host reboot and VM migration or shutdown, and say to include both dependent bulletins or the rollup bulletin in the baseline. Cloud Foundation 9.1.x lists ESXi-9.1.0.0200-25557999 for this issue; 9.0.x lists ESXi-9.0.2.0100-25595025. The advisory’s separate matrices give the fixed rows for the lower-severity ESX issues, including ESXi80U3i-25205845 for CVE-2026-41703 and ESXi80U3j-25429389 for CVE-2026-41709. Workstation and Fusion 25H2 move to 26H1 for CVE-2026-41703.

Plan version jumps as well as patching. Broadcom’s vCenter 8.0 U3k notes say an upgrade from that release to vCenter 9.1.0 or its patches is unsupported; choose a supported forward path before changing a mixed estate. This is a reason to read the release notes for the actual target, even when the security matrix gives a fixed build.

Verify each host and manager

Start with the vCenter appliances that untrusted networks can reach. Limit management access to approved administrative paths, then record each installed vCenter version and compare it to the relevant advisory row. Inventory ESXi host builds alongside VMs configured with VMXNET3 and guest-admin access. Upgrade affected hosts to their branch’s fixed build; account for the rest of the advisory’s ESX fixes and the desktop products in the same change plan. Check the installed build again after the change against Broadcom’s component-specific matrix. On ESXi 8.0 U3k, the release-notes build is 25595708; on vCenter 8.0 U3k, it is 25600417.

If earlier intrusion is suspected, review independent access, change and VM-administration history for the period before the upgrade, especially because CVE-2026-41709 can leave certain administrator operations out of ESX logs.