SINGAPORE, 7 AUG 2026 — Broadcom has patched four flaws across VMware ESX, vCenter, Workstation and Fusion. Two of them score 9.8. The third is the one to read first: it lets code escape a virtual machine onto the host.
Singapore's Cyber Security Agency published the alert on 5 August with a single instruction: patch immediately.
The four
| CVE | CVSS v3.1 | Where | What an attacker gets |
|---|---|---|---|
| CVE-2026-59309 | 9.8 | VMware Directory Service | With network access to vCenter, bypass authentication and gain unauthorised access to the system |
| CVE-2026-59310 | 9.8 | vCenter Syslog server | With network access, execute arbitrary code via directory traversal |
| CVE-2026-47876 | 9.3 | VMXNET3 virtual network adapter | With local administrative privileges on a VM using VMXNET3, execute code on the underlying ESX host |
| CVE-2026-41703 | 7.6 | Host process | With virtual machine deployment privileges, read sensitive information or cause a denial of service in the host process |
From CSA alert AL-2026-096 of 5 August 2026, which reproduces Broadcom's descriptions. Affected products span VMware ESX, vCenter, Workstation and Fusion; the per-CVE product mapping is in the alert. CSA does not report active exploitation of any of the four.
The two 9.8s are the ones a scanner will escalate, and they deserve it. An authentication bypass in the directory service reachable by anything with network access to vCenter is about as bad as a management-plane flaw gets, and a directory traversal in the syslog server giving arbitrary code execution is not far behind.
Why the 9.3 is the interesting one
CVE-2026-47876 scores lower because it demands more: the attacker needs local administrative privileges on a virtual machine, and that machine must use the VMXNET3 adapter. Both are preconditions, and CVSS treats preconditions as mitigation.
In a hosting or cloud environment the first precondition is not a barrier. It is the product. A customer who rents a virtual machine has administrative privileges on it by design, and VMXNET3 is the default virtual network adapter for a great many guests.
The flaw offers a route from inside a rented VM to code execution on the physical host, putting an attacker in the same position relative to every other guest on that machine.
The fourth flaw runs the same way at lower severity: an attacker with virtual machine deployment privileges can read sensitive information or knock over the host process. Deployment privileges are, again, something a platform hands to tenants routinely.
The score describes the attacker, not the environment
These four flaws illustrate a general point about CVSS scores.
A severity score is computed from what an attacker must already have, but it cannot know whether that prerequisite is difficult to obtain or simply sold by the hour. In a single-tenant enterprise estate, local administrative privileges on a VM means somebody already breached you and the escape is a secondary concern. In a multi-tenant platform, it means somebody paid.
Patch ordering driven purely by the score will therefore put the two 9.8s first everywhere. That is right for an enterprise running its own vCenter behind a management network. For a provider selling virtual machines to strangers, the 9.3 is arguably the one that decides whether the platform's central promise still holds.
Neither reading is wrong. The number itself does not contain the distinction; the operator has to supply it.
The affected estate is wider than vCenter
The product mapping in the alert is worth reading before assuming this is a vSphere-only problem.
The two authentication and traversal flaws span VMware Cloud Foundation, VMware vSphere Foundation, standalone vCenter 8.0, VMware Telco Cloud Platform and VMware Telco Cloud Infrastructure. The guest-to-host write covers Cloud Foundation, vSphere Foundation, ESX 8.0 and Telco Cloud Platform.
Telco Cloud appearing twice is the detail regional operators should notice. That platform runs network functions for carriers, which places these flaws inside infrastructure that mobile and fixed-line services depend on rather than inside a corporate data centre.
The alert also covers Workstation and Fusion, which are desktop products. A single advisory spans products with almost nothing else in common because they all share the same virtual network adapter code, from laptop hypervisors to carrier platforms.
The week this arrived in
CSA published six alerts and advisories between 3 and 7 August, and this was not the only isolation failure among them.
The cPanel and WHM flaw published the same day lets an authenticated customer on a shared server reach databases belonging to other customers on that server. One breaks the boundary between tenants sharing an operating system; this one includes a break in the boundary between a guest and its host.
Two vendors, two layers of the stack, the same assumption failing in the same week: that the wall between one customer and the next holds because the platform says it does.
Why vCenter is the piece that matters
Two of the four flaws need network access to vCenter, the management plane for a VMware estate.
vCenter is the management plane for a VMware estate. It is where virtual machines are created, moved, snapshotted and destroyed, where access to them is granted, and where the hosts underneath are configured. An administrator with vCenter has the estate; software with vCenter has the same.
An authentication bypass there is not a step toward the objective. In most estates, it *is* the objective; everything after that is just administration.
This is why the management-plane exposure question matters more than the patch date for these two. A vCenter reachable only from a hardened administrative segment has a small population of potential attackers. One reachable from the general corporate network has whoever gets a foothold on any laptop.
What to do
Apply Broadcom's updates, taking version detail from the vendor rather than from CSA's summary or this report.
The ordering question is worth five minutes of thought before the change window opens. Establish whether the estate is single-tenant or multi-tenant, because that determines which of these four is the emergency. If untrusted parties have administrative access to guests on shared hosts, the escape flaw is the first item and not the third.
The second check is exposure of the management plane. Both 9.8s require network access to vCenter. A vCenter reachable from a general-purpose network — rather than from a restricted management segment — turns two flaws that need network adjacency into two flaws that need very little.
Preconditions are not equally hard
The point about the 9.3 flaw applies well beyond this advisory.
Severity frameworks give lower scores for attacks that have preconditions — needing local access, say, or specific privileges. That logic holds as long as the preconditions are genuine obstacles.
Cloud economics broke the assumption. Local administrative access on a virtual machine, physical proximity to a rented server, an account on a shared host — all are preconditions in the scoring sense and commodities in the market sense. A framework built when compute was owned rather than rented treats a purchase as a hurdle.
The practical consequence is narrow and repeatable: whenever a score is lowered because the attacker needs something, ask what that something costs. Sometimes the answer is a breach, and sometimes it is a card payment.
What to watch
Two things.
The first thing to watch is whether any of the four is reported as exploited. CSA does not describe them that way, but hypervisor escapes attract attention once a patch reveals the mechanism.
The second is whether the pattern from the start of the month continues. The flaws CISA listed in the first week of August were, without exception, systems that build, deploy, monitor or run other software. A hypervisor is the most literal instance of that category there is.
View author profile → · Editorial policy
