Two 9.8s in vCenter, a VM escape and the flaw nobody will look at

vCenter is the control room of your virtualization: from there everything gets powered on, powered off, moved, cloned and deleted. On 29 July Broadcom published VMSA-2026-0006 and, among the five flaws it fixes, there are two rated CVSS 9.8 that let someone into that room without credentials, and one rated 9.3 that allows jumping from inside a virtual machine onto the server running it. The advisory's own answer to "are there workarounds?" is a single word: no.

We run VMware and Proxmox in production, we have migrated companies from VMware to Proxmox, and we have also recommended staying put when that made sense. We are not resellers of either and we do not sell licences, so this post is not about cashing in on the scare. It is about four concrete things: what is actually inside the advisory, in what order to apply it — which has changed —, where the patches are if you were left with a perpetual licence and no support, and the fifth flaw on the list, the one that will not make any headline because it barely scores at all.

The five flaws, plainly

A precision note, because it matters: the advisory says the batch's scores range from 2.7 to 9.8 under CVSS 3.1, and explicitly confirms the 2.7 for CVE-2026-41703 on Workstation and Fusion, where the effect is limited to information disclosure. The per-CVE breakdown published by the specialist press puts that same flaw at 7.6 on ESX — there it can indeed bring down the host process — and the logging flaw at 2.7. Broadcom states it has no information suggesting exploitation in the wild for any of the five.

Before arguing about the maintenance window

This week's conversation in many companies will be the usual one: "I have no window". It is worth separating the two halves of the work, because they do not cost remotely the same.

• vCenter does not stop your workloads. The Q&A document says so itself: updating vCenter does not affect running virtual machines or containers; you lose the vSphere Client — and other management paths — for a while. In other words, the part holding the two 9.8s is the cheap one.
• ESX does require a host restart. That is where the real work sits: vMotion to drain each host, a rolling reboot across the cluster, and powering down machines that cannot live-migrate. If your cluster has no spare capacity, that is your actual bottleneck, not the patch.
• Live Patch works here. These ESX updates are compatible with Live Patch if your environment supports it — it has been available since ESX 8.0.3, it is worth confirming in the release notes, and watch out for hosts using a TPM: those are only eligible from VCF 9.1 onwards — which according to Broadcom can make the process "several orders of magnitude" faster. vCenter Quick Patch, on the other hand, is not available for these patches: there you are back to the traditional method, or RDU if you have it set up.

Translated: the window you need to close the two most serious flaws is far smaller than the committee approving it will assume. It is worth putting it in those terms before the meeting drifts.

The order you knew is no longer the only one

Here is the part of the advisory that has barely been covered. The classic rule was vCenter first, hosts afterwards. Broadcom now acknowledges that this requirement has evolved and that it is often possible to update ESX before vCenter without trouble; you check it in the product interoperability matrix, cross-referencing your vCenter version against ESX (and vSAN, if you use it).

What is valuable about those two sentences is not the order itself: it is that they leave no argument for anyone planning to park the advisory until September. The patches are also cumulative and require nothing applied beforehand, so there is no chain of prerequisites to negotiate.

One warning worth reading in full if you are mid-project: these vSphere 8.0 and 9.0 updates trigger a "back in time" restriction that blocks upgrades to VMware Cloud Foundation 9.x. If that migration was under way, decide with the calendar in front of you; compatibility is restored in later releases, as with previous restrictions of this type.

The VM escape and a temptation worth resisting

CVE-2026-47876 is a textbook virtual machine escape: someone who already holds local admin inside a VM using the VMXNET3 adapter can execute code on the ESX host. It requires being inside, yes. But "inside with administrator privileges" is exactly what anyone who compromises a run-of-the-mill application server obtains. The boundary many architectures sell as solid — "each environment in its own VM" — depends on the hypervisor not having flaws of this kind. Every so often it does, which is why VM separation does not replace network segmentation or least privilege.

The temptation, for anyone who cannot patch right away, is to change the virtual adapter: VMs using another card type are not affected by that flaw. The advisory recommends against it for two reasons we share: non-paravirtualized adapters such as e1000 have had vulnerabilities of their own, and switching to them costs you the performance paravirtualized drivers provide — up to 40 % better I/O, according to Broadcom. Update ESX; do not redesign your fleet's virtual hardware to buy two days. You do not need to touch VMware Tools either: the flaw is on the host side.

The flaw nobody will look at

The fifth on the list is CVE-2026-41709, "insufficient logging" in ESX: an administrator can perform operations without those operations being recorded. It is the lowest-scoring of the batch and the one that will not appear in any headline. We read it the other way round from the ranking.

CVSS scores the impact on the confidentiality, integrity and availability of the system. It does not score — because that is not its job — your ability to reconstruct afterwards what happened. A logging flaw knocks nothing over: it takes away the witness. And chained with the other four it changes size. If someone gets in through one of the 9.8s and ends up operating as an administrator, this 2.7 decides whether your later report says "this is what they did" or "this is what we think they did".

We wrote about this recently regarding another vendor: applying the patch does not evict whoever was already inside. Here there is an extra twist, because what degrades is not the system but the evidence. And evidence is no longer an internal matter: when you have to notify an incident under NIS2, or when a large customer sends over their supplier questionnaire, what they ask for is facts with timestamps, not impressions.

Our rule when an advisory includes a logging flaw is short: patch, mark the log period before the patch as unreliable, and do not accept a "nothing looks odd" from that period as if it were a clean review. An incomplete log is not a reassuring log; it is an incomplete log.

If your vSphere is old, or you no longer pay for support

This is where a lot of people are after the licensing changes of the past two years, and it is where the advisory holds the most useful information:

• vSphere 6.5 and 6.7: Broadcom does not evaluate products past their End of General Support date, so they are not in the matrix. The instruction is to assume they are affected.
• vSphere 7: affected. It reached End of General Support on 2 October 2025; if you have an extended support contract, patches are requested through that channel.
• vSphere 8: security updates are built on top of Update 3. Being on U3 is not strictly required to receive the patch, but it is the version Broadcom recommends being on.
• Perpetual licence and expired support contract: you are entitled to the patch anyway. Under the commitment published on 15 April 2024, all customers — including those whose support has lapsed — get access to patches for Critical Severity Security Alerts on supported versions of vSphere. You need to create a free account on the support portal. This is the point most people miss and precisely the one most needed by those left holding perpetual licences.
• Third-party engineered systems (VxRail, SimpliVity and the like): do not apply the vSphere patch on your own. Those vendors control patch levels as part of their qualification process; the guidance has to come from them.

To check which version you are on without fighting the interface, the quick way is PowerCLI: Get-VMHost | Select-Object Name,Version,Build for the hosts, and the $global:DefaultVIServer.Version and .Build variables after connecting with Connect-VIServer for vCenter.

What this advisory is not

It is not an argument for migrating. And we say that as the people who have spent months writing about the VMware exodus that never quite happened and who run migrations to Proxmox for those who need them. Proxmox publishes its own security advisories and also has to be patched, with its own reboots and its own windows. Switching hypervisor because of a July advisory moves the work somewhere else; it does not remove it.

The platform decision gets made with a spreadsheet, an inventory and a renewal calendar in front of you, and sometimes the right answer is to stay. What this advisory does say, with no room for interpretation, is simpler: if you run vSphere, you have work to do this week.

Sources (verified): the five CVEs with their component and effect, the absence of workarounds, the cumulative nature of the patches, the impact of updating vCenter and ESX, Live Patch compatibility and Quick Patch unavailability, the change of guidance on vCenter/ESX ordering via the interoperability matrix, the "back in time" restriction towards VCF 9.x, the advice against switching to e1000 (including the up-to-40 % I/O improvement from paravirtualized adapters), the fact that VMware Tools need not be updated, the status of vSphere 6.5/6.7/7/8, access to critical patches for customers without active support since 15 April 2024, and the PowerCLI commands — Broadcom's official "VMSA-2026-0006: Questions & Answers" document (29 July 2026) and the VMSA-2026-0006 advisory. CVSS scores of 9.8 (CVE-2026-59309 and CVE-2026-59310) and 9.3 (CVE-2026-47876), plus the per-CVE breakdown: The Hacker News and SecurityOnline (29 July 2026); the 2.7–9.8 range for the batch and the 2.7 for CVE-2026-41703 on Workstation and Fusion are in the official document. The reading of why a logging flaw gets underestimated when sorting by CVSS, the rule of marking the pre-patch log period as unreliable, and the judgment on the maintenance window are ours. Image: a restored mission control room (Wikimedia Commons, public domain).