CVE-2026-41709: The ESXi Logging Flaw Warp Panda Used, and the Audit Records Most Hosts Never Wrote

ESXi keeps no audit records until an administrator turns them on. Broadcom's own hardening reference lists the installation default for Syslog.global.auditRecord.storageEnable as False, and the same for Syslog.global.auditRecord.remoteEnable, with Syslog.global.logHost undefined. Hold that default in mind while reading the newest entry in the Known Exploited Vulnerabilities catalog: CVE-2026-41709, an insufficient-logging flaw in VMware ESX, CVSS 2.7, added by CISA on October 28 with a November 11 remediation date. CrowdStrike reports that the China-nexus group it tracks as Warp Panda used it as a zero-day to reduce audit-trail visibility at legal-sector targets in the United States.

Two numbers in that paragraph disagree. A base score of 2.7 is the floor of the Low band, and Broadcom shipped the fix on July 29 inside VMSA-2026-0006, an advisory whose headline items were two 9.8 authentication bypasses in vCenter. Everybody patched for the 9.8s. The 2.7 is the one with evidence of exploitation behind it.

Which hosts this applies to

The affected hypervisor lines are ESX and ESXi 9.1.x, 9.0.x, 8.0 and 7.0, plus the Cloud Foundation, vSphere Foundation and Telco Cloud Platform packagings of the same builds. Fixed builds for this CVE are ESXi-9.1.0.0-25370933, ESXi-9.0.2.0100-25595025 and ESXi80U3j-25429389, with Cloud Foundation 5.2.4 and the Telco products handled through Broadcom KB449886. There is no workaround.

If every workload you run sits on EC2 instances, Azure virtual machines, or somebody else's managed platform, you operate no hypervisor and nothing below applies to you. Stop here. If you own the metal - the three-host cluster in a colo cage, the pair of hosts in the back room of a sixty-person law firm, the single box an MSP installed in 2019 and has patched twice since - then you have two separate pieces of work, and only one of them is the patch.

The November 11 date is a federal deadline under BOD 26-04 and carries no legal weight for a private company. The catalog row also sets forensic triage to No, so even an agency is not obliged to go hunting on this entry. Go and look at the configuration anyway, because the patch restores a log that most hosts were never writing.

What a 2.7 buys an attacker

Broadcom's description is one sentence: "A malicious administrator could exploit this issue to perform certain operations without them being logged." The NVD record carries CWE-778 and the vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N. Read the fields and the low score explains itself: confidentiality and availability impact are none, the integrity impact is Low, and privileges required are High. The integrity being damaged is the integrity of the record, and the attacker already holds administrative rights when they reach for it.

That is why this never belonged in a patch-priority queue sorted by score, and why it ended up in KEV anyway. CISA's SSVC assessment on the entry reads exploitation active, automatable no, technical impact partial. The scoring system is measuring the wrong axis. A post-exploitation capability widens no doors. It extends how long an intruder stays behind the one they already opened, and dwell time is the entire business model of an espionage actor.

Neither Broadcom nor CrowdStrike has published which operations go unlogged, and no indicator list accompanies the reporting. Treat any article that tells you exactly which ESXi calls were suppressed as speculation. What is documented is the provenance: the advisory credits the finding to Ian Barton of CrowdStrike, the same vendor that reported the intrusions, which puts the discovery in casework rather than a bug bounty.

Where the logging flaw sits in the Warp Panda sequence

Warp Panda, also tracked as UNC5221, Armory Castle, Clay Typhoon and VerdantBamboo, has been working against the information technology, legal and manufacturing sectors since 2022. Singapore's IMDA republished CrowdStrike's technical findings in an ICM sector advisory, and the sequence it describes is worth reading in full if you run vSphere. The short version:

The pattern the advisory documents

• Initial access on internet-facing systems, then a pivot into vCenter using valid credentials or known vCenter bugs, specifically CVE-2024-38812, CVE-2021-22005 and CVE-2023-34048.
• BRICKSTORM, a Go backdoor built for VMware management servers, deployed on vCenter and disguised as legitimate processes such as updatemgr and vami-http.
• Two further Go implants for ESXi hosts, Junction and GuestConduit, plus JSP web shells for continued access.
• Lateral movement over SSH using privileged management accounts, vpxuser among them.
• Operational security measures: log clearing and manipulation, file timestamp modification, and creation of short-lived virtual machines that were never registered in vCenter.

Later reporting adds cloud session-token theft for Microsoft 365 access that raises no credential alert, and in at least one intrusion the registration of an attacker-controlled MFA device so access survived a password reset. Mandiant separately attributed the BeyondTrust Remote Support zero-day CVE-2026-102764, in the catalog since October 16, to the same actor.

Patching CVE-2026-41709 removes one item from that list. The item above it, log clearing, needs no vulnerability at all when the records live on a disk the intruder administers.

Read the audit configuration off every host

Start with the state of the logging, not the state of the patch. From a host shell, two commands answer it:

esxcli system auditrecords get
esxcli system syslog config get

The first returns four fields: AuditRecordRemoteTransmissionActive, AuditRecordStorageActive, AuditRecordStorageCapacity and AuditRecordStorageDirectory. Broadcom warns that reaching them over SSH means opening SSH logins on the host, so for anything larger than two hosts do it from vCenter instead. This is read-only and needs no more than a read-only role:

# esxi-audit-posture.ps1 - report audit-record and syslog state for every host
# vCenter knows about. Read-only. Requires PowerCLI and Connect-VIServer.
$settings = @(
  'Syslog.global.auditRecord.storageEnable',
  'Syslog.global.auditRecord.remoteEnable',
  'Syslog.global.auditRecord.storageCapacity',
  'Syslog.global.logHost'
)

Get-VMHost | Sort-Object Name | ForEach-Object {
  $vmhost = $_
  $v = @{}
  Get-AdvancedSetting -Entity $vmhost -Name $settings |
    ForEach-Object { $v[$_.Name] = $_.Value }

  [pscustomobject]@{
    Host        = $vmhost.Name
    Build       = $vmhost.Build
    AuditLocal  = $v['Syslog.global.auditRecord.storageEnable']
    AuditRemote = $v['Syslog.global.auditRecord.remoteEnable']
    CapacityMiB = $v['Syslog.global.auditRecord.storageCapacity']
    LogHost     = if ($v['Syslog.global.logHost']) { $v['Syslog.global.logHost'] } else { 'NONE' }
  }
} | Sort-Object AuditRemote, Host | Format-Table -AutoSize

Three columns decide what you are looking at. A host reporting AuditLocal False wrote none of the records this CVE suppresses, which makes the configuration change the real work and the patch a formality for that host. A host with AuditLocal True and AuditRemote False keeps its records in a fixed-size buffer on the host, 4 MiB by default in /scratch/auditLog, oldest entries overwritten first, on a machine whose administrator account is exactly what the attacker holds. LogHost reading NONE means nothing leaves the box at all, audit records or otherwise.

Enable the records, then move them off the host

The ordering here has a trap in it. Broadcom's guidance is to configure persistent scratch storage before setting any auditRecord parameter or logDir, because a scratch relocation afterwards leaves vmsyslogd unable to find the audit directory after a reboot. The target directory must also not already exist, or the enable fails with an invalid-location error. Capacity cannot be reduced once raised, and raising it above the host profile's value breaks profile remediation, so pick the number once. The DISA STIG baseline is 100 MiB.

# 1. Persistent storage first, then the directory, then the enable.
esxcli system auditrecords local set --directory=/vmfs/volumes/datastore1/auditLog --size=100
esxcli system auditrecords local enable

# 2. Point syslog at a collector you control, then enable remote audit records.
esxcli system syslog config set --loghost='tcp://siem.internal:514'
esxcli system syslog reload
esxcli system auditrecords remote enable

# 3. Confirm, and read the local buffer back.
esxcli system auditrecords get
/bin/viewAudit | tail -n 50

Settings beginning with Syslog.global.auditRecord take effect immediately; the rest of the syslog options need the reload. For a pull-based collector, the FetchAuditRecords method on the DiagnosticsManager managed object returns the same records through the API. Use ssl:// rather than tcp:// if your collector terminates TLS, and remember that a hypervisor forwarding to a collector inside its own cluster is a dependency loop; the collector should not be a virtual machine running on the hosts it audits.

Three checks that survive an administrator who can suppress entries

1. Alert on the silence

Every control above fails against an intruder with host administrative rights unless something notices when the stream stops. An absence-of-events rule per host is the detection with the best survival odds, because suppressing records produces exactly the signature it watches for:

index=vmware sourcetype=vmware:esxlog
| stats latest(_time) AS last_seen BY host
| eval silent_minutes = round((now() - last_seen) / 60, 1)
| where silent_minutes > 20
| sort - silent_minutes

2. Watch vpxuser and host SSH

vCenter uses vpxuser to manage hosts, so authentications from the vCenter appliance address are expected and everything else is not. Alert on vpxuser activity sourced from any other address, on SSH sessions to a host, and on the SSH service being enabled at all. In a small estate that last one should be a zero-volume alert between maintenance windows.

3. Reconcile host inventory against vCenter

The advisory records unregistered virtual machines created and torn down after use. A machine missing from the vCenter inventory is still visible to the host that runs it, and its files are still on a datastore:

# On a host: every VM the host itself has registered
vim-cmd vmsvc/getallvms

# Across the estate: every .vmx on every datastore, to diff against Get-VM
Get-Datastore | ForEach-Object {
  $ds = $_
  Get-ChildItem -Path ("vmstore:\" + $ds.Datacenter.Name + "\" + $ds.Name) -Recurse `
    -Filter *.vmx -ErrorAction SilentlyContinue |
    Select-Object @{n='Datastore';e={$ds.Name}}, Name, LastWriteTime
}

Diff both lists against Get-VM output. A .vmx with a recent write time and no inventory entry is worth a morning.

Point every hypervisor at a log host you control

Install the fixed build during your next window; it is one line in a quarterly patch run and it closes a gap you will never see used. Then do the part that changes your position: enable audit records on every host, raise the capacity once, forward to a collector that lives outside the cluster, and put a silence alert on each host's stream. A fleet with that configuration would have produced evidence of the Warp Panda sequence whether or not CVE-2026-41709 had ever been patched, and a fleet without it will produce nothing for the next intrusion either. If your detection pipeline has never had a hypervisor log source onboarded, that is the gap worth a conversation about your SIEM coverage rather than another patch ticket.