Workstation and Fusion 25H2 and 26H1, CVSSv3 8.1–9.3. Neither CVE is in CISA KEV, and the advisory makes no statement on exploitation.
- CVE-2026-59346 9.3 VMXNET3
- CVE-2026-59347 8.1 HGFS
DoUpdate to 26H1u1. There is no workaround.
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 →A quiet weekend for releases, but not for security: vCenter CVE-2026-59310 from VMSA-2026-0006 has been in CISA's Known Exploited Vulnerabilities catalogue since 18 August, and CISA lists known ransomware campaign use. New in the knowledge base: VCF Operations 9.1.1 can raise recurring internal-certificate alerts after upgrade (KB 456305). Today's deep dive covers the VCF 9.1 license server.
This is an earlier briefing. Read today's Latest Tech News →
The newest advisory on Broadcom's Security Advisory portal is VMSA-2026-0007 (3 Sep 2026). Exploitation status comes from each Broadcom advisory and the CISA KEV catalogue (release 2026.10.16). Also in KEV since 23 Jan 2026: vCenter CVE-2024-37079 from VMSA-2024-0012.1, which Broadcom marks Closed and says has been exploited in the wild; fixed in vCenter 8.0 U2d / 7.0 U3r and later.
Workstation and Fusion 25H2 and 26H1, CVSSv3 8.1–9.3. Neither CVE is in CISA KEV, and the advisory makes no statement on exploitation.
DoUpdate to 26H1u1. There is no workaround.
vCenter, ESX, Workstation and Fusion (also VCF, VVF and Telco Cloud), CVSSv3 2.7–9.8, no workarounds. CVE-2026-59310 is in the CISA KEV catalogue (added 18 Aug, due 21 Aug, known ransomware campaign use). The Broadcom advisory itself makes no statement on exploitation. The other four CVEs are not in KEV. First published 29 Jul.
DoPatch vCenter to 9.1.0.0300, 9.0.2.0100 or 8.0 U3k / U2f (VCF 5.x: async patch per KB 88287), and ESX to ESXi-9.1.0.0200-25557999, 9.0.2.0100-25595025 or 8.0 U3k / U2f. Treat any unpatched, reachable vCenter as possibly compromised.
Aria Operations / VCF Operations, CVSSv3 6.2–8.1. CVE-2026-22719 is in CISA KEV (added 3 Mar 2026); Broadcom is "aware of reports of potential exploitation" but cannot confirm them.
DoVCF Operations 9.x to 9.0.2.0 or later; Aria Operations 8.x to 8.18.6. Workaround for CVE-2026-22719: KB 430349.
Aria Operations and VMware Tools, CVSSv3 4.9–7.8. CVE-2025-41244 is in CISA KEV (added 30 Oct 2025), and Broadcom reports suspected exploitation.
DoVMware Tools to 13.0.5 or 12.5.4; VCF Operations 9.x to 9.0.1.0 or later; Aria Operations 8.x to 8.18.5. No workaround.
All VMware security advisories on Broadcom's support portal →
vidb-postgres-instance-postgres-cert-secret in namespace vidb-external so it regenerates, wait about 5 minutes, then clear the alerts. virtualHW.version = "17" in the .vmx, vim-cmd vmsvc/reload, power on and retry. inPlaceUpdateStrategy (default MinimizeSpareNodes), VLAN-backed VPC support and new cluster conditions. Upgrade VKS to 3.7.2 before upgrading the Supervisor to 9.1. Also unchanged: Avi KB 312808 lists 32.1.3 (3 Sep) as newest, and the VKr notes list v1.36.2 and v1.35.6 (17 Aug) as newest. No new provider or plugin releases. Latest versions, from the Terraform Registry API and GitHub, are in the side panel.
3.14.2 (10 Jul), vra 0.17.4 (11 Sep), tanzu-mission-control 1.4.11 (15 Sep). The legacy hashicorp/vsphere provider is still at 2.12.0 (22 Apr 2025). 2.5.0 (31 Aug) removed vTPM support (#836), no longer needs an IP on every NIC (#720) and moved to govmomi 0.56.0. vm_info now warns instead of failing when a VM disappears mid-gather (#431); vm_portgroup_info VM search was reworked to handle attribute errors (#425). New docs cover VM inventory migration (#429) and case sensitivity (#433). Safe to move your pin up. v9.1.0.0 (GitHub, June; Python 3.10+) and Ansible vmware.vmware_rest 5.0.0 on Ansible Galaxy. HEALTH0002 … Synthetic checks failed [VCFMS-BOOTSTRAP-999]. Cause: choosing Small (High Availability), which needs three control-plane VMs on separate hosts. Fix: clean up (KB 445132, 447187), redeploy with Small. In two-host labs, never pick an HA size. In VCF 9.1, licensing is no longer something vCenter does on its own. VCF Operations is the licensing control plane, and a separate license server appliance holds and serves the entitlements. One license server can serve many VCF instances and vCenters in a fleet, but you need at least one, and it only works together with VCF Operations. On its own it licenses nothing.
The flow is: VCF Operations issues a time-bound registration key, you deploy the license server OVA through vCenter with that key, the appliance registers with VCF Operations, and you then register it with the VCF Business Services console (vcf.broadcom.com) to assign VCF or VVF entitlements. Deployment takes up to about 20 minutes. Later VCF Operations upgrades also patch the license server and cloud proxy, so you rarely touch it again.
It has two operating modes. In connected mode, usage is sent to Broadcom every 24 hours and an updated licence file is applied automatically, which removes the old 180-day manual acknowledgement. Disconnected mode keeps the manual exchange roughly every 180 days, and the licensing APIs (now open to all customers, not just service providers) let you script that across sites. The license server itself does not talk to the internet; it talks only to VCF Operations, optionally through a proxy.
Requirements that catch people out: a unique FQDN with both A and PTR records, which every vCenter using it must resolve; IPv4 only, as there is no IPv6 support; and the API Key field in the OVA wizard stays blank unless support tells you otherwise. In upgrades from vSphere 8, licences downloaded to the license server cannot be assigned until vCenter is on 9.x, so an evaluation warning in between is expected.
Broadcom's troubleshooting article for a license server that will not register (KB 441251) lists the usual culprits: time drift between VCF Operations, the appliance and the ESX host, which breaks token validation; missing forward or reverse DNS; uppercase characters in hostnames or DNS records; a proxy applied to internal traffic; and deploying the OVA from the standalone ESX host client, which never injects the OVF properties. The symptom is quiet: adding the server bounces back to the Licenses & Registration page and the appliance shows DISCONNECTED. Fix the cause, generate a fresh one-time token and redeploy through vCenter.
Lab gotchas: registration keys expire, so generate one right before deploying (a stale key or time drift can leave the appliance missing from the License Servers list). Avoid 172.17.0.0/16 for DNS or the appliance's network, because it collides with the appliance's internal Docker network (KB 441526, fixed in 9.1.0.0200). For automation, the community Broadcom.Community.VCFLicensing PowerShell module can fetch the registration key, which pairs well with a Packer or OVF Tool pipeline.
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.