VMware fixes critical vCenter and ESX flaws enabling authentication bypass and VM escape

Broadcom has published VMware Security Advisory VMSA-2026-0006 to address five vulnerabilities in VMware components used across vSphere, VMware Cloud Foundation and related platforms. The advisory is rated Critical and should be handled with urgency because it includes two vCenter flaws reachable by an unauthenticated attacker with network access, plus a VMXNET3 vulnerability that may allow a virtual machine to escape to the ESX host.

The operational message is direct: there are no official workarounds. Broadcom recommends installing the fixed versions listed in the advisory. The patches are cumulative, so later versions in the same supported branch include the applicable fixes as well.

This should be treated as an emergency change, but not as an improvised one. vCenter and ESX hosts are central infrastructure components. Updating vCenter temporarily interrupts the vSphere Client and other management interfaces, although running virtual machines and containers continue to operate. Updating ESX requires a host reboot, which means administrators need to plan vMotion, rolling reboots, maintenance windows or shutdowns for workloads that cannot migrate.

Vulnerabilities addressed

#

The three critical issues are the two vCenter vulnerabilities, CVE-2026-59309 and CVE-2026-59310, and the VMXNET3 flaw, CVE-2026-47876. The remaining two issues carry lower severity ratings, but they still matter in environments where auditability, delegation and operational visibility are part of the security model.

Authentication bypass in VMware Directory Service

#

CVE-2026-59309 affects VMware Directory Service in vCenter. According to the official advisory, a malicious actor with network access to vCenter may exploit the issue to bypass authentication and gain unauthorized access to the system.

This is why management-plane exposure should never be treated as a minor detail. Even when vCenter is not directly exposed to the Internet, the risk remains relevant in internal networks, shared administrative segments, broad VPN access models or scenarios where an administrator workstation has already been compromised.

The vulnerability has a CVSS score of 9.8 and is rated Critical. Remediation requires applying the fixed versions listed in the official response matrix. No workaround is available.

Code execution through the vCenter Syslog Server

#

CVE-2026-59310 affects the vCenter Syslog Server and is described as a directory traversal vulnerability. Broadcom’s stated impact is severe: an unauthenticated attacker with network access to vCenter may exploit it to execute arbitrary code.

That places vCenter at the center of the risk. vCenter concentrates management, inventory, administrative authentication, automation, permissions and operations across clusters. A flaw that allows code execution in this component should be prioritized even when compensating controls such as internal firewalls or segmentation are present.

Like CVE-2026-59309, this vulnerability has a CVSS score of 9.8, is rated Critical and has no official workaround. The supported remediation path is to update vCenter to a fixed version.

VM escape through the VMXNET3 adapter

#

CVE-2026-47876 affects the VMXNET3 virtual network adapter on the ESX side. It is an out-of-bounds write vulnerability and is rated Critical with a CVSS score of 9.3.

The exploitation prerequisite matters: the attacker must first have administrative privileges inside a virtual machine that uses VMXNET3. From there, the vulnerability may allow code execution on the ESX host, making this a VM escape. Virtual machines using other virtual network adapters are not affected by this specific issue.

That does not make switching from VMXNET3 to E1000 an official recommendation. Broadcom’s supplemental guidance warns that moving to non-paravirtualized devices is not a sound general strategy: those devices have also had vulnerabilities and can reduce performance. The supported fix is to update the ESX host.

Updating VMware Tools is also not required to resolve this CVE. VMXNET3 has an in-guest driver, but the issue addressed by this advisory is on the ESX side. Patching ESX is what removes the vulnerability.

Other vulnerabilities included in the advisory

#

CVE-2026-41703 is an out-of-bounds read vulnerability affecting ESX, Workstation and Fusion. On ESX, Broadcom rates it Important with a CVSS score of 7.6. An attacker with virtual machine deployment privileges could trigger the issue, potentially causing information disclosure or, more likely, a denial-of-service condition in the host process. On Workstation and Fusion, the impact is limited to information disclosure and the issue is rated Low with a CVSS score of 2.7.

CVE-2026-41709 affects ESX and relates to insufficient logging. A malicious administrator may perform certain operations without those operations being recorded. It is rated Low with a CVSS score of 2.7, but it is still relevant for regulated environments, teams with multiple administrators and infrastructures that rely on audit trails for incident response.

Affected products and fixed versions

#

Affected products include VMware ESX/ESXi, VMware vCenter, VMware Workstation, VMware Fusion, VMware Cloud Foundation, VMware vSphere Foundation, VMware Telco Cloud Platform and VMware Telco Cloud Infrastructure.

The official VMSA should always be treated as the definitive source for supported versions, builds and upgrade paths. Its response matrix also includes separate guidance for VMware Cloud Foundation 5.x and Telco products, which should be followed according to the platform deployed.

Operational impact of patching

#

Updating vCenter temporarily affects access to the vSphere Client and other management methods. This may interrupt administrative tasks, API-dependent automation or inventory operations, but it does not stop virtual machines or containers that are already running.

ESX hosts are different. Updating ESX requires a host restart. Broadcom recommends using vMotion to move virtual machines to alternate hosts and then applying updates in a rolling reboot model. Virtual machines that cannot use vMotion must be powered down during the host restart.

In compatible environments, ESX Live Patch may reduce disruption. Eligibility depends on the version, the patch type and the environment’s requirements. The vCenter updates in this advisory are not eligible for Quick Patch, so they must be planned through the standard update mechanisms, or through Reduced Downtime Upgrade where that model is available and configured.

The “back-in-time” upgrade restriction

#

Broadcom’s supplemental guidance notes a possible “back-in-time” restriction with some of these patches. The issue occurs when a patch applies a newer build number to a branch that is later upgraded to a VMware Cloud Foundation 9.x target carrying a lower build number, resulting in a compatibility error.

This should not block the security fix, but it should be included in planning if the organization is in the middle of a VCF 9.x migration. The practical approach is to validate the VMware Product Interoperability Matrix and review Broadcom’s linked knowledge base guidance before deciding the final sequence.

Recommendations for administrators

#

1. Inventory vCenter and ESX versions and builds.
2. Confirm compatibility in the VMware Product Interoperability Matrix.
3. Classify the update as an emergency change.
4. Update vCenter and ESX hosts in a planned sequence.
5. Use vMotion and rolling reboots where possible.
6. Validate backups and recovery mechanisms.
7. Monitor administrative events and access to vCenter.
8. Restrict exposure of management interfaces.
9. Confirm the update after the reboot.
10. Review integrated platforms such as VxRail or SimpliVity with the respective vendor.

For quick version checks with PowerCLI:

Connect-VIServer -Server "vcenter.example.com"

$global:DefaultVIServer |
    Select-Object Name, Version, Build

Get-VMHost |
    Select-Object Name, Version, Build

These commands are for inspection only. They do not replace update planning and should not be turned directly into automated patching without validation.

Known exploitation

#

Based on the official information available at publication time, Broadcom had no information suggesting exploitation of these vulnerabilities in the wild. BleepingComputer reported the same position while adding broader context: VMware servers are valuable targets because vCenter and ESXi often provide access to large portions of an organization’s workloads and data.

There is therefore no basis to state that these flaws are being actively exploited. There is also no reason for complacency: the combination of vCenter, remote code execution and VM escape is enough to justify high priority.

Conclusion

#

VMSA-2026-0006 is a high-impact advisory for teams administering VMware infrastructure. The critical vCenter flaws reduce the safety margin around a central management component, while the VMXNET3 vulnerability opens a VM escape path once an attacker already controls a virtual machine with administrative privileges.

Because there are no official workarounds, the response should be patching. The challenge is to do it with operational discipline: validate compatibility, prepare backups, plan maintenance windows, use vMotion where possible and confirm builds after reboots. The risk is high, but careful execution reduces the chance of unnecessary downtime.

Sources

#

• Broadcom - VMware Security Advisory VMSA-2026-0006
• VMware VMSA-2026-0006 Questions & Answers
• BleepingComputer - VMware fixes three critical flaws allowing auth bypass, VM escapes