Security

VMware ESX CVE-2026-41709: a 2.7 on CISA's exploited list, and why the score is the wrong thing to read

28 October 2026·9 min read

A vulnerability score tells you how bad a flaw is on its own. It cannot tell you what the flaw is useful for. On 28 October CISA added CVE-2026-41709, a VMware ESX logging flaw scored 2.7 out of 10, to its list of vulnerabilities that are being exploited. A flaw that does nothing by itself and appears on that list tells you something about how attackers use it.

This note is for you if you run VMware ESX, or investigate incidents in an environment that does. Everything is as of 28 October 2026 and every claim links to its source at the end. One caution on sourcing: Broadcom's advisory page needs a browser to render, so our reading of the fixed builds comes from the CVE record and published coverage of the advisory. Confirm the builds in the advisory itself before you act.

The short version

CVE-2026-41709 (CWE-778, insufficient logging) is a flaw in VMware ESX. A malicious administrator can perform certain operations without them being logged. CVSS 3.1 2.7: network, high privileges required, a low integrity impact.
It was published in July in advisory VMSA-2026-0006 and added to CISA's Known Exploited Vulnerabilities catalog on 28 October, due 11 November. Ransomware use is not recorded.
Fixed in ESXi 9.1.0.0-25370933, ESXi 9.0.2.0100-25595025 and ESXi80U3j-25429389, per the published coverage and the CVE record. Check the advisory for your exact build.
The same advisory fixes more serious flaws: two critical vCenter flaws (CVE-2026-59309 and CVE-2026-59310, both 9.8) and a VM escape in the VMXNET3 adapter (CVE-2026-47876, 9.3). Patch to the build that covers all five.
Broadcom said in July it had found no evidence any of the issues was exploited. CISA's listing is newer and does not say how the flaw is used.

Cover page of A 2.7 on the KEV list: Assessment & Action Plan

Free PDF · 8 pagesA 2.7 on the KEV list: Assessment & Action PlanThe full version as a PDF for whoever runs your virtualisation estate: what the flaw is and why it is on the list, severity decoded, the fixed builds, the critical flaws in the same advisory, a dated timeline, a procedure for patching and for logging off-host, hunting without trusting the host's own logs, and a definition of done.Download the PDF →

What the flaw is

ESX records what administrators do: logins, configuration changes, commands. That record is what you reach for when something has gone wrong. This flaw means certain operations by an administrator are not recorded. It is not a way in. It needs an administrator already. Its value is what it does after the way in.

Why a 2.7 is on a list of exploited vulnerabilities

CISA's Known Exploited Vulnerabilities catalog is for vulnerabilities it has evidence are being exploited. A listing is CISA's statement that exploitation has been seen; it does not say who, how widely or since when. A flaw can only be on the list if CISA has evidence it is being used. So the listing is evidence that somebody has used a bug that makes administrative actions invisible.

Our reading, and it is a reading and not something the sources state, is that the value of this flaw is in covering tracks. An attacker who has reached administrator access on a hypervisor, perhaps through one of the other flaws in the same advisory or through stolen credentials, can use a logging gap to do things you would later want to prove or disprove: what they accessed, what they changed. A defender investigating afterwards has a gap where the evidence should be.

That is why a score that measures damage on its own misleads here. The damage is to your ability to find out what happened.

The advisory it came with

VMSA-2026-0006 is not a low-severity advisory. It contains:

CVE-2026-59309 and CVE-2026-59310 (vCenter, 9.8 each): an authentication bypass and a directory traversal leading to code execution, both with network access.
CVE-2026-47876 (ESX, VMXNET3 adapter, 9.3): an out-of-bounds write that lets a virtual machine administrator execute code on the host, a VM escape.
CVE-2026-41703 (7.6, information disclosure or denial of service).
CVE-2026-41709 (2.7), the subject of this note.

Broadcom classed the updates as an emergency change requiring immediate action and listed no workarounds, according to published coverage. A researcher reported on 11 August a spike in scanning of vCenter that they considered consistent with attempts against CVE-2026-59309. That is the researcher's observation, not Broadcom's statement.

Who is exposed

Anyone running ESX 9.1.x, 9.0.x or 8.0 builds before those named above, and the VMware Cloud Foundation, vSphere Foundation and Telco Cloud Platform versions that include them.
The exposure to this flaw is specific to people who already have administrator access. That includes the people you know, and the credentials, scripts and tools that act as them.
The larger exposure is the rest of the advisory. If you have not applied it, you have not closed the vCenter flaws either.

Things people will get wrong

"It is a 2.7, so it can wait." It is on the exploited list, with a deadline.
"Only admins can use it, so it is not our problem." Attackers who have become admins can use it. It is the second step.
"The host logs show nothing unusual." That is exactly what the flaw can produce.
"We can patch ESX and ignore vCenter." The advisory's most serious items are in vCenter and the VMXNET3 adapter.

How we would triage it

This is our judgement.

Patch to the build that covers the whole advisory, within CISA's window. You are patching for the critical flaws; this one rides along.
Change how you investigate. Do not rely on one host's own logs. Collect from the systems around it: vCenter, your identity provider, your network, your backup system.
Reduce who can be an administrator, and how. The flaw only matters to an attacker who has become one.

Step 1: builds and exposure

# On an ESXi host
vmware -vl
esxcli system version get

# Who has administrator access
esxcli system permission list

Record the build number for every host and compare with the fixed builds in VMSA-2026-0006. Include hosts in recovery sites and lab clusters.

Step 2: send logs somewhere an administrator cannot edit

# Forward ESXi logs to a remote syslog collector
esxcli system syslog config set --loghost='tcp://LOGHOST:514'
esxcli system syslog reload

Use a collector that ESX administrators do not control, and keep the copy for as long as you keep other evidence. A log that an attacker can edit on the host is a log that a gap like this can empty. An off-host copy captures what is sent before the operation, and from other systems.

Step 3: patch

Update to the fixed ESXi build for your version: ESXi 9.1.0.0-25370933 or later, ESXi 9.0.2.0100-25595025 or later, or ESXi80U3j-25429389 or later.
Apply the advisory's other fixes for vCenter and the VMXNET3 flaw. Broadcom's table names different builds for them, so confirm which single build carries all five.
Use vCenter lifecycle tooling where you have it, and plan evacuations.

Step 4: investigate without trusting the host

Review vCenter events, identity provider logs and network flow records for the periods when administrators were active.
Look for administrative access from addresses and times that do not fit, and for configuration changes that do not appear in any change record.
Compare what the host's own log says with what the surrounding systems say. A mismatch is the finding.
Lock down management: restrict who can reach ESX directly, and use lockdown mode so that hosts are managed through vCenter.

What we do not know yet

How the flaw is being used. The listing gives no detail.
Whether it is being used alone or with the vCenter and VMXNET3 flaws.
Whether Broadcom's July statement about exploitation has changed.

If you take one thing from this: a good investigation does not depend on one witness. Make sure that a record of what an administrator did exists somewhere the administrator cannot reach.