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 →It's a quiet morning for patches, which makes it a good day to read Broadcom's new six-part series on tenant connectivity in VCF 9.1. If you run NSX VPCs, and especially if you've ever wondered why a VPC workload leaves with one source address on one path and a different one on another, Part 2 sets out the four rules that decide it, and today's deep dive builds on it.
Security hasn't changed, and it still needs your attention. There's no new advisory from Broadcom, but vCenter CVE-2026-59310 from VMSA-2026-0006 remains in CISA's Known Exploited Vulnerabilities catalogue with known ransomware use, so any unpatched vCenter is still the top job.
Elsewhere, three Broadcom KBs are worth a read before your next 9.1.1 upgrade, VCF Operations 9.1.1 has a new capacity forecasting engine that may nudge your rightsizing numbers, and there's a small correction on the Azure VMware Solution deadline: 31 October applies to licence-included PayGo SKUs, not every licence-included node.
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, and every open advisory reads exactly as it did yesterday. Three older 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 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 →
None of these show an updated date, but all three are about the 9.1 to 9.1.1 upgrade path, so they're worth a read before your next maintenance window.
lcm-debug.log shows NsxClusterRetrievalException: Failed to retrieve NSX-T manager, this is the likely cause. SDDC Manager's inventory has the NSX Manager cluster stuck in ACTIVATING instead of ACTIVE. The fix is to snapshot SDDC Manager, pull the cluster record from the local inventory API, change only the status to ACTIVE, PUT it back and rerun the precheck. 9.1.1.0.25713928 and throws a red banner. The workaround is simply to run prechecks and plan the upgrade from VCF Operations under Build > Lifecycle > Upgrades > VCF Instances instead. Another quiet day for release notes. Nothing 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.
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. Every current version and the full support table are 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). Nothing to update this week. VCF.PowerCLI 9.1.1.25718932 (10 Sep) is still the current version on the PowerShell Gallery, and govmomi v0.56.0 (21 Aug) is still the latest release.
If you've started using NSX VPCs in VCF 9.1, the part that usually takes longest to click is how a VPC actually reaches the outside world. Broadcom's model has three layers. A VPC is an on-demand logical network inside an NSX project. Every project, including Default, gets a transit gateway that joins its VPCs together and links them outwards. And the transit gateway attaches to one or more external connections, which are the real links into your physical network. A VPC Connectivity Profile glues it all together: it names the transit gateway, the IP blocks the VPC may use, and whether Default Outbound NAT is switched on.
There are three kinds of external connection, and your choice shapes everything else. A centralised connection goes through a Tier-0 gateway on NSX Edge nodes, which gives you BGP with the fabric and stateful services, and lets you configure NAT on the transit gateway. A distributed VLAN connection skips Edges entirely and connects the transit gateway straight to fabric VLANs on the ESX hosts, with stateful services coming from Virtual Network Appliances (VNAs). From 9.1.1 there's also a distributed VXLAN connection for EVPN fabrics, again using VNAs for advanced services. Attaching a transit gateway to a centralised connection makes it a centralised transit gateway (CTGW); attaching it to a distributed one makes it a distributed transit gateway (DTGW).
A few rules from TechDocs are easy to trip over. All the external connections on one transit gateway must be the same type, so you can't mix centralised and distributed. A VPC connects to only one transit gateway at a time, although you can move it by changing its connectivity profile, and NSX runs IPAM and span checks when you do. Public subnets and external IPs can't overlap across different DTGWs. And a CTGW can now run its own HA mode on an Edge cluster that differs from the Tier-0's: active-active suits throughput, active-standby suits NAT. That fixes the old limitation where an active-active Tier-0 meant no auto SNAT, and sharing the Tier-0's HA mode is now deprecated.
Then there's the question of which source address a packet leaves with, which Part 2 of the new VCF blog series answers neatly. Public subnets come from external IP blocks and are routed as they are. Private-VPC subnets only get out through NAT. Private-TGW subnets can talk to other VPCs on the same transit gateway without NAT, but need NAT at the CTGW or explicit advertisement to leave. Default Outbound NAT applies first (at the VPC gateway for Private-VPC, at the CTGW for Private-TGW), the CTGW routing table then picks the exit by longest prefix, and the exit connection either applies Provider Outbound SNAT, passes the address through, or forwards advertised Private-TGW traffic. If the source isn't authorised on that exit connection, there's no return path, and that's the failure the series sees most.
For production, decide early whether you need dynamic routing and centralised stateful services (centralised connections, Edges and a CTGW) or would rather keep things light and host-based (distributed connections and VNAs). Plan your IP blocks before you build anything, because overlaps between external blocks, VLANs, public and private subnets and transit gateway blocks cause failures that look like misconfiguration. Remember that stateful gateway firewalling on VPCs needs a vDefend licence. If you use VNAs, size them properly: community testing describes Small (2 vCPU, 4 GB) as lab-only and Large (8 vCPU, 32 GB) for production, with services running active/standby rather than active/active.
In a nested lab, the distributed VLAN route is usually the easiest win, since there's no Edge cluster to feed. The external VLAN has to be present on the hosts' uplinks alongside the NSX overlay vmkernel adapter, which in practice means a Layer 2 design where every host can reach it. Watch for the auto-created connectivity profile having no private transit gateway block (add one if VPCs need to talk to each other), keep the external IP block inside the distributed connection's CIDR, and add a small VNA cluster if you want Default Outbound NAT. It's also worth testing vMotion and a host failure, not just steady-state pings, before you trust the design.
/storage/log/vcops/log/capacityMetricsUpgradeChanges.csv shows what changed, and you can reset a workload's baseline after a migration using the suggested Recommended Reset Date. 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.