VMSA-2026-0008.1 — Apply KB 460732 on 9.1.1 or KB 460734 on 5.2.x, 9.0.x and 9.1.0, keep SDDC Manager reachable only from trusted admin hosts, and subscribe to the advisory so you see the patch the day it lands.
Details →The story to read first today isn't a VMware bug, but it lands squarely on your platform. Palo Alto's Unit 42 says attackers exploiting the GlobalProtect flaw CVE-2026-0257 moved from the VPN gateway to the vCenter appliance, disabled execInstalledOnly on ESXi hosts, and dumped credentials straight from a domain controller's virtual disk, bypassing in-guest EDR. If your VPN and vCenter sit close together, it's a good day to check that path.
On VMware advisories there's nothing new from Broadcom, but our count was short. Broadcom's advisory pages also show VMSA-2026-0004 (VCF Operations), VMSA-2026-0002 (Workstation and Fusion) and VMSA-2025-0004 (ESXi, with exploitation in the wild stated by Broadcom) as Open, so eight are listed below. vCenter CVE-2026-59310 from VMSA-2026-0006 is still the one to patch first.
Elsewhere, Broadcom has introduced KubeVM Service for declarative, Kubernetes-style VM management, renewed its infrastructure software agreement with FedEx, and William Lam's VCF upgrade planner can now plan Supervisor and VKS upgrades. The deep dive looks at backing up and restoring the Supervisor control plane in VCF 9.1, which is also the recovery route for KB 457944.
This is an earlier briefing. Read today's Latest Tech News →
execInstalledOnly on ESXi, so restrict vCenter and ESXi management to jump hosts and alert on changes to that setting. v1alpha1. execInstalledOnly switched off, and credentials dumped from a domain controller's VMDK. iv for DataScript crypto calls and required SNMPv3 passphrases: check DataScripts and API clients before upgrading. No new VMSA today; the newest is still VMSA-2026-0007 from 3 September. Broadcom's portal shows Open on advisories going back into 2025, so this list covers every 2026 advisory marked Open plus older ones where Broadcom or CISA's KEV catalogue confirms exploitation; VMSA-2026-0003 (Fusion, fixed in 26H1) carries no status on its page. No Broadcom statement has appeared on this week's NGINX, Apache Tomcat or Node.js fixes, and KB 459989 still says VCF components don't use PHP and aren't affected by PHP2Shell. Separately, Unit 42 reports attackers pivoting from GlobalProtect (CVE-2026-0257) to vCenter and disabling ESXi execInstalledOnly [Press].
For desktop hypervisors: Workstation and Fusion 25H2 and 26H1, CVSSv3 8.1 to 9.3. Both CVEs need local admin rights inside a guest and can lead to code execution on the host; the advisory makes no statement on exploitation. First published 3 Sep 2026.
DoUpdate Workstation and Fusion to 26H1u1. There's no workaround, so if you run nested labs on a laptop, do it soon.
This is the one to prioritise. It covers vCenter, ESX, Workstation and Fusion (and so VCF, VVF and Telco Cloud), with CVSSv3 scores from 2.7 to 9.8 and no workarounds. CISA added CVE-2026-59310, a vCenter Syslog directory traversal, to its KEV catalogue on 18 Aug 2026 with known ransomware use; the Broadcom advisory itself makes no statement on exploitation. First published 29 Jul 2026.
DoPatch vCenter to 9.1.0.0300, 9.0.2.0100 or 8.0 U3k / U2f (VCF 5.x: async patch per KB 88287; 7.0 extended-support customers should contact Broadcom). For ESX, apply ESXi-9.1.0.0200-25557999, ESXi-9.0.2.0100-25595025, ESXi80U3k-25595708 or ESXi80U2f-25626445. A vCenter that has been reachable and unpatched is safest treated as possibly compromised.
If you run Avi Load Balancer (including for VKS or VCF Automation), this one matters. Seven CVEs, CVSSv3 7.1 to 9.8, no workarounds. The worst, CVE-2026-47865, is an authentication bypass on the Avi control plane, and two others allow remote code execution. The advisory makes no statement on exploitation. First published 14 Jul 2026.
DoUpgrade 32.1.x to 32.1.2 or later (32.1.4 is current), 31.1.1–31.2.2 to 31.2.2-2p3, and 30.1.1–30.2.6 to 30.2.7; 22.1.x needs at least 30.2.7.
Three stored cross-site scripting flaws in VCF Operations and Aria Operations, each CVSSv3 8.0. Someone with rights to create policies, views or text widgets could plant scripts that perform administrative actions. No workarounds, and no statement on exploitation. First published 8 Jun 2026.
DoVCF Operations 9.1.x is fixed from 9.1.0.0 and 9.0.x needs 9.0.2.0 EP2. Aria Operations 8.x and Aria Operations under VCF 5.x need 8.18.7 to fix all three (Telco Cloud Platform: KB 443138).
Showing the 4 most recently published or updated. All VMware security advisories on Broadcom's support portal →
Neither is new drama, but both turn a vague precheck failure into a quick fix.
A quiet end to the week for VCF release notes. The 9.1 release notes index still shows 12 October as the newest patch batch, with no sign of a 9.1.2 or 9.2 line, and the Async Releases page hasn't changed. Outside VCF, Avi Load Balancer 32.1.4 (13 Oct) is still the newest 32.1 release, vCenter 8.0 U3k is still the newest 8.0 patch, and VCF 5.2.4 the newest 5.2 release.
Nothing new from the providers or Packer plugins this week. The vcf provider README still lists VCF 9.1.1 support from v0.19.0, which shipped on 7 Oct and is still marked Latest on GitHub, and the repository still has a single open issue. vsphere 2.17.1, vcfa 1.2.3 and the vsphere 2.5.0 and vmware 2.1.6 Packer plugins are all unchanged. Every current version and the full support table are in the side panel.
Nothing to update. VCF.PowerCLI 9.1.1.25718932 (10 Sep) is still the current version on the PowerShell Gallery, govmomi v0.56.0 (21 Aug) is still the latest release, and the Ansible vmware.vmware 2.12.0 tag from 12 Oct is still the newest.
If you run Supervisors, KB 457944 is a good reason to look at this now. Its recovery steps for missing Supervisor control plane VMs include "Restore the Supervisor Cluster from a Supervisor backup", which only works if that backup exists. The good news is that it isn't a separate product or appliance; it's a checkbox most people haven't ticked.
In VCF 9.1, Supervisor control plane backup rides on the vCenter file-based backup. In the VAMI on port 5480, you edit (or create) the backup schedule and select "Supervisors Control Plane". TechDocs puts it simply: "The state of all Supervisors in vCenter is backed up as part of the vCenter backups." The target is the same FTP, FTPS, HTTP, HTTPS, SFTP, NFS or SMB server you already use for vCenter, and the option covers every Supervisor that vCenter manages, not individual ones.
What goes into it is the Supervisor's own state: etcd, the infrastructure pod container images (so the control plane can be rebuilt even after a vCenter upgrade), the Kubernetes CA certificate and key, every vSphere Namespace and the Kubernetes resources behind workloads, such as deployments, pods, VMs, VKS resources and persistent volume claims. Keeping the same CA matters, because vSphere Pods and the Spherelet don't have to be taught to trust a new one.
Plenty of Supervisor configuration lives in vCenter instead, and comes back with a vCenter restore rather than a Supervisor one: namespace resource pools, control plane VM settings, VKS content libraries, network settings, storage policies, certificates, registries, identity providers, permissions and vSphere Zones. The two restores are separate workflows, and TechDocs is explicit that restoring vCenter does not restore the Supervisor control plane.
The restore itself starts from Supervisor Management > Supervisors > Restore in the vSphere Client. You point it at the backup server (or reuse the vCenter schedule's location and credentials), pick a backup file and the Supervisor, and finish the wizard. The Supervisor goes into Configuring, its control plane VMs are deleted and redeployed from the backup, and you follow progress from the Config Status column.
Rutger Blom tested this end to end in a 9.1 lab, and his numbers are useful for planning. A manual backup took about 15 minutes and roughly 4.4 GB, and the restore task took about 43 minutes, with reconciliation carrying on afterwards. vCenter deployed three new control plane VMs; the VKS node VMs were left alone, and kubectl worked against the guest cluster afterwards.
The gotchas are where it gets interesting. A namespace deleted after the recovery point isn't recreated by a Supervisor restore (TechDocs says you need the vCenter state for that), and in Rutger's test a node volume added after the backup was rolled back. In one test a VKS cluster came back with only link-local IPv6 addresses on its nodes and an unreachable API, which he couldn't pin on the restore or his lab. The restore also replaces all three control plane VMs with no undo, so it's for lost or corrupted control plane state, not a fix for a failed upgrade.
The biggest one: workload data isn't in the backup. Persistent data inside VKS clusters, vSphere Pods and data in VM Service VMs need their own protection, and TechDocs points to Velero and the Velero Plugin for vSphere for that. Rutger's view is blunt: "I would not start a planned Supervisor restore without reliable, tested backups."
For production, a few rules follow. Don't take backups while the Supervisor or a Supervisor Service is in error, or during an upgrade, because a backup can complete and still not be restorable. If vCenter may also need restoring, keep the installer for your exact vCenter build, since Rutger notes the VCSA installer and backup must match. Restore vCenter first when you need both, and Supervisors below vSphere 8 Update 3 aren't included at all.
In a nested lab this is cheap to try and worth doing once before you need it. An SFTP target on a small Linux VM is enough, a daily job with a week's retention mirrors Broadcom's recommendation for vCenter and SDDC Manager, and running a restore on a throwaway namespace will show you how long your Supervisor is out of action. After a restore, check the API, the expected namespaces, node addresses, load balancer VIPs and DNS before you call it done; as Rutger puts it, "A completed vCenter task is only the first checkpoint."
v1alpha1 API, so treat it as early. execInstalledOnly on ESXi hosts, and used a custom tool to dump credentials offline from a domain controller's VMDK, bypassing in-guest EDR. Patch the firewalls, but also check who can reach vCenter from the VPN pool and whether execInstalledOnly is still enforced on your hosts. Tags: Official Broadcom and VMware sources, Press trade press, Community community posts and unverified reports.
Questions, ideas, or just want to talk VCF? Drop me an email or find me on the socials.