Vulnerabilities

Warp Panda hid on ESXi with a 2.7-rated logging flaw

By Yaali. November 2, 2026, 6 min read, Vulnerabilities, Threat intel, Patching.

CISA lists ESXi bug CVE-2026-41709 as exploited after CrowdStrike tied it to China-nexus Warp Panda. Fixed builds, hunting steps and logging fixes.

CVE-2026-41709 is an insufficient logging flaw in VMware ESX, the bare-metal hypervisor Broadcom ships with vSphere and VMware Cloud Foundation (VCF). Someone who already holds administrator rights on a host can run certain operations without the host recording them. Broadcom fixed it on July 29 in advisory VMSA-2026-0006 and scored it 2.7, Low, so many teams never scheduled the update.

On October 28 CrowdStrike reported that Warp Panda, a China-nexus espionage group, had used the flaw as a zero-day in several intrusions at US organisations, including law firms, as late as early 2026. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog the same day, with a November 11 deadline for US federal civilian agencies. If you run ESX 8.0 or 9.x below the fixed builds, or if you ever closed an ESXi investigation because the host logs looked clean, this one applies to you.

How it works

ESXi keeps its own audit trail: shell and SSH activity, host management actions and the commands administrators run all land in local log files under /var/log, and in syslog if you forward it. Responders rely on that trail to reconstruct what happened on a hypervisor, because endpoint detection and response (EDR) agents do not run on ESXi itself.

The flaw is classed as CWE-778, insufficient logging. Broadcom's description says a malicious actor with administrative privileges may be able to perform certain operations without them being logged. CrowdStrike calls it an "ESXi command logging bypass". Neither company has published which operations escape the log, and no public proof of concept was known as of October 30, so the exact trigger is not public.

The CVSS 3.1 vector is AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N. Read plainly: it is reachable over the network, needs high privileges, and does nothing to confidentiality or availability. That is why it scored 2.7. The score measures what the bug grants on its own, and it grants nothing to an outsider. For an intruder who already has root or vpxuser (the account vCenter uses to manage each host), it removes the record that would later show what they did.

Security Affairs reported a 7.6 score and one French outlet 8.8. Broadcom's own figure, repeated by the Cloud Security Alliance (CSA) and Rescana, is 2.7.

What Warp Panda does

CrowdStrike has tracked Warp Panda since at least 2022 and published a profile of the group on December 4, 2025. Google attributes the same BRICKSTORM backdoor to a cluster it calls UNC5221. The group usually gets in through internet-facing edge devices, using Ivanti Connect Secure flaws CVE-2023-46805 and CVE-2024-21887 or F5 BIG-IP flaw CVE-2023-46747. From there it reaches vCenter with stolen credentials or the vCenter memory corruption bugs CVE-2023-34048 and CVE-2024-38812.

On the virtual estate it moves between vCenter and ESXi hosts over SSH as vpxuser and installs its own tooling:

• BRICKSTORM, a backdoor for long-term access to vSphere. Google reported in September 2025 that BRICKSTORM intrusions had an average dwell time of 393 days, often longer than the victims kept logs.
• Junction, a Go implant on ESXi that poses as a VMware service on port 8090, the port the real vvold service uses. It runs commands, proxies traffic and talks to guest VMs over VSOCK, the host to guest socket channel.
• GuestConduit, a Go implant inside guest VMs that listens on VSOCK port 5555 and tunnels traffic between guests and the hypervisor.

CrowdStrike also saw the group create VMs that were never registered in vCenter and shut them down after use, clone domain controller VMs to collect Active Directory data, and copy data out of snapshots of running guests. It clears logs and changes file timestamps. CVE-2026-41709 fits that pattern: a way to work on a host without leaving the entries a responder would look for. In Microsoft 365, the group has replayed stolen session tokens and registered its own MFA (multi-factor authentication) device on compromised accounts.

CrowdStrike gave no victim count, and Broadcom, CISA and CrowdStrike have published no indicators of compromise specific to this CVE.

What to do

1. Patch every host. The fixed builds in VMSA-2026-0006 are ESXi80U3j-25429389 for ESX 8.0, ESXi-9.0.2.0100-25595025 for VCF and vSphere Foundation 9.0.x, ESXi-9.1.0.0-25370933 for 9.1.x, and VCF 5.2.4 for VCF 5.x. Telco Cloud Platform 5.0.x and 5.1.x are covered in Broadcom KB 449886. Check the running build with vmware -vl on the host or in the vCenter host summary. Broadcom lists no workaround.
2. Plan for ESXi 7.0. It is not in the advisory's fixed version table, and CSA notes that Broadcom's later 7.0 guidance covered only Critical issues. Do not assume a 7.0 fix exists; schedule the upgrade and treat 7.0 hosts as unable to prove what admins did on them.
3. Send logs somewhere admins cannot edit. Forward ESXi and vCenter syslog in real time to a SIEM (security information and event management) or store that hypervisor administrators have no rights over, for example with esxcli system syslog config set --loghost='tcp://collector.example:514' and esxcli system syslog reload. Logs from a host that was already compromised stay untrustworthy after patching. CSA suggests keeping virtualisation logs for at least 13 months, given the 393-day dwell time.
4. Hunt without trusting the host. Compare the VM and file inventory on each datastore with what vCenter has registered, to find unregistered VMs. Look for listeners on port 8090 that are not vvold, and for VSOCK traffic between hosts and guests, including port 5555 inside guests. Review vCenter task and event history and network flow records for SSH sessions as root or vpxuser you cannot explain. The YARA and Sigma rules in the joint CISA, NSA and Canadian Cyber Centre BRICKSTORM report AR25-338A cover the backdoor itself.
5. Reopen old cases. Any ESXi investigation since 2025 that ended because the host logs were clean deserves a second look against independent evidence: flow logs, vCenter events, guest EDR and the edge device logs.
6. Harden the hosts. Disable SSH on ESXi where you can and alert on every SSH login. On ESXi 8.0 and later, remove shell access from vpxuser with esxcli system account set -i vpxuser -s false; keep at least one working root login first, because Broadcom notes some password reset procedures stop working once that shell is off. Turn on execInstalledOnly so only binaries from installed, signed packages run. Block outbound internet access from ESXi and vCenter, keep management interfaces on their own segment, and put vCenter sign-in behind an identity provider that enforces MFA.
7. Rotate what the hypervisor could see. If you find signs of access, rotate vCenter and ESXi admin credentials and API keys, and treat any cloned domain controller as a full Active Directory credential exposure.

Severity scores and the hypervisor blind spot

A 2.7 score sorted this fix to the bottom of most patch queues for three months while a state group used it. CVSS rates a flaw in isolation, and logging flaws only matter once someone is already inside, which is when you need the record most. When a fix touches audit, logging or authentication on infrastructure that EDR cannot see, such as hypervisors, firewalls and VPN appliances, patch it with the high-severity items regardless of the number.

Our security operations team builds hypervisor log pipelines and hunts vSphere estates for unregistered VMs and implants, and our safeguarding and hardening work applies the ESXi and vCenter settings above. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: Cloud Security Alliance research note, Rescana, Help Net Security, Security Affairs, SecurityWeek, The Hacker News, CrowdStrike, Unveiling Warp Panda, Google Threat Intelligence, BRICKSTORM, Broadcom KB 396941.