VMware vCenter flaws need emergency patching as 7.0 guidance arrives

Broadcom’s updated VMSA-2026-0006.2 advisory adds critical patch guidance for vSphere 7.0 after disclosing two network-reachable vCenter vulnerabilities rated 9.8. CVE-2026-59309 can allow authentication bypass, while CVE-2026-59310 may permit arbitrary code execution through a directory-traversal flaw. Neither requires an authenticated vCenter account, and Broadcom provides no workaround, so organisations should restrict vCenter exposure and treat remediation as an emergency change.

Both carry a CVSS score of 9.8. The published attack conditions require no authenticated vCenter account; network access to vCenter is the meaningful precondition. There’s no need for panic, but this belongs in an emergency change, not the next routine maintenance window. vCenter is the control plane for hosts, virtual machines, storage and identity integrations. A compromise reaches far beyond one appliance.

The immediate exposure is vCenter

Verified fact: CVE-2026-59309 is an authentication bypass in VMware Directory Service. A malicious actor with network access to vCenter may bypass authentication and gain unauthorised system access. CVE-2026-59310 is a directory-traversal vulnerability in the vCenter Syslog server that an actor with network access may use to execute arbitrary code. Broadcom classifies both as Critical and provides no workaround.

The first question isn’t whether vCenter is directly exposed to the internet. It shouldn’t be. Management-plane access can still come from inside the corporate network: a compromised workstation, VPN access, a poorly segmented management VLAN, supplier connectivity or another administrative foothold. Review every route to the vCenter appliance, not just the public firewall rule.

Analysis: Workload availability often delays hypervisor and management-plane maintenance. That calculation needs adjusting here. Updating vCenter briefly interrupts the vSphere Client and related management interfaces, but doesn’t stop running virtual machines and containers. ESX patching is more involved because hosts need restarting, yet the vCenter emergency shouldn’t wait for every host-maintenance dependency to be resolved. Patch the exposed control plane first, then carry out host work in a planned rolling sequence where capacity allows.

What’s affected, and which fixed versions should you use?

VMSA-2026-0006.2 covers VMware vCenter, ESX, Workstation and Fusion, along with product stacks containing those components: VMware Cloud Foundation (VCF), VMware vSphere Foundation (VVF), VMware Telco Cloud Platform and VMware Telco Cloud Infrastructure. Patches are cumulative, so a later release in the same supported branch also resolves the listed issue.

Critical vCenter issues: CVE-2026-59309 and CVE-2026-59310

The 19 August update matters especially to vSphere 7.0 users. vSphere 7 reached end of general support on 2 October 2025, and the advisory doesn’t name a generally downloadable 7.0 build. Customers with an extended support contract are directed to Broadcom Support. That’s awkward, but it matters: being on 7.0 isn’t an excuse for inaction, and an unqualified update path isn’t a substitute for vendor-supported remediation.

ESX, Workstation and Fusion issues in the same advisory

The advisory also covers CVE-2026-47876, a Critical VMXNET3 out-of-bounds write flaw in ESX. It requires local administrative privileges in a guest VM using a VMXNET3 virtual network adapter, but could allow code execution on the host. This is a VM-escape risk and warrants urgent host remediation once the vCenter work is under way.

CVE-2026-41703 is an Important ESX out-of-bounds read issue. It can lead to information disclosure or, more likely on ESX, a denial-of-service condition in a host process when an actor has VM deployment privileges. Workstation 25H2 and Fusion 25H2 are also affected, though Broadcom rates the impact Low and limits it to information disclosure. CVE-2026-41709 is a Low-severity ESX insufficient-logging issue that could allow a malicious administrator to perform certain operations without those operations being logged.

This is an abbreviated operational view, not a replacement for the advisory’s response matrix. VCF, VVF and Telco deployments in particular must follow their supported lifecycle and asynchronous-patching procedures. Don’t treat embedded components as a standalone vSphere installation.

Detection and containment while patching is under way

Broadcom has not published indicators of compromise for these vulnerabilities. Incident review therefore depends on normal management-plane evidence, not a magic search string. Preserve relevant vCenter logs before broad changes. Review authentication activity, administrative-session creation, appliance and service logs, configuration changes, new or altered privileged identities, and unexpected task execution. Compare the results with change records and known administration windows.

Reduce vCenter reachability to the smallest viable set of administration jump hosts, automation systems and management networks. Remove broad workstation, user-VLAN and third-party access where practical. Validate firewall changes carefully: a rushed block that strands backup, monitoring or recovery tooling creates an operational problem of its own. Even so, tightly controlled management access is a reasonable compensating measure while the patch is tested and deployed.

For ESX, identify guests using VMXNET3 and prioritise hosts carrying higher-risk administrative workloads or less-trusted tenant workloads. Don’t switch guest adapters to e1000 merely to avoid CVE-2026-47876; Broadcom explicitly advises updating ESX rather than making that trade-off. Updating VMware Tools doesn’t fix the issue either: ESX is the vulnerable side.

Practical priorities for the next maintenance window

One complication should be surfaced early. Broadcom warns that the vSphere 8.0 and 9.0 updates in this advisory can create a “back in time” upgrade restriction for organisations part-way through a move to VCF 9.x. That affects scheduling, but it isn’t a blanket reason to defer two unauthenticated 9.8 vCenter flaws. Escalate the compatibility decision quickly, document it and take the least risky supported route.

Patch reliability matters as much as urgency. Release notes, dependency checks, rollback planning and post-update validation aren’t bureaucracy when the target is the virtualisation control plane. Update failures can create their own operational trouble, as the recent Microsoft Defender scan-crash fix showed. In this VMware case, though, indecision is the bigger risk.