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 biggest story today is PHP2Shell. The PHP project disclosed two critical flaws, CVE-2026-109618 and CVE-2026-109619, on 21 October, and Broadcom has answered the question every VCF admin is asking in KB 459989: "VMware Cloud Foundation components do not use PHP and are not affected." That's good news for vCenter, SDDC Manager, NSX and the rest of the stack, but it doesn't cover the PHP applications, jump boxes and tooling running on your VMs, and exploitation attempts are already being reported.
On VMware advisories, there's nothing new from Broadcom, but vCenter CVE-2026-59310 from VMSA-2026-0006 remains in CISA's Known Exploited Vulnerabilities catalogue with known ransomware use, so an unpatched vCenter is still the first job of the day. We've also added VMSA-2026-0005, a critical Avi Load Balancer advisory from 14 July that is still open and was missing from earlier briefings.
Elsewhere, Avi Load Balancer 32.1.4 tightens several defaults that could break DataScripts and API clients on upgrade, the SDDC Manager 9.1.1.0200 notes list a Binary Management quirk with large depots, and today's deep dive looks at what vSAN ESA storage policies really do in 9.1.
This is an earlier briefing. Read today's Latest Tech News →
avi.crypto.encrypt and avi.crypto.decrypt need the iv parameter (upgrades fail if DataScripts use the two-argument form), and SNMPv3 passphrases are now mandatory. Check your DataScripts and API clients first. On the VCF side, KB 457944 still has no fixed build, so keep running the KB 455737 check before vCenter upgrades on Supervisor estates. No new VMSA today; the newest is still VMSA-2026-0007 from 3 September. The PHP2Shell flaws (CVE-2026-109618 and CVE-2026-109619) don't need a VMware advisory: Broadcom's KB 459989 states that VCF components do not use PHP and are not affected. VMSA-2026-0005 for Avi Load Balancer is also still open and is now listed below. Three advisories have CVEs in CISA's Known Exploited Vulnerabilities catalogue, so they deserve another look if they aren't 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 makes no statement on exploitation, and the other four CVEs aren't in KEV. Patches are cumulative, and 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.
If you run Avi Load Balancer (including as the load balancer for VKS or VCF Automation), this one matters. Seven CVEs, CVSSv3 7.1 to 9.8, with no workarounds. The worst, CVE-2026-47865, lets a network attacker bypass authentication to 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. There are no workarounds.
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 them. 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.
Showing the 4 most recently published or updated. All VMware security advisories on Broadcom's support portal →
KB 459989 is the one to read today. The other two won't block an upgrade, but they can waste an afternoon if you don't know about them.
Another quiet day 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. One release from outside the core stack is worth catching up on.
avi.crypto.encrypt and avi.crypto.decrypt require the iv parameter and upgrades fail if DataScripts use the two-argument form, SNMPv3 no longer falls back to a default passphrase, and backups default to a Bundle archive instead of JSON. On the plus side, it adds WAAP/API protection, the AI Assistant and TLS session key forwarding. It also includes the fixes from VMSA-2026-0005, which was resolved for the 32.1 line in 32.1.2. 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 marked Latest on GitHub, and the repository has a single open issue. Every current version and the full support table are in the side panel.
vcfa_vks_cluster can now change cluster_class.name in place, so you can move cluster_class and version together in one apply; changing cluster_class.namespace still forces a replacement. Nothing to update today. 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, with mostly fixes such as vm_info warning rather than failing when a VM disappears mid-run.
If you've opened the Storage Rules tab on a vSAN storage policy, you've probably read it as a set of per-VM switches: encryption on or off, compression on or off. That's a reasonable reading of the UI, but it isn't how it works. As Duncan Epping lays out in his 2026 update on the subject, Storage Rules mostly act as filters. They decide which vSAN datastores show up as compatible for the policy, based on what each cluster has switched on, rather than turning those services on or off for an individual VM.
The reason is that space efficiency and encryption are cluster services in vSAN ESA. TechDocs describes the ESA write path as inline compression followed by encryption, with deduplication running as an offline background process, and encryption always applied last so the data on the devices is encrypted. VCF 9.1 adds ESA Global Deduplication, which the release notes call "a cluster-wide and post-processing setting with encryption support", alongside improved ESA compression and Auto RAID-6 as the default layout. None of those are per-VM choices: you set them on the cluster, and policies then steer VMs to clusters that match.
There's one change between releases that's easy to trip over. On ESA before 9.1, the "No data reduction" rule actually disabled compression for every object using that policy. From vSAN 9.1 it behaves like the others and only matches datastores where compression is already off. So a policy you built on an earlier release to exempt, say, already-compressed database volumes no longer does that after the upgrade; it simply makes those VMs non-compliant on a cluster that compresses. The "require encryption" and "no encryption" rules work the same way, limiting which datastores match rather than encrypting anything.
In production, the practical upshot is to design for it at the cluster level. If a workload genuinely needs different efficiency or encryption settings, it needs a cluster with those settings, and the policy is how you make sure it lands there. Encryption needs either an external KMS or a vSphere Native Key Provider, vCenter only holds key IDs, and you can rotate keys if one is compromised. Before upgrading to 9.1, check any policy that uses "No data reduction" and decide whether you still need it, and remember that with Auto-RAID enabled on a policy, not every Storage Rules option is shown until you turn it off.
In a nested lab this matters mostly when you're testing space savings. If you want to compare compressed and uncompressed results, change the cluster's setting (or build a second small cluster) rather than relying on a policy, and give global deduplication time to run, since it's a background process and won't show savings straight after a copy. And if you're testing encryption, a Native Key Provider is the lightest way to do it without standing up a KMS.
No new posts from the regular community blogs since yesterday's briefing. If you missed it, William Lam's 19 Oct post on deploying VCF Management Services and VCF Automation to non-management networks from the 9.1.1 UI is still the most useful recent one for lab builders.
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.