Security Advisories Latest four
No new VMSA today. Broadcom revised VMSA-2026-0008 to .1 on 28 Oct to make clear that SDDC Manager is the only affected component, and it is still waiting on a patch. The news is about VMSA-2026-0006: The Hacker News and SecurityOnline [Press] report that CISA added the ESX logging flaw CVE-2026-41709 to its KEV catalogue on 28 Oct, and CrowdStrike says WARP PANDA exploited it as a zero-day as late as early 2026. The Broadcom advisory itself makes no statement on exploitation, and vCenter CVE-2026-59310 is still the first thing to have patched. The Linux kernel flaw CISA added the same day, CVE-2026-46300 (Fragnesia), is covered by Broadcom's KB 439687, which says ESXi and the Photon-based appliances are not affected. Broadcom's advisory portal has the older advisories.
Node.js, as used in SDDC Manager, has a Brotli decoder out-of-bounds write that an attacker with network access to SDDC Manager could use to run code. It is critical (9.8) only on SDDC Manager 9.1.1; on 9.0.x, 9.1.0 and 5.2.x it is rated important (7.5, adjacent network). Revision .1 on 28 Oct clarified the impacted products: only the SDDC Manager component of VCF. Every fixed version is still "Patch pending", and the advisory makes no statement on exploitation. Issue date 27 Oct 2026.
- CVE-2026-111497 9.8 SDDC Manager Node.js Brotli · 9.8 on 9.1.1, 7.5 elsewhere
DoRestrict SDDC Manager to trusted admin networks, apply KB 460732 on 9.1.1 or KB 460734 on 9.0.x, 9.1.0 and 5.2.x, and subscribe to the advisory for the patch.
For desktop hypervisors: Workstation 25H2 and 26H1 and Fusion 25H2 and 26H1, CVSSv3 8.1 to 9.3. Both CVEs need local admin rights inside a guest and can lead to code execution on the host. There are no workarounds and the advisory makes no statement on exploitation.
- CVE-2026-59346 9.3 VMXNET3 integer overflow
- CVE-2026-59347 8.1 HGFS stack overflow
DoUpdate Workstation and Fusion to 26H1u1, especially if you run nested labs on a laptop.
Still the one to prioritise. It covers vCenter, ESX, Workstation and Fusion (and so VCF, VVF and Telco Cloud), CVSSv3 2.7 to 9.8, with no workarounds. CISA added vCenter CVE-2026-59310 to its KEV catalogue on 18 Aug 2026 with known ransomware use. New this week: The Hacker News [Press] reports CISA added the ESX logging flaw CVE-2026-41709 to KEV on 28 Oct, and CrowdStrike reports zero-day use by WARP PANDA. Note that CVE-2026-41709 has its own fixed builds in the matrix. The Broadcom advisory itself makes no statement on exploitation. 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 · reported KEV 28 Oct
DoPatch vCenter to 9.1.0.0300, 9.0.2.0100 or 8.0 U3k / U2f (VCF 5.x: async patch per KB 88287). For ESX, ESXi-9.1.0.0200-25557999, ESXi-9.0.2.0100-25595025 or ESXi80U3k-25595708 cover all three ESX CVEs; ESXi80U2f-25626445 does not cover CVE-2026-41709, whose 8.0 fix is ESXi80U3j-25429389, and for VCF 5.x the matrix lists 5.2.4 for it.
If you run Avi Load Balancer (including for VKS or VCF Automation), this one matters. Seven CVEs, CVSSv3 7.1 to 9.8, no workarounds; the worst, CVE-2026-47865, is an authentication bypass on the Avi control plane. The advisory makes no statement on exploitation. First published 14 Jul 2026; revision .1 on 7 Aug added the 22.1.7-2p12 patch.
- CVE-2026-47865 9.8 control-plane auth bypass
- CVE-2026-47871 8.8 directory traversal
- CVE-2026-47867 8.7 RCE
- CVE-2026-47869 8.7 authenticated RCE
- CVE-2026-47866 8.3 authorisation bypass
- CVE-2026-47868 7.8 local privilege escalation
- CVE-2026-47870 7.1 privilege escalation
DoUpgrade 32.1.x to 32.1.2 or later (the advisory's recommended version), 31.1.1–31.2.2 to 31.2.2-2p3, and 30.1.1–30.2.6 to 30.2.7. On 22.1.x, 22.1.7-2p12 fixes CVE-2026-47865, but the matrix lists 30.2.7 for the other six.
All VMware security advisories on Broadcom's support portal →
Deep Dive of the Day Getting ESX logs and audit records off the host before anyone can thin them out
Today's news is a good reason to look at how ESX logging works, because a flaw that lets an administrator act without being logged only helps an attacker if the host's own logs are your only record. Broadcom fixed CVE-2026-41709 in July, but the wider lesson holds for any compromise: get the evidence off the box quickly, to somewhere the host can't edit.
ESX has two streams to think about. The first is ordinary syslog, sent to the collectors in Syslog.global.logHost as a comma-separated list of protocol://host:port entries; the ESX Syslog Options page lists TCP, UDP and SSL, with 1514 the default for TCP and SSL and 514 for UDP. A blank value forwards nothing. If you use SSL, Syslog.global.certificate.checkSSLCerts enforces certificate checking against the collector, which is what you want in production.
The second stream is audit records, which Managing ESX Audit Records describes as RFC 5424 events with the time, status, description and user for actions on the host. They are off by default. Syslog.global.auditRecord.storageEnable keeps them locally (in /scratch/auditLog unless you change it) and Syslog.global.auditRecord.remoteEnable sends them to the same logHost collectors as part of the syslog stream. Locally they live in a fixed-size buffer that overwrites the oldest records, so the remote copy is the one that matters; you can read the local ones with /bin/viewAudit.
A few gotchas from the docs. Set up persistent storage before touching the audit or logDir settings, because only /scratch survives a reboot. Audit storage capacity can be increased but never decreased, and the directory can't be changed while storage is enabled. If the link to the collector drops, records are discarded once the buffer is full, and on reconnection ESX writes an audit message saying messages may have been lost, which is itself worth alerting on. Messages default to a 1 KiB maximum length, UDP is capped at 480 bytes on IPv4 (1180 on IPv6), and before 8.0 Update 3i the length setting didn't apply to UDP at all, another reason to prefer TCP or SSL.
On the production side, Mandiant's ESXi detection and hardening write-up [Community] makes the same point from the attacker's angle: some ESXi malware stops vmsyslogd from recording at startup, so centralised logging of every host and vCenter into your SIEM is the baseline, alongside enforcing VIB acceptance levels and Secure Boot. The 9.1 ESXCLI syslog page notes that ESXCLI needs SSH, which it doesn't recommend, so set these values cluster-wide through your normal host configuration tooling rather than host by host over SSH.
In a nested lab, it's a cheap habit to build: point the hosts at a small syslog VM or your VCF Operations for logs instance over TCP, enable audit records, and you have a realistic test bed for alerting on the "potential message loss" event. One caution from the options page: Syslog.global.vsanBacking, which allows logs and audit storage on vSAN, may make a host unresponsive, so keep lab logs on a local or NFS datastore instead.
Based on Managing ESX Audit Records Official ESX Syslog Options Official Set ESX Syslog by using ESXCLI (9.1) Official Bad VIB(E)s Part Two: Detection and Hardening within ESXi Hypervisors (Mandiant)
