On this page
CISA added CVE-2026-41709 to its Known Exploited Vulnerabilities catalog on Wednesday, October 28 (catalog 2026.10.28, released 3:00 PM ET). It is a VMware ESX bug that lets someone with admin access run certain commands without ESX writing them to its logs. Broadcom scored it 2.7 out of 10 when it shipped the fix in July, which is why most patch queues skipped it. The same day, CrowdStrike reported that the China-nexus group it calls WARP PANDA used it as a zero-day, as late as early 2026, in intrusions at US organizations that included law firms.
The score measures what the bug gives an attacker on its own, which is almost nothing. The KEV entry measures what it gave a real attacker who already had the hypervisor: commands that never showed up in the record. If you are investigating an ESXi host from that period, the host's own logs may be incomplete in exactly the place you need them.
How to fix
Update each ESX host to the fixed build for its line from VMSA-2026-0006. There is no workaround.
| Product | Line | Fixed in |
|---|---|---|
| VMware ESX (vSphere Foundation, VCF) | 9.1 | ESXi-9.1.0.0-25370933 |
| VMware ESX (vSphere Foundation, VCF) | 9.0 | ESXi-9.0.2.0100-25595025 |
| VMware ESX | 8.0 | ESXi80U3j-25429389 |
| VMware Cloud Foundation | 5.x | 5.2.4 (async patching guide KB88287) |
| VMware Telco Cloud Platform | 5.0, 5.1 | KB449886 |
# On each host (SSH or ESXi Shell): what build is this?
esxcli system version get
# Typical patch flow from a depot, with the host in maintenance mode
esxcli system maintenanceMode set --enable true
esxcli software profile update -d /vmfs/volumes/datastore1/<offline-bundle>.zip -p <image-profile>
rebootIf you manage hosts with vSphere Lifecycle Manager, remediate the cluster against an image that includes the build above. Broadcom's response matrix for this CVE does not list ESXi 7.0, which reached end of general support in 2025. If you still run 7.0, treat it as unfixed for this issue.
Stop trusting the host to keep its own record
A patched host still has the problem this KEV entry exposes: anyone with root on ESXi controls the logs on that host. The fix closes one specific gap. It does not make local logs trustworthy after a compromise. Two checks matter more than the patch for incident response:
# 1. Are logs leaving the host? An empty Remote Host means they are not.
esxcli system syslog config get
# Send them to a collector the ESXi admin account cannot touch
esxcli system syslog config set --loghost='tcp://syslog.example.internal:514'
esxcli system syslog reload
esxcli network firewall ruleset set -r syslog -e true
# 2. Is anything installed that VMware did not sign?
esxcli software acceptance get
esxcli software vib listAn acceptance level of CommunitySupported, or a VIB from a vendor you cannot name, is worth a hard look. Hypervisor backdoors on ESXi have shipped as unsigned VIBs before. Also compare esxcli system account list with the accounts you expect.
One more detail from CrowdStrike's August research on ESX shell logging: shell.log records a command as it was typed, before the shell expands it. A command built from printf escapes runs normally but is logged as gibberish. Searching logs for esxcli or vim-cmd is not enough. Look for printf, base64, awk with system(), and command substitution in sessions you cannot account for.
What the attacker already had
CrowdStrike says WARP PANDA deployed several forms of malware in victims' VMware vCenter environments, and used CVE-2026-41709 in several of those cases. The bug requires administrator access to ESX, per Broadcom. So the order is: get into vCenter or an ESX admin account by some other route, then use this bug to keep the follow-up work out of the logs. Broadcom has not said which operations go unlogged, and CrowdStrike calls it a command logging bypass without more detail. We are not going to guess.
Broadcom's advisory credits Ian Barton of CrowdStrike for the report. When the patch shipped on July 29, Broadcom said it had no indication of exploitation. CrowdStrike's report now places in-the-wild use before that date.
Who is not in scope
- VMware Workstation and Fusion are not listed for this CVE. They appear in the same advisory for other bugs.
- vCenter Server is not the vulnerable component here. It is where CrowdStrike says the intrusions started. The vCenter bugs in the same advisory, CVE-2026-59309 and CVE-2026-59310, are a separate and more urgent fix, and 59310 has been on KEV since August 18.
- Hosts that no unauthorized person has administered gain nothing from the patch on day one. The value is in closing the gap before the next intrusion, and in knowing that older logs may be incomplete.
What this is not
CVE-2026-41709 is not a way in. It is not remote code execution and it does not bypass authentication. An attacker who can use it already has administrator access to the hypervisor. It matters because it hides what they do next.
What do people ask about CVE-2026-41709?
Is CVE-2026-41709 being exploited?
Yes. CISA added it to the Known Exploited Vulnerabilities catalog on October 28, 2026, and CrowdStrike reported that the China-nexus group WARP PANDA used it as a zero-day as late as early 2026.
Which ESXi builds fix CVE-2026-41709?
ESXi 9.1.0.0 build 25370933, ESXi 9.0.2.0100 build 25595025 and ESXi 8.0 Update 3j build 25429389, plus VMware Cloud Foundation 5.2.4. Later builds include the fix.
Why is a CVSS 2.7 bug on the KEV list?
KEV lists bugs with evidence of real-world exploitation, regardless of score. This one needs admin access, so the score is low, but attackers used it to hide their activity on compromised hypervisors.
Is there a workaround for CVE-2026-41709?
No. Broadcom lists no workaround. Forwarding ESXi logs to a remote syslog server does not fix the bug, but it keeps a copy of what is logged out of the attacker's reach.
Does CVE-2026-41709 affect ESXi 7.0?
Broadcom's response matrix for this CVE lists ESX 9.1, 9.0 and 8.0, Cloud Foundation 5.x and Telco Cloud Platform 5.x. ESXi 7.0 is not listed and has no fixed build for it.
Timeline
- Before July 29, 2026: Per CrowdStrike, WARP PANDA exploits the bug as a zero-day, as late as early 2026.
- July 29, 2026: Broadcom publishes VMSA-2026-0006 with fixes, rated Low (2.7).
- August 18, 2026: CISA adds the vCenter bug CVE-2026-59310 from the same advisory to KEV.
- October 28, 2026: CrowdStrike publishes its 2026 Legal Threat Landscape Report naming the zero-day use. CISA adds CVE-2026-41709 to KEV, due November 11.
The HOL Guard evidence pack for CVE-2026-41709 keeps the source record. Also added to KEV today: Fragnesia, the Linux kernel bug behind the PHP2Shell firewall intrusions.
