VMSA-2026-0008.1 — Apply KB 460732 on 9.1.1 or KB 460734 on 9.0.x, 9.1.0 and 5.2.x, restrict SDDC Manager to trusted admin hosts, and subscribe to the advisory for the patch.
Details →If you run Supervisor clusters, the quiet news of the week is VKS 3.8.0, released on 22 October. It adds vSphere Kubernetes Release 1.37, lets workload clusters jump up to three minor versions in one chained upgrade, and brings audit logging, file integrity monitoring and an immutable Photon OS image. It also retires some older ClusterClasses and legacy add-on resources, so read the upgrade notes before you click anything.
There's no new VMSA this weekend, and vCenter CVE-2026-59310 is still the one to patch first.
There's also some good news hiding in the Supervisor release notes: Supervisor 9.1.1.0100, released on 12 October, already fixes the missing control plane VMs problem in KB 457944, even though the KB itself still calls the fix pending.
Otherwise it's a calm Sunday: no new VCF patches since 12 October, no new Broadcom KBs worth flagging, and nothing new from the Terraform providers, though govmomi has a small 0.56.1 update. The deep dive looks at how password management really works in VCF 9.1, and why the SDDC Manager service-account lock in KB 459311 is a good reminder to let the platform own its own credentials.
This is an earlier briefing. Read today's Latest Tech News →
No new VMSA this weekend, so these are the four most recently released or updated advisories; Broadcom's advisory portal has the rest. vCenter CVE-2026-59310 (VMSA-2026-0006) is still the one to patch first. On PHP2Shell, Broadcom's statements for VCF (KB 459989), vDefend (KB 460110) and Avi (KB 460068) are unchanged: not affected. None of them yet mentions the newer, unpatched PHP flaw CVE-2026-115560.
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 also describes code execution for CVE-2026-47870). The advisory makes no statement on exploitation. First published 14 Jul 2026; revision .1 on 7 Aug added a 22.1.7-2p12 patch.
DoUpgrade 32.1.x to 32.1.2 or later (the advisory's recommended fix), 31.1.1–31.2.2 to 31.2.2-2p3, and 30.1.1–30.2.6 to 30.2.7. On 22.1.x, 22.1.7-2p12 fixes CVE-2026-47865, but the matrix lists 30.2.7 for the other six CVEs, so plan the move to 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).
All VMware security advisories on Broadcom's support portal →
No new VMware KBs worth flagging since yesterday, and the ones we're tracking haven't moved. KB 457944 (Supervisor control plane VMs missing after a 9.1 upgrade) still says the fix is "in the next release of VCF 9.1.1", although the Supervisor 9.1.1.0100 release notes already list it as resolved (see Corrections). KB 458671 (NSX Manager hanging on startup) and KB 452660 (SCRX after an NSX upgrade) still name no fix version, and KB 456305 (VCF Operations certificate alerts) still says a fix is planned for an upcoming release.
No new VCF patches: the 9.1 release notes index still shows 12 October as the newest batch of 9.1.1.x patches, with no 9.1.2 or 9.2 line. The one release worth your time is VKS.
vcf package is deprecated in favour of vcf addon, and control-plane zone selection needs Supervisor 9.1.1.0100 or later. There are 13 known issues, including add-on manager memory limits at large scale and Windows-node quirks. Nothing new from the providers or Packer plugins. The vcf provider README still lists VCF 9.1.1 support from v0.19.0 (7 Oct), and the v0.19.0 release is still the latest. Two things in the repos are worth watching: the nsxt provider has been working through pull requests for VPC load balancer resources and data sources (PR #2373, PR #2377), which points to them arriving in a future nsxt release, and the vsphere provider has an open PR to make vsphere_namespace more stable (PR #2788).
VCF.PowerCLI 9.1.1.25718932 (10 Sep) and pyVmomi 9.1.1.0 (3 Sep) are still current, and vmware.vmware is still at 2.12.0.
Password management in VCF 9.1 is split across two tools, and most of the pain comes from not knowing which one owns a given account. Broadcom's guidance is that VCF Operations is now the preferred place to manage passwords: it covers local, application and service accounts on VCF 5.2 and later, plus standalone vCenter and ESX 8.0 Update 3 and later, and it doesn't keep its own copy of passwords in a vault. SDDC Manager still manages credentials for the core components, but TechDocs says it "will be deprecated in a future VCF release" and that using it for passwords "is not advised" unless your environment needs it.
In practice that means two worlds. The vCenter, ESX, NSX and SDDC Manager root and admin accounts are rotated by SDDC Manager, which can rotate (generate a new password and apply it everywhere), remediate (tell SDDC Manager about a password that was changed directly on the component) and auto-rotate on a schedule. Broadcom's design recommendations say auto-rotation is limited to a 30, 60 or 90-day cycle. KB 435599 adds that some fleet components (Fleet Management, VCF Operations and its logs and networks appliances, and the identity broker) may currently sit outside that automated rotation engine and need managing by hand, so watch their expiry through VCF Operations.
VCF Operations works on policies rather than vaulted secrets. A policy sets length, complexity, expiry, lockout and history, and can apply to the whole fleet, the management components or a single instance, with the narrower one winning. The catch is that expiry is counted from the last password change: apply a 90-day policy to an account last changed 120 days ago and it expires the moment the policy lands. Complexity rules also don't touch existing passwords, which is why Broadcom recommends changing passwords straight after a policy goes live. Policy tasks depend on Salt, so give a fresh management deployment about 30 minutes before you push one.
The gotchas in production are mostly about stepping round the platform. Broadcom is explicit that you shouldn't change the passwords or permissions of the inter-component service accounts on the components themselves, because that breaks the integrations; KB 459311 from earlier this week, where stale lock entries in SDDC Manager kept an NSX service account locked, shows how fiddly that plumbing can be. There's no "never expire" option for core components, and using chage or passwd on the appliances to get round it creates drift that SDDC Manager or lifecycle operations will trip over. Cosmin Trif's write-up on expired accounts in Fleet password management adds a useful rule: VCF 9.1 has no "store a password I already changed" button, so if someone changed one by hand you supply that as the current password and rotate once more through the UI or API.
In a nested lab the temptation is to turn expiry off altogether, and that's exactly what bites you when you come back to a lab after three months and find root expired on half the appliances. A better habit is to turn on SDDC Manager auto-rotation for the core accounts, keep the VCF Operations password alerts switched on, and when something has expired, reset it from the console to a temporary value and immediately rotate it through VCF Operations or the SDDC Manager credentials API so the platform knows the final password. If you script any of this, watch for passwords containing !, which some shells will happily expand.
No new exam or course announcements this week. The newest post in the VCF blog's certification and learning section is still the new VCAP and VCDX certifications for VCF (31 Aug).
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.