A suspected China-nexus advanced persistent threat (APT) group is actively exploiting CVE-2026-59310 — a critical directory-traversal vulnerability in Broadcom's VMware vCenter Server carrying a CVSS score of 9.8 — to gain arbitrary code execution on vCenter appliances and deploy a Babuk-derived ransomware payload against downstream ESXi infrastructure. This is not a theoretical risk: exploitation is confirmed in the wild, the vulnerability is pre-authentication and network-reachable, and the endgame is full virtualization-layer encryption. If vCenter is exposed in your environment, treat this as an active incident-response scenario, not a routine patch cycle.
I've led IR engagements where the virtualization layer was the blast radius multiplier. When an adversary controls vCenter, they don't just own one server — they own the management plane for your entire compute estate. The combination of a 9.8 pre-auth traversal and ransomware deployment tells you exactly what this actor's playbook looks like: initial access for espionage, monetization or destruction as a secondary objective. Defenders need to move on this today.
Technical Analysis
Affected Products and Severity
| Attribute | Detail |
|---|---|
| CVE | CVE-2026-59310 |
| CVSS v3.1 | 9.8 (Critical) |
| Affected Product | Broadcom VMware vCenter Server (VCSA) |
| Vulnerability Class | Directory traversal (CWE-22) leading to arbitrary code execution |
| Exploitation Status | Confirmed active in-the-wild exploitation by suspected China-nexus APT |
| Payload | Babuk-derived ransomware targeting ESXi-hosted workloads |
| Attribution | Suspected China-nexus APT (per cybersecurity researchers) |
How the Attack Works — Defender's View of the Kill Chain
Directory traversal in vCenter follows a well-understood pattern we've seen in prior virtualization-layer campaigns. Based on the reported behavior, the attack chain is:
- Initial Access (T1190 — Exploit Public-Facing Application): The attacker sends crafted HTTP requests to a vulnerable vCenter endpoint. The traversal sequences (e.g.,
../../variants, often URL-encoded or double-encoded to bypass naive filtering) escape the intended web root, allowing the attacker to read or write files outside the sanctioned path. - Code Execution: Write-access traversal into web-accessible directories on the VCSA appliance enables web shell deployment or direct command execution under the context of the vCenter service. The observable signature here is the
vpxdor web-service process spawning unexpected child processes —/bin/bash,sh,curl,wget, or python interpreters. - Persistence & Discovery: Dropped web shells in vCenter webapp directories, anomalous scheduled tasks or systemd units on the appliance, and enumeration of ESXi hosts via vCenter's management APIs.
- Impact (T1486 — Data Encrypted for Impact / T1489 — Service Stop): The Babuk-derived payload follows the classic Babuk-for-ESXi tradecraft: the operators (or their tooling) enumerate running VMs, forcibly power them off (via
vim-cmd vmsvc/power.offoresxcli vm process kill), then encrypt datastore files —.vmdk,.vmx,.vmsn,.nvram— rendering the estate unbootable. Babuk's leaked builder spawned an entire ecosystem of derivatives, so do not expect a single static hash to save you; behavioral detection on the encryption workflow is the durable control.
Why This Is Worse Than a Typical Web CVE
vCenter sits at a trust apex. Compromise of the appliance gives an adversary legitimate API pathways to every managed ESXi host — meaning lateral movement doesn't look like lateral movement. It looks like administration. This is precisely why nation-state actors prize the virtualization management plane, and why your detection strategy must focus on behavioral anomalies (unexpected child processes, off-hours VM power operations, traversal strings in logs) rather than network IOCs alone.
Detection & Response
The detections below target the observable behaviors in this campaign: traversal attempts against vCenter, anomalous process execution on the VCSA appliance, and the ESXi-side ransomware staging behavior characteristic of Babuk derivatives. Tune the host/scope fields to your asset inventory before deploying.
---
title: VMware vCenter Directory Traversal Exploitation Attempt (CVE-2026-59310)
id: 3f9a1c4e-7b2d-4e58-a6c1-9d0e2f5b8a31
status: experimental
description: Detects directory traversal sequences in HTTP requests targeting VMware vCenter services, consistent with exploitation of CVE-2026-59310. Source from reverse-proxy, load balancer, or web logs ingested for vCenter.
references:
- https://thehackernews.com/2026/08/suspected-china-nexus-actor-exploits.html
- https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/15
tags:
- attack.initial_access
- attack.t1190
logsource:
category: webserver
detection:
selection_uri:
cs-uri|contains:
- '../'
- '..%2f'
- '%2e%2e'
- '..%252f'
- '%252e%252e'
- '..\'
filter_vcenter_scope:
cs-host|contains:
- 'vcenter'
- 'vcsa'
condition: selection_uri and filter_vcenter_scope
falsepositives:
- Rare; traversal sequences in URIs against vCenter are almost never legitimate. Verify scanner traffic from authorized vulnerability management tools.
level: high
---
title: Suspicious Child Process Spawned by VMware vCenter Services
id: 8c2e5b71-4a9f-4d36-b7e2-1f6a0c3d9e84
status: experimental
description: Detects vCenter service processes (vpxd, rhttpproxy, vmware-envoy, java) spawning shells or download/execution tooling on the VCSA appliance, indicating post-exploitation activity following web shell deployment.
references:
- https://thehackernews.com/2026/08/suspected-china-nexus-actor-exploits.html
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/15
tags:
- attack.execution
- attack.t1059.004
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|contains:
- 'vpxd'
- 'rhttpproxy'
- 'envoy'
- 'vmware'
- 'java'
selection_child:
Image|endswith:
- '/bash'
- '/sh'
- '/dash'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
- '/python'
- '/python3'
- '/perl'
condition: all of selection_*
falsepositives:
- Legitimate vCenter health scripts and some update workflows spawn shells from service parents. Baseline per-appliance and alert on net-new parent/child pairs.
level: high
---
title: ESXi Mass VM Power-Off and Datastore Encryption Staging (Babuk-Derived Behavior)
id: b47d0f29-6e13-4c85-a2d4-5b9c7e1f3a60
status: experimental
description: Detects command patterns associated with Babuk-derived ESXi ransomware staging, including mass VM termination via esxcli/vim-cmd and manipulation of datastore or core dump settings ahead of encryption.
references:
- https://thehackernews.com/2026/08/suspected-china-nexus-actor-exploits.html
- https://attack.mitre.org/techniques/T1489/
- https://attack.mitre.org/techniques/T1486/
author: Security Arsenal
date: 2026/08/15
tags:
- attack.impact
- attack.t1486
- attack.t1489
logsource:
category: process_creation
product: linux
detection:
selection_kill:
CommandLine|contains:
- 'esxcli vm process kill'
- 'vmsvc/power.off'
- 'vim-cmd vmsvc/getallvms'
selection_storage:
CommandLine|contains:
- 'system coredump partition set'
- 'esxcli storage filesystem'
condition: 1 of selection_*
falsepositives:
- Individual VM power operations by administrators are normal. Alert on velocity and source — multiple kills in a short window, or execution outside approved automation accounts/change windows.
level: critical
// Hunt: Directory traversal attempts against vCenter + anomalous service child processes (last 14 days)
// Requires vCenter/VCSA syslog via CEF or Syslog collector, and web/proxy logs where available.
// Part 1: Traversal patterns in vCenter syslog/web logs (CVE-2026-59310 exploitation attempts)
Syslog
| where TimeGenerated > ago(14d)
| where Computer has_any ("vcenter", "vcsa") // tune to your vCenter appliance hostnames
| where SyslogMessage has_any ("../", "..%2f", "%2e%2e", "..%252f", "%252e%252e")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, HostIP
| order by TimeGenerated desc;
// Part 2: vCenter services spawning shells or transfer/execution tooling (post-exploitation)
Syslog
| where TimeGenerated > ago(14d)
| where Computer has_any ("vcenter", "vcsa")
| where SyslogMessage has_any ("vpxd", "rhttpproxy", "envoy")
and SyslogMessage has_any ("/bin/bash", "/bin/sh", "curl", "wget", "nc ", "python", "perl")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;
// Part 3: ESXi-side Babuk staging — mass VM kill / power-off velocity per host
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceProduct has_any ("ESXi", "VMware")
| where Message has_any ("vm process kill", "power.off", "getallvms")
| summarize KillEvents = count(), DistinctCmds = dcount(Message) by DeviceName, bin(TimeGenerated, 10m)
| where KillEvents > 5
| order by KillEvents desc;
-- Hunt VCSA/ESXi endpoints (where Velociraptor is deployed) for post-exploitation
-- indicators tied to CVE-2026-59310 and Babuk-derived ransomware staging.
-- Part 1: Suspicious processes — shells and transfer tools spawned on virtualization hosts
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(curl|wget|nc |ncat|python|perl|base64)'
OR Name =~ '(bash|sh|dash)$'
-- Part 2: Hunt for web shells dropped into vCenter webapp/service directories
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=[
'/usr/lib/vmware-*/**/*.jsp',
'/usr/lib/vmware-*/**/*.war',
'/var/log/vmware/**/*.sh'
])
WHERE Mtime > ago('30d')
ORDER BY Mtime DESC
-- Part 3: Outbound connections from virtualization hosts to non-management infrastructure
SELECT Pid, Name, Path, Status, Family, Type,
Laddr, Lport, Raddr, Rport
FROM netstat()
WHERE Status =~ 'ESTAB'
AND NOT Raddr =~ '^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)'
Response Priorities
- Assume breach until proven otherwise. If your vCenter was internet-reachable or reachable from less-trusted segments during the exposure window, initiate a compromise assessment in parallel with patching — do not patch-and-forget.
- Review vCenter log retention now. Confirm
/var/log/vmware/and reverse-proxy logs are being shipped off-box. On-appliance logs are the first thing a competent operator tampers with. - Snapshot integrity check. Babuk-derived tooling and adjacent actors routinely delete or encrypt snapshots. Verify snapshot chains and, critically, verify your backups are offline/immutable and restorable — run a test restore of at least one critical VM this week.
- Isolate at the hypervisor management layer. If ESXi encryption behavior is detected, sever vCenter-to-host management connectivity for affected hosts and preserve volatile data before rebooting anything.
Remediation
Patch Immediately
Broadcom has released a patch for CVE-2026-59310. Actions:
- Identify your exact vCenter build: In the vSphere Client, navigate to Menu → Administration → System Configuration, or run
shellon the appliance and check the build banner. Confirm against the fixed builds listed in the official advisory. - Apply the update from the official source only: Consult the Broadcom security advisory for CVE-2026-59310 at https://support.broadcom.com/web/ecx/security-advisory and the VMware vCenter Server release notes for your version train. Download patches exclusively from the Broadcom support portal — ransomware-adjacent campaigns routinely poison search results for hot CVEs.
- Verify post-patch: Confirm the build number incremented, re-run external scans against the management interface, and validate that traversal probes now return 4xx responses.
- Monitor CISA KEV: Given confirmed in-the-wild exploitation and a 9.8 score, expect this CVE to land in the CISA Known Exploited Vulnerabilities catalog with a federal remediation deadline — track https://www.cisa.gov/known-exploited-vulnerabilities-catalog and apply KEV-style urgency (patch within days, not weeks) regardless of whether you're bound by BOD 22-01.
Verify and Harden — vCenter / ESXi
#!/bin/bash
# CVE-2026-59310 vCenter/ESXi verification and hardening checks
# Run on VCSA via: Command> shell (enable shell first if needed)
set -u
echo "=== [1] Current vCenter version/build — compare against Broadcom fixed builds ==="
vpxd -v 2>/dev/null || cat /etc/vmware/.buildInfo 2>/dev/null || true
echo "=== [2] Recently modified files in vCenter webapp directories (web shell hunt) ==="
find /usr/lib/vmware-* /etc/vmware-* -type f \( -name '*.jsp' -o -name '*.war' -o -name '*.sh' \) -mtime -30 -ls 2>/dev/null
echo "=== [3] Suspicious shell/transfer process lineage ==="
ps auxf | grep -Ei 'bash|sh -i|curl|wget|nc |python|perl' | grep -viE 'grep|vmware-(vmon|stats)|/usr/lib/vmware' || echo "No obvious anomalies"
echo "=== [4] Unexpected persistence — systemd units and cron modified recently ==="
find /etc/systemd/system /etc/cron* -type f -mtime -30 -ls 2>/dev/null
systemctl list-unit-files --state=enabled | grep -viE 'vmware|systemd-|dbus|sshd|cron|ntpd|chrony|rsyslog' || true
echo "=== [5] Outbound connections from the appliance to non-RFC1918 destinations ==="
netstat -tnp 2>/dev/null | grep ESTABLISHED | grep -viE '127\.0\.0\.1|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.' || echo "None observed"
echo "=== [6] Traversal probes visible in reverse-proxy logs ==="
grep -rEi '\.\./|\.\.%2f|%2e%2e|%252e%252e' /var/log/vmware/envoy/ /var/log/vmware/rhttpproxy/ 2>/dev/null | tail -50 || echo "No matches or logs unavailable"
echo "=== [7] HARDENING REMINDERS ==="
echo "- Restrict vCenter UI/API (443) to a dedicated management subnet via firewall"
echo "- Confirm vCenter has NO direct internet inbound exposure (check NAT/ACLs)"
echo "- Enforce MFA via IdP federation on vCenter SSO; audit local accounts"
echo "- Enable lockdown mode on ESXi hosts; require vCenter-mediated access"
echo "- Verify backups are offline/immutable and snapshots are intact"
If You Cannot Patch Immediately (Workarounds)
There is no substitute for the vendor fix on a 9.8 traversal-to-RCE, but while you schedule downtime:
- Block vCenter management interfaces (TCP 443) from all untrusted networks at the perimeter and internal segmentation firewalls. Limit to a jump-host/management VLAN only.
- Deploy WAF/reverse-proxy rules rejecting any request to vCenter containing decoded or encoded traversal sequences (
../,%2e%2e,%252e) — this mitigates naive exploitation but should be treated as a speed bump, not a fix; a determined APT will probe for filter bypasses. - Increase log verbosity and ship logs off-appliance so you retain forensic evidence if exploitation occurs before patching.
Strategic Hardening
- Segment the management plane. vCenter and ESXi management interfaces should never be reachable from user subnets, let alone the internet. This single control would have neutered the initial access vector in most environments.
- Immutable, tested backups. Babuk-derived ESXi ransomware is only an existential event if your recovery path is encrypted alongside production. Air-gap or immutability (object lock) is the control that changes the business outcome.
- Treat virtualization infrastructure as Tier 0. Apply the same credential hygiene, monitoring depth, and change control you apply to domain controllers.
The window between patch release and mass exploitation of virtualization-layer CVEs is now measured in hours. This campaign — nation-state initial access paired with commodity-derived ransomware — is the shape of what we're seeing across 2026. Patch the appliance, hunt for the behaviors above, and validate your recovery posture before you need it.
Related Resources
Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.