CVE-2026-41709 ESXi: Low Score, Exploited Zero-Day

CVE-2026-41709 is an ESXi logging flaw that lets someone who already has admin access do certain things without leaving a log entry. Broadcom scores it 2.7 out of 10. CISA added it to its Known Exploited Vulnerabilities catalog on 28 October 2026 because attackers used it as a zero-day. The fix is in ESXi80U3j-25429389, ESXi-9.0.2.0100-25595025 and ESXi-9.1.0.0-25370933, or any later build.

Before writing this I read Broadcom's advisory, the CISA catalog entry and CrowdStrike's report. A 2.7 would normally wait for the next maintenance window. This bug was used in real intrusions to keep host logs quiet, and those logs are what you would read to find out whether your host was touched.

What is CVE-2026-41709?

Broadcom describes it as an insufficient logging vulnerability in VMware ESX (CWE-778). Its advisory, VMSA-2026-0006, says a malicious actor with administrative privileges could perform certain operations without them being logged. Broadcom has not said which operations those are. CrowdStrike calls it an "ESXi command logging bypass".

The flaw came out on 29 July 2026 in the same advisory as several critical vCenter and ESXi fixes. Broadcom credits Ian Barton of CrowdStrike with reporting it. The CVSSv3 vector Broadcom gives is AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N, so it needs high privileges and only touches integrity, which is why the number is so small.

Am I affected?

You are affected if you run ESX 8.0, 9.0 or 9.1 on a build older than the fixed one for your line, or VMware Cloud Foundation 5.x below 5.2.4. That covers most homelab and SMB hosts that have not been patched since July. To see your build, run vmware -vl or esxcli system version get in the ESXi shell, or look at the host summary in the web client.

ESX 7.0 has no row for this CVE in Broadcom's response matrix. The advisory does not say 7.0 is safe, and it does not say it is vulnerable. If you still run 7.0 with an extended support contract, ask Broadcom Support directly.

Which ESXi build fixes it?

These are the fixed versions in Broadcom's response matrix for CVE-2026-41709. Anything newer on the same line also contains the fix.

Broadcom lists no workaround, so patching is the only fix. If you run the free ESXi edition, check what you can download first. Portal access for free users has been a sore point, and we covered it in updating free ESXi 8.0U3e to 8.0U3h.

Why does a 2.7 score matter here?

CVSS measures what a bug does by itself. By itself this one does little, since an attacker needs admin rights and gets no new access or data from it. Once someone has admin on a host, though, the logs are the main way you would ever learn what they did, and a bug that hides commands from those logs makes the rest of the intrusion much harder to find.

CrowdStrike's 2026 Legal Threat Landscape Report, published on 28 October 2026, says the China-nexus group it tracks as WARP PANDA deployed several types of malware in victims' VMware vCenter environments at US organizations, some of them in the legal sector. In several of those cases, and as late as early 2026, the group used CVE-2026-41709 as a zero-day. SecurityWeek reported on 29 October that, according to CrowdStrike, the group usually gets in through internet-facing edge devices and then moves on to vCenter.

The CISA catalog entry gives federal civilian agencies until 11 November 2026 to apply the fix. Known ransomware use is marked "Unknown". That deadline only binds US federal agencies, but it is a fair guide for anyone else running exposed ESXi.

What should I check in my logs?

Patching stops new hidden activity, but it cannot put back entries that were never written. If a host ran an unpatched build and you have reason to think it was accessed, do not trust its local logs on their own. Compare them with records the host admin cannot edit: vCenter events, a remote syslog server, firewall logs and network flow data.

CrowdStrike's earlier WARP PANDA report from December 2025 lists practical checks for ESXi and vCenter, and they apply here too:

• Forward ESXi and vCenter syslog to an external system and keep it. A copy off the host is the one an attacker on the host cannot clean up.
• Look at SSH logins to ESXi, especially as root and vpxuser. CrowdStrike says any SSH activity by vpxuser should be thoroughly investigated.
• Turn off SSH on ESXi hosts when you are not using it. On ESXi 8.0 or later, turn off shell access for vpxuser.
• Enable the execInstalledOnly setting so the host runs only installed, signed binaries.
• Look for virtual machines that run on a host but are not registered in vCenter. CrowdStrike describes WARP PANDA creating such VMs and shutting them down after use.
• Limit outbound internet access from ESXi and vCenter, and put ESXi management interfaces on their own network segment.
• Reach vCenter only through an identity provider that enforces MFA.

Broadcom and CISA have not published indicators of compromise for this CVE, and neither does CrowdStrike's 28 October report. Gaps, sudden quiet periods or admin sessions nobody remembers in your local logs are a reason to look closer, though none of them proves an intrusion on its own.

Does this change the Proxmox vs VMware decision?

Not by much. Every hypervisor gets security fixes, and Proxmox has had its share. What this CVE does show is that patching and log forwarding need to work on whatever platform you run. If you stay on ESXi, the deciding question is whether you can reliably get patches like 8.0 Update 3j onto every host, including free-edition and lab hosts.

If you are partway through a move off ESXi, keep the old hosts patched and logging off-host until the last VM is gone. Hosts that are about to be retired are easy to forget. Our posts on the VMware exit problem, Proxmox gotchas for VMware admins and XCP-ng versus Proxmox for a VMware migration cover the planning side.

What I would do this week

Check every ESXi host's build against the table above and patch the ones below the fixed version, starting with any host whose management interface can be reached from outside. While you are in there, confirm that syslog is leaving each host, and turn SSH off where nobody needs it. For any host that sat unpatched with SSH open or an exposed vCenter in front of it, read its logs next to your vCenter and syslog records before you call it clean.