Broadcom Shipped Two 9.8s in vCenter With No Workaround. The Bug That Should Worry You Scores 2.7.

Broadcom published VMSA-2026-0006 on 29 July: five vulnerabilities across VMware ESX, vCenter, Workstation and Fusion, scoring from 9.8 down to 2.7. Two of the criticals have no workaround, which means the patch is the only move available.

Everyone will lead with the 9.8s, correctly. We are going to spend most of this post on the 2.7, because of what it does to the other four.

The four you will read about elsewhere

CVE-2026-59309 — 9.8. Authentication bypass in the VMware Directory Service. vCenter is the control plane for the estate; an authentication bypass there is not a server compromise, it is administrative access to everything vCenter manages.

CVE-2026-59310 — 9.8. Directory traversal. Also vCenter. Also no workaround.

CVE-2026-47876 — 9.3. VM escape via the VMXNET3 virtual network adapter. An attacker with administrator privileges inside a guest executes arbitrary code on the underlying ESXi host. This is the one that breaks the promise the hypervisor exists to make: that the boundary between a tenant's VM and the host holds. If you run untrusted or semi-trusted workloads, or you sell VMs to anyone, this is your emergency.

CVE-2026-41703 — 7.6. Out-of-bounds read. Serious, unglamorous, patch it.

That is a straightforwardly bad advisory. Two unworkaroundable criticals in the control plane plus a guest-to-host escape is close to a worst-case set for a virtualisation stack.

The 2.7

CVE-2026-41709 — insufficient logging in ESXi. A malicious administrator can perform certain operations without those actions being properly recorded in logs.

CVSS scores impact to confidentiality, integrity and availability. A logging gap directly damages none of the three. So it scores 2.7, lands at the very bottom of the advisory, and will be deferred by every triage process that sorts by severity — defensibly, because that is precisely what sorting by severity is designed to do.

Now put it next to the other four.

CVE-2026-59309 gives an attacker administrative access to vCenter. CVE-2026-47876 gives an attacker inside a VM code execution on the host. CVE-2026-41709 means certain things done with administrative access on ESXi leave no record.

The 9.8 is how they get the privileges. The 2.7 is why you never find out what they did with them.

This has a name in our notes

We track this as the subtraction attack: a technique that wins by removing the artifact a defence assumes will exist, rather than by adding anything detectable. Every detection strategy has a load-bearing assumption underneath it, and the strongest attacks target the assumption instead of the control.

Your entire post-incident capability rests on one assumption: that privileged actions produce records. Forensics, threat hunting, compliance attestations, breach-notification scoping, insurance claims — all of it assumes the log is a faithful account of what happened. A vulnerability that quietly falsifies that assumption is not a 2.7 to your investigation. It is the difference between an incident you can scope and an incident you can only speculate about.

And unlike an attacker clearing logs after the fact — noisy, detectable, a known hunt — this is the platform declining to write them in the first place. There is no gap in the timeline to notice. There is no deletion event. The record simply never existed, and it looks exactly like a quiet day.

The pattern, for the fourth time this week

We keep arriving here, and it is starting to feel less like a coincidence and more like the actual state of vulnerability management.

Tuesday: three medium-severity Artifactory bugs, none critical, chained into a containment breach at a frontier AI lab.

Wednesday: a 10.0 in Arista VeloCloud alongside a 5.3 in FortiOS, where the 5.3 was a bypass of the patch meant to evict an attacker already inside.

Wednesday night: Cisco FMC, a static password scoring 5.3, which Cisco themselves publicly relabelled to High severity in the advisory text — because, they wrote, it can be chained with other FMC vulnerabilities to elevate privileges.

Today: a 2.7 that makes a 9.8 unauditable.

Severity scores rank vulnerabilities in isolation. They cannot see the rest of the machine, they cannot see what else is on the box, and they cannot price the destruction of your ability to investigate. Cisco said the quiet part out loud this week by overriding their own number. Broadcom's advisory does not, so we will: the ordering in VMSA-2026-0006 is not the ordering of your risk.

What to do tonight

Patch. There are no workarounds for the two vCenter criticals, so there is no clever mitigation to buy time with — the sequence is vCenter first because it is the control plane, then ESXi for the escape, then everything else.

While you are in there, treat the logging bug as a forensics question rather than a patching one. If you have had any ESXi incident, anomaly or unexplained administrative action in the window this vulnerability has existed, your logs from that period are not the authority you assumed they were. That does not mean something happened. It means the absence of evidence in those logs is no longer evidence of absence, and any conclusion you drew from a clean ESXi log deserves a second look.

Then ask the general version of the question, because it outlives this advisory: for each of your critical platforms, what would an attacker have to break for your logs to stop being a faithful record — and would you notice?

Confidence capped at 95%. CVE identifiers, scores and the no-workaround status are from Broadcom's VMSA-2026-0006; the argument about the 2.7's real weight is ours and is offered as an argument.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.