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 →Broadcom has widened its PHP2Shell all-clear. KB 460110 says vDefend isn't affected and points to IDS/IPS signatures that can virtually patch your PHP workloads, and KB 460068 does the same for Avi with a set of WAF rules. Neither replaces the PHP patch, but both buy useful time for VMs you can't update straight away.
There's no new VMSA this weekend, and vCenter CVE-2026-59310 is still the one to patch first.
Otherwise it's quiet: no new VCF patches since 12 October and nothing new from the Terraform providers. Two NSX 9.1.1 KBs are worth reading before your next maintenance window, Virtually Speaking has a new episode on planning a VCF upgrade, and the deep dive looks at choosing and protecting key providers for encryption in VCF.
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 says VCF (KB 459989), vDefend (KB 460110) and Avi (KB 460068) aren't affected.
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 (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. 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 →
Two are Broadcom's latest word on PHP2Shell, and two are NSX 9.1.1 issues you'd rather know about before a restart than after.
A quiet weekend for release notes. 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. Avi Load Balancer 32.1.4 is still the newest 32.1 release, vCenter 8.0 U3k the newest 8.0 patch, and VMware Tools 13.1.5.0 (build 25544008, 3 Sep) the newest Tools release, with OpenSSL 3.5.7 and a Secure Boot PK update driver for Windows VMs.
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 releases still show it as Latest. Remember that 0.19.0 changed vcf_instance so it can no longer bring up VCF 9.0.0 and earlier (PR #445), so pin older versions for 9.0 labs. vsphere 2.17.1, vcfa 1.2.3 and the vsphere 2.5.0 and vmware 2.1.6 Packer plugins are unchanged; the full table is in the side panel.
Nothing to update. VCF.PowerCLI 9.1.1.25718932 (10 Sep) is still current, govmomi v0.56.0 is still marked Latest, and pyVmomi 9.1.1.0 (3 Sep) is the newest on PyPI.
Every encryption feature you might switch on in VCF (vSAN data-at-rest encryption, VM encryption and virtual TPMs) depends on a key provider configured on vCenter, and the choice you make there decides what happens on the worst day: a full power-off and restart. There are two kinds. A Standard Key Provider talks KMIP to an external key server; a vSphere Native Key Provider is built into vCenter, generates a Key Derivation Key and pushes it to every host in the cluster, with no external server at all. Broadcom's own guidance is that you can mix them, for example a Standard Key Provider for vSAN and the Native Key Provider for virtual TPMs, and a vCenter can hold up to 32 providers.
With a Standard Key Provider, hosts cache keys in memory and lose them on reboot. vSAN hosts contact the key server directly, so their disks won't mount until it's reachable, and VMs with VM encryption or a vTPM won't start until vCenter and the key server are both up. That's why the VCF blog's first two rules are to run more than one key server and keep them away from shared failures, and why the classic trap is a key server VM sitting on the very encrypted datastore it unlocks. Watch for drift too: a Storage vMotion can quietly move a key server onto an encrypted datastore. KMIP uses TCP 5696, and with vSAN encryption every vSAN host needs to reach it, not just vCenter.
The Native Key Provider is quicker to stand up but comes with its own rules. TechDocs is blunt that "You must back up a vSphere Native Key Provider", and a new provider can't be used until you do; vCenter alarms every 24 hours until then. That backup, and every vCenter file-based backup, contains the key, so encrypt your vCenter backups and store the NKP backup and its password somewhere you can reach when vCenter is down. NKP has no KMIP or HSM support, so anything outside VMware that needs keys still needs a real key server. It doesn't need a TPM, but if you use one it must be TPM 2.0, and the "Use key provider only with TPM protected ESX hosts" option is on by default: turn it off unless every host has a TPM, or hosts without one simply won't get the key.
A few gotchas catch people in production. Key providers can't be renamed, so pick names carefully and use the same name everywhere a provider is shared. vCenter will let you delete a provider that's still in use; running VMs carry on but won't power on again until it's restored, so rekey first. Providers belong to individual vCenter instances, so for cross-vCenter vMotion or disaster recovery the same provider (or an NKP restored from backup) must exist on the target. Rotation is a shallow rekey for most compliance needs; a deep rekey rewrites data, needs the VM off with no snapshots, and adds flash wear. Key Persistence keeps keys across reboots on TPM 2.0 hosts, but it's off by default because a stolen host could then unlock its own data.
For nested labs the Native Key Provider is the obvious choice: no extra appliance, and nested hosts without a TPM work fine as long as you untick the TPM-only option. Do the backup straight away, because rebuilding a lab vCenter without it leaves encrypted VMs unreadable. Community advice also warns against stacking VM encryption on top of encrypted vSAN, which adds CPU overhead because data is encrypted twice and makes deduplication of those VMs close to useless. Finally, use the lab for what Broadcom recommends testing anyway: restore an NKP backup, power the whole cluster off and on with key servers starting as they would in a real outage, and take one key server away to see what keeps running.
No new exam or course announcements this week. The most recent official news is still the new VCAP and VCDX certifications for VCF (31 Aug) and the next generation of Hands-on Labs (21 Sep).
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.
