CISA lists VMware ESX CVE-2026-41709, rated Low by Broadcom, as exploited; CrowdStrike says it was a zero day

Ninety one days from fix to the exploited list, for a flaw scored 2.7

On 28 October 2026 CISA added CVE-2026-41709, which it names "Broadcom VMWare ESX Insufficient Logging Vulnerability", to its Known Exploited Vulnerabilities (KEV) catalogue, with a due date of 11 November 2026. Broadcom published the fix on 29 July 2026, so the listing came 91 days later and gives federal agencies 14 days (both derived). Broadcom, acting as the CVE Numbering Authority, scores the flaw CVSS 3.1 base 2.7, rated Low. That is the bottom of an advisory whose scores run from 2.7 to 9.8.

That is the oddity. A flaw its own vendor calls Low, which needs an administrator first, now sits on a list of vulnerabilities that CISA says have reliable evidence of exploitation. This briefing reads the records to say what the listing establishes and what it does not. It was read from 21:19 to about 21:50 GMT on 28 October 2026 from CISA's own data feed, alert and directive, the CVE and NVD records, Broadcom's FAQ and documentation, and CrowdStrike's blog. Broadcom's advisory page, VMSA-2026-0006, answers automated requests with a challenge page and was not bypassed, so its wording is taken from the CVE record Broadcom published and from Broadcom's own FAQ, not from the advisory itself.

What the record does not establish: CISA's entry describes the flaw and names no source of evidence. It does not say who exploited it, against how many hosts, or whether it was chained with another flaw. The one public account of exploitation found is CrowdStrike's. Its blog of the same day says the China nexus adversary it calls WARP PANDA exploited what it names an "ESXi command logging bypass", CVE-2026-41709, as a zero day in several intrusions at U.S. entities, as late as early 2026. That is an attributed vendor claim, taken from a summary of a report that was not read in full for this briefing. On interests: Broadcom sells VMware and scored the flaw it also fixed; CrowdStrike sells security products and tracks adversaries, and its blog is the claim.

What each source states, and what it leaves out

Six sources bear on the listing. The table sets what each states against what it does not. Every cell is taken from the saved page or data file named in the caption.

What "exploited" and "forensic triage" mean in CISA's rules

The directive in force is BOD 26-04, issued 10 June 2026. Its implementation guidance lists four conditions for a KEV addition: an assigned CVE ID, "reliable evidence of active exploitation in the wild", clear remediation or mitigation, and significant risk to U.S. government systems. CISA's KEV criteria page adds that active exploitation includes attempted exploitation as well as successful exploitation, and that the flaw's exploitability alone is not the test. The guidance says a public proof of concept is not required, and that a listing does not necessarily mean CISA is currently observing exploitation. It names security vendors, researchers and government partners as sources and says CISA reviews the evidence. So the listing is a statement that CISA judged some evidence reliable. The entry does not show it.

The forensic triage field has a narrower meaning than it sounds. In the directive, the words "& forensic triage" attach to the shortest, three day timeline: the agency must remediate within three days and also examine whether the asset is already compromised. This entry has a 14 day due date and forensic triage No. The sibling flaw in the same advisory, CVE-2026-59310, has three days and forensic triage Yes. Derived from the data file as downloaded: of 145 entries added from 10 June 2026, the directive's date, 116 carry a three day due date (94 with triage Yes, 22 No) and 29 carry 14 days, all with triage No. This entry is one of the 29.

CISA's due dates follow a response table in the directive that weighs whether the asset is publicly exposed, whether the flaw is listed, whether an attacker can automate every step, and how much control the exploit gives. The table is a figure on the directive page and was not read as text, so this briefing does not say which cell produced 14 days. The CISA data in the CVE record says automatable no and technical impact partial, which fits a flaw that needs an administrator first. Forensic triage No means CISA did not attach the triage requirement to this listing. It does not say that no host was compromised, and the notes field gives no triage steps.

Five flaws in one advisory, and two on the exploited list

Broadcom's FAQ lists five CVEs in VMSA-2026-0006 and rates the advisory as a whole Critical. The scores and products below are from the CVE records Broadcom published; the KEV column is from the CISA data file read on 28 October. SecurityWeek reported on the advisory's release that Broadcom was not aware of exploitation, and on 13 August BleepingComputer reported that a digital forensics firm, QUIRSO, saw exploitation of CVE-2026-59310 from 3 August, five days after disclosure.

Two of the five are listed, and they sit at opposite ends of the score range. The highest rated flaw on the ESX side, the VM escape, is not listed. A rating of 9.3 or 2.7 describes what a flaw does by itself. It says nothing about which flaws attackers have used. The listing of the vCenter flaw is the better fit to the reported campaign. The listing of the logging flaw is the one that needs the CrowdStrike claim to explain it.

Zoom

Nothing read links the 3 August campaign against vCenter to CrowdStrike's account of WARP PANDA, and nothing read says either used the logging flaw against the other's victims. BleepingComputer says QUIRSO believes an advanced persistent threat actor is responsible and notes it gave no evidence for that. The two stories share an advisory and nothing else on the record.

What an attacker needs first, and what the gap hides

The CVE record gives the vector as network reachable, low complexity, high privileges required, no user interaction, with no confidentiality or availability impact and a low integrity impact. Broadcom's description says "a malicious administrator" could perform "certain operations" without them being logged. So the flaw is not a way in. It is a way to leave less behind once an administrator on an ESX host is already acting. How that access is obtained is not stated anywhere read.

Which operations go unlogged, and in which log, is also not stated. Broadcom's documentation lists the host's logs: auth.log for authentication events, hostd.log for the host agent, and shell.log for commands typed into the ESX Shell, among others. CrowdStrike's label, a "command logging bypass", points toward command records, but that is CrowdStrike's wording and not Broadcom's description of the defect. One managed security provider, Socura, goes further and writes that the flaw lets an attacker disable monitoring without audit records. That is the provider's extrapolation. Broadcom's wording stops at "certain operations".

Zoom

One inference follows, labelled as one. Broadcom's syslog documentation says that when ESX generates a message it writes it to the log file on the host and also forwards it to every configured collector. If an operation is never written, forwarding has nothing to send. Sending logs off the host still matters, because it protects records that exist from later deletion, but it cannot be relied on to close this particular gap. Whether the unlogged operations leave any trace elsewhere, for example in vCenter's records, is not stated.

The friendly name check: Low, logging, ESX and builds

Low is not a statement about use. The score is a function of what the flaw does by itself: privileges required high, integrity impact low, nothing else. It does not price what the flaw lets an intruder avoid recording. CISA's own guidance makes the same point about labels: its implementation guidance says CVSS ratings such as critical or high do not prescribe specific actions, which is why the directive uses timelines instead.

Insufficient logging sounds like hygiene. It is filed as CWE-778 and scored on integrity. In an investigation, missing records are what let an intruder's activity be disputed or missed. CrowdStrike calls it a command logging bypass and says it was exploited; neither it nor CISA says what the flaw was used to hide.

ESX is not a new product, and a build is not a version. Broadcom's FAQ says the hypervisor was renamed from ESXi to ESX with VMware Cloud Foundation 9.0, that the two terms may be used interchangeably, and that patch and build identifiers still carry the ESXi prefix. So CISA lists "VMware ESX" while the fixed builds read ESXi-9.1.0.0-25370933. The advisory's affected and fixed values are build strings, not product versions, so a host's build number is the thing to check.

The minimum build for this flaw is not the build to aim for. The CVE records give different fixed builds per flaw. For CVE-2026-41709 the fixed builds are ESXi-9.1.0.0-25370933 for 9.1 and ESXi80U3j-25429389 for 8.0. For the VM escape, CVE-2026-47876, they are ESXi-9.1.0.0200-25557999 and ESXi80U3k-25595708. A host patched only to the logging fix on those two branches would still be below the VM escape fix (derived from the records). Broadcom's FAQ says patches are cumulative, so the newest listed build covers all the ESX flaws.

What defenders do, in order

The steps below use Broadcom's own documentation, CrowdStrike's published recommendations and CISA's directive. Where a step is this site's inference, it says so. CISA recommends that every organisation, not only federal agencies, prioritise KEV listings.

What is not established

One more caveat bears on the headline fact. CrowdStrike dates the use to "as late as early 2026", which is before Broadcom's fix of 29 July 2026 and, on its own wording, before the flaw was public. It does not say when the use began, so it does not follow that the flaw was used for 91 days after the fix. The 91 days measure the gap between the fix and the listing, nothing more.

Technical details

Each block below is copied from the source named in its caption on 28 October 2026. None of CISA, Broadcom or CrowdStrike publishes indicators of compromise, a detection rule or exploit detail for CVE-2026-41709, and none is printed here. The blocks give the listing's fields, the record's vector and builds, the commands Broadcom prints for checking builds and forwarding logs, and the hardening list CrowdStrike published for this adversary in December 2025.

The KEV entry. This is the machine readable listing federal agencies track. The fields that matter for a defender are the due date, the ransomware field and the forensic triage field. The notes field holds links only.

cveID: CVE-2026-41709
vendorProject: Broadcom
product: VMware ESX
vulnerabilityName: Broadcom VMWare ESX Insufficient Logging Vulnerability
dateAdded: 2026-10-28
shortDescription: Broadcom VMWare ESX contains an insufficient logging vulnerability that could allow a malicious actor with admin access to perform certain operations without being logged.
dueDate: 2026-11-11
knownRansomwareCampaignUse: Unknown
forensicTriage: No
cwes: CWE-778

The CVE record. The vector string is what produces 2.7. Reading it left to right: network, low complexity, high privileges required, no user interaction, scope unchanged, no confidentiality impact, low integrity impact, no availability impact. The second block is the data CISA added the same day.

title: ESX insufficient logging vulnerability
datePublic: 2026-07-29T04:30:00.000Z
datePublished: 2026-07-30T12:45:02.292Z
dateReserved: 2026-04-22T06:21:34.490Z
problemType: CWE-778 Insufficient logging
cvssV3_1: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N  baseScore 2.7  LOW
description: VMware ESX contains an insufficient logging vulnerability. A malicious administrator could exploit this issue to perform certain operations without them being logged.
source discovery: UNKNOWN

SSVC (CISA Coordinator, version 2.0.3), timestamp 2026-10-28T19:50:06Z
Exploitation: active
Automatable: no
Technical Impact: partial
KEV dateAdded: 2026-10-28

The affected products and fixed builds in the record. A host whose build string is lower than the fixed value for its branch is affected. These are the CVE record's values, not the advisory's response matrix, which was not readable.

ESX 9.1.x.x   lessThan ESXi-9.1.0.0-25370933
ESX 9.0.x.x   lessThan ESXi-9.0.2.0100-25595025
ESX 8.0       lessThan ESXi80U3j-25429389
Cloud Foundation 9.1.x.x, 9.0.x.x   affected
Cloud Foundation 5.x   lessThan 5.2.4
vSphere Foundation 9.1.x.x, 9.0.x.x   affected
Telco Cloud Platform 5.1.x, 5.0.x   affected

Checking the build. Broadcom's FAQ prints this PowerCLI line for ESX hosts. Run it against vCenter and compare the Build column with the fixed values above and in the other ESX records.

Get-VMHost | Select-Object Name,Version,Build

Forwarding logs. Broadcom's documentation prints the esxcli form below and warns that using esxcli requires SSH on the host, which it calls a security risk and not recommended. It also says to run the reload command after setting each parameter. The vSphere Client route is the documented alternative.

esxcli system syslog config set --loghost=<str>
esxcli system syslog reload

Where ESX writes records. These are the paths Broadcom's vSphere 9.0 documentation lists. Which of them, if any, carries the gap for this flaw is not stated.

/var/log/auth.log     all events related to authentication for the local system
/var/log/hostd.log    the agent that manages and configures the ESX host and its virtual machines
/var/log/shell.log    a record of all commands typed into the ESX Shell and shell events
/var/log/syslog.log   general log messages
/var/log/vpxa.log     the agent that communicates with vCenter

How a shell session reads in the two logs. Broadcom's knowledge base article shows the correlation: a login in auth.log gives a process number, and the same number prefixes the commands in shell.log. A defender comparing logs sees whether a session has a login but no commands, or the reverse. Whether that is the pattern this flaw produces is not stated.

auth.log:
YYYY-MM-DD HH:MM:SS sshd[12345]: Accepted publickey for root from 10.11.12.13 port 2605 ssh2
YYYY-MM-DD HH:MM:SS sshd[64386]: Session opened for 'root' on /dev/char/pty/t0

shell.log:
YYYY-MM-DD HH:MM:SS shell[64386]: Interactive shell session started
YYYY-MM-DD HH:MM:SS shell[64386]: cd /var/log

Hardening for this adversary. CrowdStrike published this list on 4 December 2025, before CVE-2026-41709 was public; the post does not mention the CVE. It is the list its October 2026 blog points defenders to for WARP PANDA, so it is included as published and not as a fix for the flaw.

Monitor for the creation of unsanctioned VMs
Retain and monitor ESXi and vCenter syslog
Audit unsanctioned outbound connections to unexpected network destinations
Consider disabling SSH access to VMware ESXi hosts
Monitor for SSH authentications, specifically authentications as root and vpxuser
Forward vSphere syslog to an external platform
Enable ESXi's execInstalledOnly enforcement setting
For ESXi versions 8.0 or later, deactivate shell access for the vpxuser account on ESXi hosts
Restrict outbound internet access from ESXi and vCenter
Install security patches for vSphere infrastructure

The question that exposes the gap

A Low score told defenders they could wait, and CrowdStrike now says that for at least one adversary the flaw was used as a zero day. The score was never a measure of that. The harder question is about the evidence you would have. If an administrator on one of your ESX hosts did something today that left no record on that host, which other log, in which system, would show it?

Key facts