Networks

Security alert

VMware ESX logging flaw is on CISA's exploited list: patch the whole advisory, because it also fixes critical bugs

CVE-2026-41709 is a low-severity ESX flaw, but CISA lists it as exploited. The same Broadcom advisory fixes critical vCenter and ESX flaws. Here is what to check and install.

If your office or agency runs VMware ESX hosts or a vCenter server, read Broadcom’s advisory VMSA-2026-0006 this week. The Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-41709 to its Known Exploited Vulnerabilities (KEV) catalog on October 28, 2026, with a federal due date of November 11, 2026.

On its own, this one looks minor. It is an insufficient-logging flaw in ESX that lets a malicious ESX administrator perform certain operations without them being recorded. Broadcom rates it Low, with a CVSS score of 2.7. The reason to care is what shipped alongside it.

Why the “low” rating shouldn’t make you wait

CVE-2026-41709 is one of five issues fixed in the same advisory, which Broadcom first published on July 29, 2026 and last updated on August 19. The advisory as a whole is rated Critical:

  • CVE-2026-59309 (vCenter): authentication bypass in the VMware Directory Service, CVSS 9.8. Exploiting it needs network access to vCenter but no login.
  • CVE-2026-59310 (vCenter): directory traversal in the Syslog server, CVSS 9.8.
  • CVE-2026-47876 (ESX): out-of-bounds write in the VMXNET3 virtual network adapter, CVSS 9.3. It needs local administrator rights inside a virtual machine that uses that adapter, and may allow code to run on the host.
  • CVE-2026-41703 (ESX): out-of-bounds read, CVSS 7.6 for ESX.
  • CVE-2026-41709 (ESX): the logging flaw above.

CISA’s KEV entry covers only CVE-2026-41709. Broadcom’s advisory does not state that the other four are exploited. Still, if you have been putting this patch off because nothing in it looked urgent, the KEV listing is a reason to stop. There are no workarounds for any of the five, so installing the update is the only fix.

A logging flaw matters most after something has already gone wrong. If an attacker already has ESX admin rights, this flaw can help hide what they did. If you can’t explain who has admin rights on your hosts, deal with that first.

Check whether you’re exposed

  1. Find out which products you run: ESX hosts (older documents call them ESXi), vCenter Server, or both. Small shops sometimes inherit a single host that nobody has logged into for a year.
  2. Note each host’s version and build number, and each vCenter’s version.
  3. Confirm that the vCenter and ESX management interfaces are not reachable from the internet. If one is, treat that as the first problem to fix, whatever the patch status.
  4. Compare your builds with the response matrix in the advisory (linked below).

What to install

Per the advisory’s response matrix, as of November 2026:

Product Fixed in
ESX 8.0 ESXi80U3k-25595708 (or ESXi80U2f-25626445 for U2f deployments) for the critical VMXNET3 flaw; the logging flaw is fixed in ESXi80U3j-25429389
ESX 9.0 ESXi-9.0.2.0100-25595025
ESX 9.1 ESXi-9.1.0.0200-25557999 for the critical VMXNET3 flaw; the logging flaw is fixed in ESXi-9.1.0.0-25370933
vCenter 9.1 9.1.0.0300
vCenter 9.0 9.0.2.0100
vCenter 8.0 8.0 U3k (or 8.0 U2f for U2f deployments)

ESX 7.0 and vCenter 7.0 have no fixed builds listed. The advisory says to contact Broadcom Support if you have an extended support contract. If you don’t, that version is past the point where this advisory can help you, and it’s time to plan a move or a replacement.

Because the critical and low-severity issues carry different build numbers, don’t stop at the build that fixes the logging flaw. Install the build listed for the highest-severity issue that applies to you, then confirm against the matrix that your final build covers every CVE for your version.

Before you patch

  • Take a current backup or snapshot-level copy of the virtual machines that matter, and confirm you can restore from it.
  • Patch vCenter first if you run one, then the hosts, one at a time if you have more than one.
  • Plan for host reboots and for moving or shutting down the virtual machines on each host. Do it in a maintenance window.
  • If you manage hosts for several offices, record the build number you installed at each one.

After you patch

Review who holds administrator rights on ESX and vCenter, remove accounts that no longer need them, and make sure host logs are also sent to a separate syslog server you control. If you ran an unpatched, exposed host for any length of time, assume log gaps are possible and check for accounts and virtual machines you don’t recognize.

Whether this affects a system covered by CJIS (the FBI’s Criminal Justice Information Services) or FFIEC (the banking regulators’ council) requirements is a question for your state CJIS systems agency, examiner, or counsel.

Sources

All articles