What happened

• CVE-2026-41709 is an insufficient-logging flaw in VMware ESXi (CVSS 2.7). It can let an actor with admin access perform certain operations without being logged. [S1]
• CrowdStrike reports that Warp Panda exploited it as a zero-day in early 2026 in intrusions at US organizations, including law firms. [S1][S2]
• Per CrowdStrike, Warp Panda gains initial access via internet-facing edge devices, pivots to vCenter, and deploys BRICKSTORM and SharpStorm. [S1][S2]
• In some cases the actor harvested cloud session tokens. In at least one case it registered a new MFA device on a compromised account. [S1]
• CISA added the CVE to KEV. FCEB agencies must patch by 2026-11-11. [S1][S2]

Timeline

Detect

ESXi/vCenter audit-log continuity gaps · ESXi/vCenter syslog (hostd, vpxa)

index=* ("hostd" OR "vpxa") earliest=-90d | sort 0 host _time | streamstats current=f last(_time) as prev_time by host | eval gap_min=round((_time-prev_time)/60,0) | where gap_min>60 | eval gap_start=strftime(prev_time,"%F %T"), gap_end=strftime(_time,"%F %T") | table host gap_start gap_end gap_min

A hit means: An ESXi/vCenter host stopped producing management-agent logs for over an hour. This is consistent with, but does not prove, admin activity hidden by the flaw or log tampering. Correlate the gap with admin sessions and maintenance windows.

New MFA method registered on M365 accounts · M365 Unified Audit Log / Entra ID audit

index=* (Operation="User registered security info" OR Operation="User registered all required security info" OR (Operation="Update user." AND "StrongAuthenticationMethod")) earliest=-90d | stats count min(_time) as first max(_time) as last values(ClientIP) as src_ip by UserId Operation | convert ctime(first) ctime(last)

FROM logs-* | WHERE @timestamp >= NOW() - 90 days | WHERE event.action IN ("User registered security info", "User registered all required security info") OR (event.action == "Update user." AND message LIKE "*StrongAuthenticationMethod*") | STATS count = COUNT(*), first = MIN(@timestamp), last = MAX(@timestamp), src_ip = VALUES(source.ip) BY user.id, event.action

A hit means: An MFA method was added to an account. It is suspicious if the user did not initiate it, if it came from an unfamiliar IP, or if it followed a session from an unusual location. This matches the reported rogue-MFA tradecraft.

Verify

• For log gaps: check the host's uptime, reboot and maintenance records, and syslog forwarder health. Planned patching, host reboots and collector outages produce the same gap.
• Compare vCenter task/event history against ESXi host logs for the same window. Admin changes visible on one side but absent on the other support a true positive.
• For MFA registrations: confirm with the user out of band. Benign look-alikes are new-phone enrolments, helpdesk resets and onboarding.
• Check whether the MFA registration session shares an IP or token with other anomalous sign-ins. Token reuse from a new location points to harvested session tokens.

Scope

Affected

• VMware ESXi, Cloud Foundation, vSphere Foundation, Telco Cloud Platform (CVE-2026-41709; per pipeline exposure data citing Broadcom July 2026 advisory)

Only if

• Attacker already has admin access to the affected component. [S1]

Not affected if

None stated by the sources.

Fixed in: ESXi-9.0.2.0100-25595025; ESXi-9.1.0.0-25370933 (VCF/VVF); ESXi80U3j-25429389; VMware Cloud Foundation 5.2.4 (per pipeline exposure data; verify against Broadcom advisory)

Enumerate

• All ESXi hosts and their build numbers versus the fixed builds
• vCenter instances, and which accounts hold admin rights on vCenter and ESXi
• Internet-facing edge devices that can reach the management network (the reported initial-access path) [S1]
• M365/Entra accounts with MFA methods added since early 2026
• Cloud session tokens issued to admins of the virtualization stack

Contain

• Restrict ESXi/vCenter management interfaces to a dedicated admin network. Review which edge devices can reach them.
• Ensure ESXi and vCenter logs forward off-host now, and preserve existing logs and vCenter appliance images before changes.
• Apply the fixed ESXi/VCF builds. Patching does not restore activity that already went unlogged.
• For suspected accounts: export audit records first, then remove unrecognised MFA methods, revoke sessions/refresh tokens and reset credentials. Revocation and removal destroy live session evidence and cannot be undone.
• Rotate vCenter and ESXi admin credentials if any hit is confirmed.

Eradicate

• Hunt vCenter and related systems for BRICKSTORM and SharpStorm. [S1]
• Remove rogue MFA devices and invalidate harvested cloud session tokens. [S1]
• Investigate and remediate the edge device used for initial access. [S1][S2]

Recover

• Before restoring trust in vCenter/ESXi, validate the patched builds, confirm admin accounts, and confirm logging continuity end to end.
• Monitor for new MFA registrations, admin sign-ins from new IPs, and fresh gaps in ESXi/vCenter logs.
• Keep the edge-device and vCenter management traffic under watch for re-entry.

Re-enter the loop when

• CrowdStrike or another vendor publishes IoCs for BRICKSTORM, SharpStorm or Warp Panda infrastructure
• A specific edge-device CVE is named as the initial-access vector
• Broadcom revises the affected versions or fixed builds
• Reporting shows victims outside the US or legal sector, including financial services
• Any confirmed log gap or rogue MFA registration in your environment

Debrief

• Record when ESXi/vCenter logs were last continuously forwarded off-host, and any gaps found.
• Record which admin accounts and MFA registrations were reviewed, and the outcomes.
• Gap: the sources do not say which ESXi operations go unlogged.
• Gap: the sources give no IoCs or persistence details for BRICKSTORM or SharpStorm.
• Gap: the sources do not name the edge devices exploited for initial access.

Detection coverage — checked automatically

Checked automatically 2026-11-10 21:16Z from public sources: 17 published, 28 nothing found, 0 not machine-checkable, 0 failed. "Nothing found" means the public source answered and had nothing, as of that moment; a feed covers only its newest posts. Re-checked daily.

Exposure queries — generated automatically

Where each CVE comes from: CVE-2026-41709 — CISA adds VMware ESXi CVE-2026-41709 to KEV; China-nexus Warp Panda used it as zero-day to reduce audit visibility; CVE-2026-59309 — CISA adds VMware ESXi CVE-2026-41709 to KEV; China-nexus Warp Panda used it as zero-day to reduce audit visibility; CVE-2026-59310 — CISA adds VMware ESXi CVE-2026-41709 to KEV; China-nexus Warp Panda used it as zero-day to reduce audit visibility. A product row answers "is the software from that story reachable from the internet", not "is this card about that software".

vuln:CVE-2026-41709

vuln:CVE-2026-59309

vuln:CVE-2026-59310

cpe:"cpe:/a:vmware:vcenter_server"

product:"Vcenter Server"

host.services: (software.product = "Vcenter Server")

http.title:"vSphere Web Client"

http.title:"VMware vCenter Server"

http.html:"VMware vSphere Client"

product:"VMware vCenter Server"

product:"VMware ESXi"

Internet-wide count, trend

Shodan's count of matching services on the whole internet, one point a day; the scope (your ranges) is never part of it. A count moves with Shodan's crawl as much as with patching, so read the direction, not the digit.

NVD names 1 more affected product (libraries and embedders); the CVE query covers them where Shodan has fingerprinted the version.

Banner spellings: a model read 5 from the NVD names and this card's text (former and marketing names, console titles); 5 matched something on Shodan and are shown above, the rest were dropped.

Scope every query in your own tool, never in a shared document: Shodan `net:<your_ranges>`, `org:"<your_org>"` or `hostname:<your_domain>` (or a Shodan Monitor network alert, which applies the scope for you); Censys `host.ip: <your_ranges>` or `host.dns.names: <your_domain>`. Then compare the banner version with the affected range. Generated automatically 2026-11-10 21:16Z from the CVE ids and NVD's CPE configurations, each Shodan query counted against Shodan itself; re-built daily with the coverage check.

Open questions

• The day-one story listed CVE-2026-59309 and CVE-2026-59310, which neither source supports. What are they, and are they related?
• The fixed builds and Broadcom July 2026 advisory come from pipeline exposure data, not a numbered source. Confirm them against Broadcom directly.
• Which specific operations does the flaw leave unlogged?
• Has CrowdStrike published IoCs or its primary report?
• Are financial-sector organisations among the victims? The sources mention US organizations and law firms only.

Sources

• [S1] https://thehackernews.com/2026/10/china-linked-hackers-exploited-vmware.html · The Hacker News
• [S2] https://www.securityweek.com/chinese-hackers-quietly-used-low-severity-esxi-logging-flaw-as-zero-day/ · SecurityWeek

Public OSINT only. AI-generated by the pipeline; structure follows the DAIR model from Dynamic Incident Response (Joshua Wright). Published automatically; a dismissed draft unpublishes it.