Are these flaws being actively exploited?

According to Broadcom, as of the advisory date (29 July 2026) there's no evidence of in-the-wild exploitation or active scanning. Given VMware products' history as a ransomware target, that can change quickly.

Is there any mitigation if I can't patch immediately?

Broadcom publishes no workarounds: the only mitigation is to update. Reducing management-plane exposure (network segmentation, restricted access, no internet exposure) limits the attack surface but doesn't replace the patch.

Which of the three critical flaws should I patch first?

The two vCenter flaws (CVE-2026-59309 and CVE-2026-59310) need no prior authentication and compromise the entire management plane, so start with your most exposed vCenters. The VM escape (CVE-2026-47876) requires local admin on a VM — a higher bar.

How do I check whether my vCenter is exposed?

Test from an external network which management interfaces respond, and review firewall rules, VPN access and any forgotten modems or links missing from the inventory. The vCenter and ESXi host interfaces should not be reachable from the internet or from user networks; their place is a segmented management network with restricted access.

Does the VM escape affect all my VMs?

CVE-2026-47876 requires the VM to use the VMXNET3 adapter and the attacker to hold local administrator privileges inside it. Its real risk shows up in two-stage intrusions: compromise a workload first, then break out to the hypervisor and, from there, reach the other machines sharing that host.

How does this relate to NIS2, DORA or ENS?

Vulnerability management on critical virtualisation infrastructure is an obligation under these frameworks for the entities they cover. An unpatched vCenter facing a known CVSS 9.8 is hard to defend to a supervisor if it turns into an incident; documenting the patching — date, versions and assets covered — serves as evidence of diligence.

Three critical VMware vCenter & ESXi flaws to patch

On 29 July 2026, Broadcom released advisory VMSA-2026-0006, patching five vulnerabilities across VMware ESXi, vCenter, Workstation and Fusion. Three are critical, scoring up to CVSS 9.8, and they hit the component that runs almost every modern data centre: the virtualisation management plane. There are no workarounds — only the patch — and one of them lets an attacker break out of a virtual machine and run code on the host. If your estate runs on vSphere, this is work for this week, not next month's maintenance window.

Broadcom fixes three critical flaws in VMware: an authentication bypass in vCenter (CVE-2026-59309, CVSS 9.8), an arbitrary file read/write that leads to RCE in vCenter (CVE-2026-59310, CVSS 9.8), and a VM escape in ESXi (CVE-2026-47876, CVSS 9.3).
Two of them need no prior authentication. Owning vCenter means owning every host and workload it manages.
Broadcom reports no known in-the-wild exploitation as of the advisory date — but there are no workarounds, so patching is the only fix.
Checking whether your vSphere management plane is reachable, and rolling out the fixed builds, is the immediate priority.

What exactly has been published

VMSA-2026-0006 bundles five issues. The three critical ones carry the real risk:

CVE-2026-59309 (CVSS 9.8) — vCenter authentication bypass. It sits in the VMware Directory Service. An attacker with network access to vCenter can bypass authentication and gain unauthorised access to the system. No credentials required.
CVE-2026-59310 (CVSS 9.8) — vCenter RCE. A directory traversal flaw in the vCenter Syslog service lets a remote, unauthenticated attacker read or write arbitrary files and, ultimately, execute code on the system.
CVE-2026-47876 (CVSS 9.3) — ESXi VM escape. An out-of-bounds write in the VMXNET3 virtual network adapter. An attacker with local administrative privileges on a VM using that adapter can execute code on the host. Broadcom describes it explicitly as a VM escape.

Two lower-severity issues round out the advisory: CVE-2026-41703 (high; ESXi, Workstation and Fusion), which lets someone with VM deployment permissions obtain information or, more likely, trigger a denial of service on the host process; and CVE-2026-41709 (low; ESXi), which allows an administrator to carry out certain actions without them being logged.

Fixed builds are available in VMware Cloud Foundation and vSphere Foundation 9.1.0.0300 and 9.0.2.0100, vCenter Server 8.0 U3k, and the matching ESXi builds (9.1.0.0200, 9.0.2.0100 and 8.0 U3k). Broadcom pairs the advisory with an FAQ covering impact and patching requirements.

Why vCenter is a single point of compromise

A CVE in an exposed web server compromises that server. A CVE in vCenter compromises the data centre. vCenter centrally manages the ESXi hosts, the virtual machines, the permissions, the templates and the operational workflows for the entire platform. Whoever controls vCenter isn't attacking one server — they inherit the keys to all of them.

That's why an unauthenticated authentication bypass (CVE-2026-59309) against vCenter is every bit as serious as a CVSS of 9.8 implies. The attacker needs no prior foothold, no phishing, no stolen credentials. Network access to the management interface is enough to get in. From there they can change permissions, deploy malicious workloads, clone or exfiltrate entire machines and move laterally into any virtualised system.

This is precisely why the vSphere management interface should never be reachable from untrusted networks, let alone the internet. The lesson repeats with every management-plane flaw — we saw it recently with firewall management products: when the console that runs your security is exposed, an authentication bypass turns a vulnerability into a full takeover.

The VM escape, in context

CVE-2026-47876 belongs to a class of bug that breaks virtualisation's core promise: isolation between guest and host. If an attacker already controls a virtual machine — say, a compromised server in a virtualised DMZ — an escape lets them jump to the hypervisor and, from there, reach every other VM sharing that host.

It isn't a new pattern, nor one unique to VMware. A few weeks ago we looked at «Januscape», a VM escape in KVM that had sat dormant in the code for sixteen years. The overlap is telling: the same risk — break out of the VM, take the physical host — resurfaces across different hypervisors, from different technical roots. Treating hypervisor isolation as an unbreakable security boundary is a threat-modelling mistake. It's one more barrier, and barriers have flaws.

The practical difference: CVE-2026-47876 requires local administrator privileges inside the VM, which raises the bar compared with the two vCenter flaws, which ask for nothing. But in a two-stage intrusion — compromise a workload first, then escalate toward the infrastructure — that requirement is met often enough.

No exploitation yet, but the window is closing

Broadcom states that, as of the advisory date, it has no evidence of in-the-wild exploitation or active scanning for these flaws. That's welcome news with a short shelf life. VMware products are a recurring priority target: there's a long track record of vSphere bugs going from patch release to mass exploitation within days or weeks, frequently abused by ransomware operators who encrypt ESXi datastores directly.

The lack of a workaround sharpens the urgency. When a vendor offers a temporary mitigation, there's room to plan. Here there isn't: either you apply the patch or the system stays vulnerable. Broadcom has classed the updates as emergency changes.

For anyone running a large estate who can't patch everything at once, order matters. Prioritise by exposure and criticality: internet- or broadly reachable vCenters first, then the hosts carrying your critical assets. A prioritisation approach driven by real exploitability and exposure — not CVSS alone — helps decide what's due today and what can wait; we set it out in our guide on prioritising vulnerabilities with KEV, EPSS and SSVC.

What the regulation requires

Vulnerability management on critical virtualisation infrastructure isn't just hygiene — for many organisations it's a regulatory obligation.

Article 21 of the NIS2 Directive (EU 2022/2555) requires essential and important entities to adopt risk-management measures that explicitly include vulnerability handling and disclosure, security in systems maintenance and business continuity. An unpatched vCenter facing a known CVSS 9.8 is, in practice, hard to defend to a supervisor if it turns into an incident. How that expectation plays out in a heavily regulated sector is something we cover in our analysis of cybersecurity in healthcare and NIS2.

For financial entities, DORA (Regulation (EU) 2022/2554) — fully applicable since January 2025 — points the same way with its ICT risk-management framework and its demand for digital operational resilience. And here's the nuance that keeps regulators up at night: concentration risk. When dozens of critical services depend on a single virtualisation platform, a flaw in that management plane isn't an isolated incident — it's a systemic risk to the entity. In the public sector, Spain's ENS (National Security Framework) imposes equivalent controls for vulnerability management and for protecting the supporting infrastructure.

What to do now

An orderly response to VMSA-2026-0006 works across five fronts:

Patch vCenter and ESXi to the fixed builds (VCF/vSphere Foundation 9.1.0.0300 or 9.0.2.0100, vCenter 8.0 U3k and the matching ESXi builds). It's the only real mitigation; there's no workaround.
Get the management plane off the general network. The vCenter and ESXi host interfaces belong on a segmented management network, with no exposure to the internet or user networks, access restricted by allow-list, and reached through a bastion or a VPN with MFA.
Review your current exposure before you call this closed. Check from the outside which management interfaces are reachable; a vCenter that "shouldn't" be exposed sometimes is, thanks to a forgotten firewall rule or a cellular modem missing from the inventory.
Strengthen telemetry. Watch for anomalous vCenter logins, unexpected account creation or permission changes, and unusual file writes on the Syslog service. Remember that CVE-2026-41709 lets an administrator act without leaving a log entry: don't rely on vCenter's own logs alone to catch abuse. If you find signs of compromise, trigger your incident response procedure before you call the environment clean.
Document the action — patch date, versions, assets covered — as evidence of diligence for NIS2, DORA or ENS.

The bottom line

VMSA-2026-0006 is not a routine patch. It combines an unauthenticated authentication bypass and RCE on the brain of your virtualisation platform, plus a VM escape on the hypervisor. The absence of public exploitation today is a window, not a guarantee; with vSphere, those windows close fast. Prioritise exposed vCenters, roll out the fixed builds, and take the chance to confirm your management plane isn't reachable from where it shouldn't be. If you need help assessing the exposure of your virtualisation infrastructure, or shaping a vulnerability-management process aligned with NIS2 or DORA, talk to the Hard2bit team.

This analysis is provided for informational and defensive purposes and reflects the information available on its publication date; always verify the details against the vendor's official advisories, which may be updated. The detection, hardening and configuration measures should be validated in a test environment and adapted to your architecture before being applied in production. References to NIS2, DORA or ENS are informational and do not constitute legal advice: consult the official text and a qualified adviser. Apply everything under your own judgement and responsibility.

Three critical VMware vCenter and ESXi flaws to patch now