Security advisories 3 open with KEV CVEs
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.
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.
- CVE-2026-59309 9.8 vCenter VMDir auth bypass
- CVE-2026-59310 9.8 vCenter Syslog traversal · KEV
- CVE-2026-47876 9.3 ESX VMXNET3
- CVE-2026-41703 7.6 ESX OOB read
- CVE-2026-41709 2.7 ESX logging
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.
- CVE-2026-22719 8.1 command injection · KEV
- CVE-2026-22720 8.0 stored XSS
- CVE-2026-22721 6.2 privilege escalation
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.
- CVE-2025-41244 7.8 local privilege escalation · KEV
- CVE-2025-41246 7.6 Tools for Windows
- CVE-2025-41245 4.9 info disclosure
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.
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.
Deep dive of the day The VCF 9.1 license server
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.
Based on Deploy a License Server (TechDocs) Official KB 441251 Official VCF 9.1 Licensing (VCF blog, 18 May) Official William Lam (24 Jul) DinoCloud (14 Oct)
