VMware ESX Logging Vulnerability Exploited: Are Your Hosts Affected?

At a glance (as of 28 October 2026)

CVE-2026-41709 is an insufficient logging weakness in Broadcom's VMware ESX. Broadcom describes it as allowing a malicious administrator to perform certain operations without them being logged. Broadcom published the fix on 29 July 2026 in advisory VMSA-2026-0006, rated the flaw Low (CVSS 2.7) and lists no workaround. CISA added it to the Known Exploited Vulnerabilities (KEV) catalogue on 28 October 2026, stating the addition was based on evidence of active exploitation.

The practical message is calm but not optional. This flaw does not get an attacker onto your hypervisor. It makes an attacker who already has administrator-level access harder to see. That is precisely the help someone wants after a break-in, which is why a 2.7 on paper can still earn a place in this month's patching.

Your next action: list your ESX and ESXi hosts, read their build numbers, compare them with the fixed builds below and book the update. Then make sure the hosts send their logs somewhere else.

Which hosts are affected and what fixes them

Broadcom's response matrix for CVE-2026-41709 lists the ESX component only. Every row is rated Low (CVSS 2.7) with workarounds shown as none. The fixed versions it gives are:

• VMware Cloud Foundation or vSphere Foundation 9.1.x.x: ESXi-9.1.0.0-25370933
• VMware Cloud Foundation or vSphere Foundation 9.0.x.x: ESXi-9.0.2.0100-25595025
• VMware ESX 8.0: ESXi80U3j-25429389 (8.0 Update 3j)
• VMware Cloud Foundation 5.x: 5.2.4, with Broadcom pointing to its async patching guide, KB88287
• VMware Telco Cloud Platform 5.0.x and 5.1.x: see Broadcom KB449886

Edge cases to check against the advisory itself

ESXi 7.0 does not appear in the matrix for this CVE. We have not found a Broadcom statement either way, so do not read that as a clean bill of health. If you still run 7.0, ask Broadcom support or your supplier for guidance.

ESXi 8.0 Update 3k (build 25595708) is described by Broadcom as a targeted security rollup, and some third-party write-ups cite it as the 8.0 fix. The matrix we could read lists Update 3j. If you are on 3k, confirm in the current advisory and release notes that it covers this CVE rather than assuming.

Broadcom has revised VMSA-2026-0006 twice since July (3 and 19 August). Always read the live advisory before settling on a target build, because rows can change.

How serious is it really?

Severity and urgency point in different directions here. Broadcom rates the flaw Low because it needs high privileges and does not itself give anyone control, data or code execution. Its value to an intruder is concealment: an administrator-level action that does not appear in the host's logs is an action you cannot investigate afterwards.

On exploitation, there are two separate pieces of evidence. CISA lists the flaw in KEV, though its entry does not describe what it observed or who was targeted, and it records ransomware use as unknown. Separately, CrowdStrike, whose researcher reported the flaw to Broadcom, says in a report published on 28 October 2026 that a China-nexus adversary it tracks as WARP PANDA exploited this ESXi command logging bypass as a zero-day in several intrusions, as late as early 2026. That claim comes from a single vendor report, and the report does not tell us which operations go unlogged.

Neither source says every vulnerable host has been attacked. Treat it as a known tool in real intruders' kits, not as evidence your own estate is compromised. The deadline of 11 November 2026 in the KEV catalogue is a requirement for US federal agencies, not for UK organisations, but it is a sensible yardstick for how quickly CISA thinks this should be dealt with.

Check which build each host is running

This is read-only. You need rights to view the host in the vSphere Client or access to the ESXi Shell. Do not switch SSH on just to do this check if the client gives you the answer.

1. In the vSphere Client, select the host and open its Summary tab. The Build value is the number to compare with the fixed builds above.
2. If the ESXi Shell or SSH is already enabled for administration, you can instead run the command below. On an 8.0 Update 3k host Broadcom documents the expected output as VMware ESXi 8.0.3 build-25595708, so the same format applies for other builds.
   shellCopy

   vmware -v

3. Write down each host's build and mark which ones sit below the fixed build for their branch. Those are your patching list.

Patch the hosts

Updating ESXi is a disruptive change. Plan for each host to enter maintenance mode, so its virtual machines must be moved or shut down, and expect a host reboot unless the release notes for your target build say otherwise. Run hosts one at a time in a clustered environment so that capacity stays available, and take the usual backup or snapshot protections your change process requires for the workloads on them.

Use the update path Broadcom documents for your product: the ESX build for standalone 8.0 hosts, the VCF or VVF release for managed estates, and the async patching guide for VCF 5.x. The same advisory also covers other flaws rated far higher, including in vCenter, so it is worth reading the whole of VMSA-2026-0006 rather than only this CVE.

After each host returns, confirm the Summary tab or vmware -v now shows the fixed build. A host that still reports the old number has not taken the update, whatever the task log said.

Send host logs to a separate log server

Patching closes the hole going forward. It does not recreate records that were never written. We do not know which operations were affected, so no one can honestly tell you which gaps to look for. What you can do is stop relying solely on files stored on the host itself, where anyone with administrator rights has the best chance of altering them. NCSC logging guidance likewise supports sending logs to a central store.

If your hosts already forward to a syslog collector or monitoring platform, check it is still receiving and skip this section. Otherwise, the commands below use Broadcom's documented syslog procedure. They change the host's configuration and its outbound firewall rules, need administrator access to the ESXi Shell, and need a collector the host can reach. Replace YOUR_SYSLOG_SERVER_IP with the collector's address. Broadcom's article also supports udp:// and ssl:// prefixes, so choose what your collector accepts.

1. Show the host's current syslog settings so you know what you are changing.
   shellCopy

   esxcli system syslog config get

2. Set the remote log host. This example uses TCP on port 514.
   shellCopy

   esxcli system syslog config set --loghost='tcp://YOUR_SYSLOG_SERVER_IP:514'

3. Reload syslog so the new setting takes effect.
   shellCopy

   esxcli system syslog reload

4. Allow the syslog ruleset through the ESXi firewall and refresh it. Standard ports still need this ruleset enabled.
   shellCopy

   esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true
   esxcli network firewall refresh

5. Send a test message, then check that it appears on your log server. If it does, forwarding works. If nothing arrives, check network reachability from the host to the collector on that port.
   shellCopy

   esxcli system syslog mark --message "Syslog Test Message"

If you suspect someone has already misused admin access

Nothing in the public sources gives a reliable way to detect use of this flaw, and CrowdStrike's report offers no indicators for it. So the useful questions are the ordinary ones: who holds administrator rights on the hosts and vCenter, are there accounts or sessions nobody can explain, is the management network reachable from places it should not be, and do your central logs and the host logs tell the same story? CISA's guidance also asks organisations to evaluate internet exposure of affected products, and ESXi management interfaces should not be reachable from the internet.

If you find something odd, do not wipe or rebuild a host first, because that destroys evidence. Preserve what you have and bring in incident response help.

What has and has not been confirmed publicly

Confirmed by primary sources: Broadcom's description, severity, fixed builds and the absence of a workaround, CISA's KEV listing on 28 October 2026 and CrowdStrike's statement of zero-day use. Not established: how the bypass works, which operations are left unlogged, whether ransomware operators use it, and any named victim. We are not naming any organisation, because no public source we checked identifies one in connection with this CVE. Information is still developing and we will revise this page as Broadcom, CISA or others publish more.