This is the security camera going dark in the vault, but only the bank manager has the remote
CVE-2026-41709 is an insufficient logging flaw (CWE-778) in VMware ESXi that allows a malicious administrator to perform certain hypervisor operations without those operations being recorded in audit logs. It affects ESXi 8.0 (prior to Update 3j), ESXi 9.0.x (prior to 9.0.2.0100-25595025), and ESXi 9.1.x (prior to 9.1.0.0-25370933), as well as VMware Cloud Foundation 5.x (prior to 5.2.4). The flaw was discovered by Ian Barton of CrowdStrike and disclosed on 2026-07-30 as part of the broader VMSA-2026-0006 advisory, which also includes far more dangerous critical VM-escape and vCenter auth-bypass CVEs.
Broadcom rates this LOW at CVSS 2.7, and that rating is accurate. The vector (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N) tells the whole story: you need high-privilege (administrator) access to exploit it, the scope is unchanged, there is zero confidentiality or availability impact, and integrity impact is low — limited to the completeness of the log record itself. This is a forensic-evasion convenience for an attacker who already owns the hypervisor. It does not grant new capabilities, escalate privileges, or enable lateral movement. The vendor got this one right.
3 steps from start to impact.
Obtain ESXi administrator credentials
PR:H (privileges: high), meaning unprivileged or low-privileged users cannot reach this bug.- Valid ESXi administrator account (root or equivalent)
- Network access to the ESXi management interface
- ESXi management interfaces should be on isolated management VLANs, not routable from user segments
- MFA or smart-card auth on vCenter/ESXi reduces credential theft risk
- Obtaining ESXi admin credentials already implies a significant prior compromise
Perform unlogged hypervisor operations
- Active admin session on a vulnerable ESXi build
- Knowledge of which operations bypass logging
- The attacker already has full admin control — they can do anything on the host regardless of this CVE
- vCenter-level logging, SIEM forwarding, and network-level monitoring may still capture evidence of the operations
- No public PoC or detailed technical write-up exists to guide exploitation
Evade forensic investigation
- Attacker has already performed malicious operations they wish to hide
- Organization relies solely on ESXi local logs for hypervisor audit
- Mature environments forward ESXi logs to a SIEM in near-real-time; the gap only matters if the SIEM also misses the events
- Network-layer monitoring (NSX, firewall logs, NTA) would still capture traffic patterns
- vCenter task/event logs may independently record the same operations
The supporting signals.
| In-the-wild exploitation | None observed. Broadcom states no evidence of exploitation. Not listed on CISA KEV. |
|---|---|
| Proof-of-concept | None public. No PoC repos, blog posts, or researcher demonstrations found as of 2026-07-31. |
| EPSS score | Not yet scored by FIRST (disclosed 2026-07-30, <48 hours old). Expected to be very low given the admin-only prerequisite and low impact. |
| KEV status | Not listed. No CISA KEV entry. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N — network-accessible but requires admin privileges. Integrity-only impact, low severity. No availability or confidentiality impact. |
| Affected versions | ESXi 8.0 (all builds before U3j), ESXi 9.0.x (before 9.0.2.0100), ESXi 9.1.x (before 9.1.0.0200), VCF 5.x (before 5.2.4), Telco Cloud Platform 5.0.x/5.1.x |
| Fixed versions | ESXi80U3j-25429389, ESXi-9.0.2.0100-25595025, ESXi-9.1.0.0-25370933, VCF 5.2.4, Telco Cloud per KB449886 |
| Exposure data | ESXi management interfaces are rarely internet-facing. Shodan/Censys historically show <5,000 directly exposed ESXi hosts globally — a tiny fraction of the installed base. The admin-auth prerequisite further narrows exposure to near-zero for external attackers. |
| Disclosure date | 2026-07-30, as part of VMSA-2026-0006 |
| Credit | Ian Barton, CrowdStrike |
noisgate verdict.
The single most decisive factor is the high-privilege prerequisite: exploitation requires an existing ESXi administrator account, meaning the attacker has already achieved full hypervisor control before this CVE becomes relevant. The flaw provides forensic evasion, not new attack capability — it cannot be weaponized to gain access, escalate privileges, or expand blast radius.
Why this verdict
- Admin-only prerequisite (PR:H): The attacker must already be an ESXi root/admin user. This is not a vulnerability that *gets you in* — it is a vulnerability that *helps you hide after you are already in*. This is the single largest downward pressure and justifies remaining at LOW.
- Impact ceiling is log integrity only: CVSS confirms C:N/I:L/A:N with S:U. No confidentiality breach, no availability disruption, no scope change. The worst outcome is incomplete audit trail on one host.
- Role multiplier: ESXi is a canonical high-value hypervisor — yes, ESXi hosts run domain controllers, databases, and production workloads as VMs. However, this CVE does not enable VM escape, guest compromise, or any operational impact to hosted workloads. The blast radius of *missing log entries* on a hypervisor is limited to forensic fidelity, not to fleet compromise. The high-value-role floor (requiring outcomes of 'domain takeover / fleet compromise / mass data egfress / supply-chain pivot') does not trigger because the outcome is audit-trail degradation, not operational compromise.
- No PoC, no exploitation, no KEV: Zero evidence of weaponization. The flaw is a logging gap, which is inherently low-value to most threat actors who already have admin access (they can simply delete logs manually at that privilege level).
Why not higher?
Elevating to MEDIUM or above would require the vulnerability to either grant new capabilities or have a broader blast radius. It does neither. An ESXi admin can already manipulate or delete logs through legitimate administrative functions — this CVE merely reveals a specific gap in audit coverage for certain operations. There is no chaining potential that amplifies severity, no scope change, and no impact to confidentiality or availability.
Why not lower?
IGNORE would be inappropriate because the flaw does represent a real, if narrow, gap in audit controls on infrastructure that is often subject to compliance mandates (PCI-DSS, SOX, HIPAA). Organizations with regulatory logging requirements have a legitimate reason to patch. Additionally, the fix is bundled into the same ESXi update that addresses the critical CVE-2026-47876 VM-escape flaw, so most environments will pick it up incidentally.
What to do — in priority order.
- Ensure ESXi syslog forwarding to SIEM is active and validated — If ESXi logs are forwarded in real-time to an external SIEM (Splunk, Elastic, Sentinel, QRadar), the logging gap on-host is partially mitigated because the SIEM may capture events through alternative telemetry (vCenter events, network monitoring). Validate forwarding is working within the noisgate remediation window of 365 days.
- Cross-correlate vCenter task/event logs with ESXi host logs — vCenter independently records administrative operations. By correlating vCenter's task history against ESXi hostd.log, SOC teams can detect gaps where ESXi failed to log an operation that vCenter recorded. This is a detective control, not preventive.
- Restrict ESXi management interface access to jump hosts — Limit network access to ESXi management (port 443, SSH) to dedicated admin jump hosts with session recording. This adds an independent audit layer that the ESXi logging gap cannot suppress.
- Prioritize the bundled ESXi update for the critical CVEs in VMSA-2026-0006 — The same patch that fixes CVE-2026-41709 also fixes CVE-2026-47876 (VM escape, CRITICAL) and other severe flaws. Prioritize the update based on those critical CVEs — this LOW-severity logging fix comes along for free.
- EDR on VMs does not help — this is a hypervisor-level logging gap; guest-level EDR agents have no visibility into ESXi management-plane operations.
- Network segmentation alone does not help — while it limits who can reach the management interface, once an admin is authenticated, segmentation does not restore the missing log entries.
- vSphere Audit Trail (VCTA) does not help if only ESXi-local logging is affected — the gap is specifically in ESXi's own logging subsystem, though vCenter-level logging may independently capture some of the same events.
Crowdsourced verification payload.
Run this script on each ESXi host via SSH (requires root access) or remotely via ssh root@<esxi-host> 'sh -s' < check_cve_2026_41709.sh. It checks the ESXi build number against known-fixed builds.
#!/bin/sh
# check_cve_2026_41709.sh
# Checks if ESXi host is patched for CVE-2026-41709 (insufficient logging)
# Run as root on the ESXi host or via SSH.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
BUILD=$(vmware -v 2>/dev/null | grep -oE '[0-9]+$')
VERSION=$(vmware -v 2>/dev/null)
if [ -z "$BUILD" ]; then
echo "UNKNOWN - Could not determine ESXi build number."
exit 2
fi
# Fixed builds:
# ESXi 8.0 U3j: 25429389
# ESXi 9.0.2.0100: 25595025
# ESXi 9.1.0.0: 25370933
echo "Detected: $VERSION (build $BUILD)"
case "$VERSION" in
*"8.0"*)
if [ "$BUILD" -ge 25429389 ]; then
echo "PATCHED - ESXi 8.0 build $BUILD >= 25429389 (U3j)"
exit 0
else
echo "VULNERABLE - ESXi 8.0 build $BUILD < 25429389 (U3j)"
exit 1
fi
;;
*"9.0"*)
if [ "$BUILD" -ge 25595025 ]; then
echo "PATCHED - ESXi 9.0 build $BUILD >= 25595025"
exit 0
else
echo "VULNERABLE - ESXi 9.0 build $BUILD < 25595025"
exit 1
fi
;;
*"9.1"*)
if [ "$BUILD" -ge 25370933 ]; then
echo "PATCHED - ESXi 9.1 build $BUILD >= 25370933"
exit 0
else
echo "VULNERABLE - ESXi 9.1 build $BUILD < 25370933"
exit 1
fi
;;
*)
echo "UNKNOWN - Unrecognized ESXi version: $VERSION"
exit 2
;;
esacIf you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.