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 →If you're still planning your move from VCF 5 to VCF 9, you now have a fixed date to plan around: Broadcom's KB 456708 sets 11 October 2027 as the end of service for ESXi and vCenter 8.x, vSAN 8.x, NSX 4.x, VCF 5.2.x, Aria 8.18.x and HCX 4.x.
Security is unchanged today but still needs your attention, because vCenter CVE-2026-59310 from VMSA-2026-0006 is in CISA's Known Exploited Vulnerabilities catalogue with known ransomware use.
Elsewhere, Broadcom signed a 10-year VCF deal with NTT DOCOMO, and today's deep dive walks through how express patches work in VCF 9.1.
This is an earlier briefing. Read today's Latest Tech News →
Nothing new from Broadcom today. The newest advisory on its Security Advisory portal is still VMSA-2026-0007 from 3 September, but three older advisories have CVEs in CISA's Known Exploited Vulnerabilities catalogue, so they're worth another look if they're not already closed out in your estate.
This one is for desktop hypervisors: Workstation and Fusion 25H2 and 26H1, CVSSv3 8.1 to 9.3. Both CVEs need local admin rights inside a guest, neither is in CISA KEV, and 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, it's worth doing 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 and lists known ransomware use. The Broadcom advisory itself says the issues were privately reported and makes no statement on exploitation; the other four CVEs aren't in KEV. Broadcom notes that patches are cumulative and that vCenter 9.1.0.0200 was the first release to fix CVE-2026-59309. First published 29 Jul 2026.
DoPatch vCenter to 9.1.0.0300, 9.0.2.0100 or 8.0 U3k / U2f (on VCF 5.x use the async patch in KB 88287; on 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. If a vCenter has been reachable and unpatched, it's safest to treat it as possibly compromised.
Affects Aria Operations and VCF Operations, CVSSv3 6.2 to 8.1. CVE-2026-22719, a command injection, has been in CISA KEV since 3 Mar 2026. Broadcom says it "is aware of reports of potential exploitation" but "cannot independently confirm their validity". First published 24 Feb 2026.
DoMove VCF Operations 9.x to 9.0.2.0 or later, and Aria Operations 8.x (including on VCF 4.x/5.x) to 8.18.6; Telco Cloud customers should follow KB 428241. If you can't patch straight away, KB 430349 has a workaround for CVE-2026-22719.
Affects Aria Operations and VMware Tools, CVSSv3 4.9 to 7.8. CVE-2025-41244, a local privilege escalation, has been in CISA KEV since 30 Oct 2025, and here Broadcom goes further, saying it "has information to suggest that suspected exploitation of CVE-2025-41244 has occurred in the wild". First published 29 Sep 2025.
DoUpdate VMware Tools to 13.0.5 or 12.5.4, VCF Operations 9.x to 9.0.1.0 or later, and Aria Operations 8.x to 8.18.5 (for 4.x/5.x under VCF, see KB 92148). There's no workaround, so patching is the only fix.
All VMware security advisories on Broadcom's support portal →
upgrade_status PAUSED with a null target_version, and resuming in NSX fails with a NullPointerException in upgrade-coordinator.log. The cause is an older NSX upgrade that was never marked complete. To clear it, upload the NSX 9.1.1 MUB to /image on one NSX Manager and upgrade the upgrade coordinator via the API; then, after snapshotting SDDC Manager, PATCH the domain's releases with targetVersion 9.1.1.0 and PARTIALLY_UPGRADED_NSXTCLUSTER_VALIDATOR in skipValidations. Checking NSX upgrade history on imported domains before you plan 9.1.1 will save you the surprise. A quiet day for release notes. Nothing new has landed for VCF, vSphere, NSX or vSAN since the 9.1.1 patch batch on 12 October, so the builds in the side panel are still current.
25784021) and vSAN OSA Witness 9.1.1.0100 (build 25783993). The notes only mention "various security enhancements" and list no known issues. Nothing new from the providers or Packer plugins today. The vcf provider README still lists VCF 9.1.1 support from v0.19.0, which shipped on 7 Oct and is still the latest on GitHub. You'll find every current version and the full support table in the side panel.
vcfa_vks_cluster can now change cluster_class.name in place (a ClusterClass rebase), so you can upgrade cluster_class and version in a single apply (#258). Changing cluster_class.namespace still forces a replacement. It also fixes a ModifyPlan panic (#255) and perpetual drift on os_image.version (#257). Since VCF 9.1, Broadcom has shipped security-focused patches between maintenance releases, roughly once a month, and calls them express patches. You'll spot them in the fourth group of the version number: 9.1.0.0100, 0200 and 0300 on the 9.1.0 line, then 9.1.1.0100 and 0200 on 12 October. TechDocs draws a helpful line here. An upgrade is a major or minor change (9.0 to 9.1) and needs a strict order. A patch is a maintenance (9.1.0 to 9.1.1) or patch-level (0200 to 0300) change and "does not require a strict patch order" unless the release notes say otherwise. Patches are cumulative, so you can jump straight to the newest one for a component.
The thing that catches people out is that not every component gets every patch. On 9.1.0, the 0100 drop touched ESX, vCenter, vSAN, NSX, SDDC Manager, VCF Operations and VCF Automation, but 0200 and 0300 only touched SDDC Manager and VCF Operations. The 12 October set is mixed again: SDDC Manager and VCF Automation went to 9.1.1.0200, while vCenter, ESX, NSX and vSAN went to 9.1.1.0100. In other words, there's no single "VCF 9.1.1.0200" bill of materials. Track versions per component instead: VCF Operations shows "On Target" or "Version Drift" on its Component Versions tab, and security advisories name component builds rather than VCF versions.
Day to day, patching runs from VCF Operations. Management components (VCF Operations, Fleet Lifecycle, VCF Automation and the management services) go through Build > Lifecycle > VCF Management > Upgrade > Change target version > Customize, where you pick a per-component target, run prechecks and upgrade. Core components (SDDC Manager, vCenter, ESX and NSX) are patched per domain under VCF Instances > Upgrades > Plan Component Upgrade. Only one patch operation can run at a time, the patch planner won't open while another upgrade plan exists, and you need the core-component binaries downloaded first, either from the online depot or with the VCF Download Tool.
For 9.1.1, order still matters in a few places. Patch the Fleet Lifecycle component first, and never patch VCF Operations in parallel with anything else. Patch VCF Operations and its license servers before ESX moves from 9.1.0.x to 9.1.1.0. Patch the services runtime before its identity broker or Salt RaaS, and VCF Automation before the migration service engine. A depot patch blocks everything else until it finishes, and patching VCF Operations also patches the license server and cloud proxy for you.
The real payoff is less downtime. vCenter quick patches restart only what the payload touches: vlcm, vsphere-ui and eam with no downtime at all, envoy and the licence service in up to 180 seconds, and vpxd, vmca, lookupsvc or vmon in about three to five minutes. ESX live patches install host by host on image-managed clusters without a reboot; Broadcom's 9.1 webinar Q&A describes hosts going into partial maintenance mode while their VMs keep running. Anything that needs a reboot, a driver change or full maintenance mode rules out live remediation, and VMs that can't fast-suspend-resume still need migrating or a power cycle.
A few gotchas to finish. In production, read each advisory's response matrix against your component builds: VMSA-2026-0006, for example, names vCenter 9.1.0.0300 as the fixed build and notes that 9.1.0.0200 was the first with the CVE-2026-59309 fix. On Supervisor estates, run the KB 455737 VUM schema check before any vCenter patch or upgrade. If you're still on 9.0, William Lam's answer to a reader is that applying a 9.0 express patch before moving to 9.1 can run into back-in-time issues depending on when you do it, so check the VCF Upgrade Planner first. In labs, remember live patching needs DRS, an image-managed cluster and hosts without TPM devices; if any of those is missing, plan for ordinary maintenance mode. And keep NTP tidy, because the 9.1.1 vCenter precheck already fails on non-UTC time zones.
A quiet week on the Broadcom Community forums, with only one VCF thread active in the last seven days. As always, treat forum posts as unverified reports.
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.