Security advisories 4 open · 3 with CVEs in CISA KEV
Nothing new from Broadcom today. The newest advisory on its Security Advisory portal is still VMSA-2026-0007 from 3 September, but three older advisories have CVEs in CISA's Known Exploited Vulnerabilities catalogue, so they're worth another look if they're not already closed out in your estate.
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.
- 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 (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.
- CVE-2026-22719 8.1 command injection · KEV
- CVE-2026-22720 8.0 stored XSS
- CVE-2026-22721 6.2 privilege escalation
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.
- CVE-2025-41244 7.8 local privilege escalation · KEV
- CVE-2025-41246 7.6 Tools for Windows
- CVE-2025-41245 4.9 info disclosure
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.
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.
- CVE-2026-59346 9.3 VMXNET3 integer overflow
- CVE-2026-59347 8.1 HGFS stack overflow
DoUpdate Workstation and Fusion to 26H1u1. There's no workaround, so if you run nested labs on a laptop, it's worth doing soon.
Deep dive of the day Express patches in VCF 9.1
Since VCF 9.1, Broadcom has shipped security-focused patches between maintenance releases, roughly once a month, and calls them express patches. You'll spot them in the fourth group of the version number: 9.1.0.0100, 0200 and 0300 on the 9.1.0 line, then 9.1.1.0100 and 0200 on 12 October. TechDocs draws a helpful line here. An upgrade is a major or minor change (9.0 to 9.1) and needs a strict order. A patch is a maintenance (9.1.0 to 9.1.1) or patch-level (0200 to 0300) change and "does not require a strict patch order" unless the release notes say otherwise. Patches are cumulative, so you can jump straight to the newest one for a component.
The thing that catches people out is that not every component gets every patch. On 9.1.0, the 0100 drop touched ESX, vCenter, vSAN, NSX, SDDC Manager, VCF Operations and VCF Automation, but 0200 and 0300 only touched SDDC Manager and VCF Operations. The 12 October set is mixed again: SDDC Manager and VCF Automation went to 9.1.1.0200, while vCenter, ESX, NSX and vSAN went to 9.1.1.0100. In other words, there's no single "VCF 9.1.1.0200" bill of materials. Track versions per component instead: VCF Operations shows "On Target" or "Version Drift" on its Component Versions tab, and security advisories name component builds rather than VCF versions.
Day to day, patching runs from VCF Operations. Management components (VCF Operations, Fleet Lifecycle, VCF Automation and the management services) go through Build > Lifecycle > VCF Management > Upgrade > Change target version > Customize, where you pick a per-component target, run prechecks and upgrade. Core components (SDDC Manager, vCenter, ESX and NSX) are patched per domain under VCF Instances > Upgrades > Plan Component Upgrade. Only one patch operation can run at a time, the patch planner won't open while another upgrade plan exists, and you need the core-component binaries downloaded first, either from the online depot or with the VCF Download Tool.
For 9.1.1, order still matters in a few places. Patch the Fleet Lifecycle component first, and never patch VCF Operations in parallel with anything else. Patch VCF Operations and its license servers before ESX moves from 9.1.0.x to 9.1.1.0. Patch the services runtime before its identity broker or Salt RaaS, and VCF Automation before the migration service engine. A depot patch blocks everything else until it finishes, and patching VCF Operations also patches the license server and cloud proxy for you.
The real payoff is less downtime. vCenter quick patches restart only what the payload touches: vlcm, vsphere-ui and eam with no downtime at all, envoy and the licence service in up to 180 seconds, and vpxd, vmca, lookupsvc or vmon in about three to five minutes. ESX live patches install host by host on image-managed clusters without a reboot; Broadcom's 9.1 webinar Q&A describes hosts going into partial maintenance mode while their VMs keep running. Anything that needs a reboot, a driver change or full maintenance mode rules out live remediation, and VMs that can't fast-suspend-resume still need migrating or a power cycle.
A few gotchas to finish. In production, read each advisory's response matrix against your component builds: VMSA-2026-0006, for example, names vCenter 9.1.0.0300 as the fixed build and notes that 9.1.0.0200 was the first with the CVE-2026-59309 fix. On Supervisor estates, run the KB 455737 VUM schema check before any vCenter patch or upgrade. If you're still on 9.0, William Lam's answer to a reader is that applying a 9.0 express patch before moving to 9.1 can run into back-in-time issues depending on when you do it, so check the VCF Upgrade Planner first. In labs, remember live patching needs DRS, an image-managed cluster and hosts without TPM devices; if any of those is missing, plan for ordinary maintenance mode. And keep NTP tidy, because the 9.1.1 vCenter precheck already fails on non-UTC time zones.
Based on Lifecycle Management of VCF Components (TechDocs) Official Upgrade or Patch an Individual VCF Component (TechDocs) Official vCenter Quick Patches (TechDocs) Official Configuring vLCM for Live Patches (TechDocs) Official Installing Express Patches with VCF 9.1 (VCF blog, 29 Jun) Official Express Patching webinar Q&A (VCF blog, 8 Oct) Official VCF 9.1 - Understanding VCF Express Patches (William Lam, 8 Jul)
