TL;DR
- what: A suspected China-nexus APT is exploiting CVE-2026-59310, a CVSS 9.8 directory-traversal-to-RCE flaw in Broadcom VMware vCenter, to plant backdoors and Babuk-derived ransomware on vCenter Server Appliances.
- impact: 361 unique victim IPs across 47 countries are confirmed compromised, concentrated in Germany (55), the U.S. (41), Turkey (38), Iran (26), and France (25), with attackers gaining root-level execution and full vSphere administrative control over entire virtualization estates.
- fix: Apply Broadcom's July 29, 2026 vCenter fix for CVE-2026-59310 and the companion patch for the CVE-2026-59309 authentication bypass, then hunt for rogue vSphere SSO accounts and cron artifacts because patching alone does not evict an established foothold.
- who: Any organization running internet-reachable or loosely segmented VMware vCenter Server Appliances, particularly VCF 9.0 estates, with mainland China notably absent from the victim set.
A suspected China-nexus APT has converted a single VMware vCenter vulnerability into 361 confirmed footholds across 47 countries, and the endgame is Babuk-derived ransomware on the hypervisor management layer. German incident response firm QUIRSO tracked the campaign against CVE-2026-59310, a CVSS 9.8 directory-traversal flaw in Broadcom VMware vCenter Server that yields arbitrary code execution. Broadcom shipped the fix on July 29, 2026. Exploitation began five calendar days after public disclosure.
The victim distribution is broad rather than targeted: Germany (55), the United States (41), Turkey (38), Iran (26), and France (25) lead the count. Mainland China is absent from the victim set entirely, one of several factors driving QUIRSO's attribution.
vCenter is the wrong thing to lose. An attacker with root on a vCenter Server Appliance and membership in the vSphere SSO Administrators group owns every workload domain, every datastore, and every VM the appliance manages. Ransomware at that layer does not encrypt one server, it encrypts the platform the servers run on.
Attribution: moderate confidence, Chinese-speaking, UTC+08:00
QUIRSO researchers Maike Orlikowski, Çağatay Yürekli, and Denis Szadkowski assess with moderate confidence that a Chinese-speaking actor operating in UTC+08:00 runs the campaign. The assessment rests on converging indicators, not a single smoking gun:
- Chinese-language artifacts embedded in attacker-created scripts
- Apparent reuse of exploitation research published by a Chinese security outlet
- Repeated operational use of Chinese-language tooling and management software
- Victimology that excludes mainland China
- Activity patterns consistent with UTC+08:00 working hours
Note the confidence language. Moderate confidence means the indicators align but alternative explanations survive. Treat this as a threat actor profile to hunt against, not a diplomatic conclusion.
Two CVEs, one appliance, two unrelated operators
On at least one compromised vCenter Server Appliance, QUIRSO found evidence of a second flaw in play: CVE-2026-59309, an authentication bypass that is also drawing active internet-wide scanning. Activity consistent with CVE-2026-59309 exploitation appears as early as August 1, 2026, followed by creation of a vCenter administrative account named "vcenter_admin" from 146.59.252.178. No login events were logged for the legitimate administrative account credited with creating it, which is the signature of an authentication bypass rather than credential theft.
On August 3 the same operator enumerated vSphere via the REST API using the User-Agent string "GoodMoodle-VCFleet/1.0," a deliberate imitation of VCF Fleet, the centralized multi-instance management capability Broadcom introduced in VMware Cloud Foundation 9.0. QUIRSO found no overlap between this activity and the CVE-2026-59310 chain that started on the same host that same day, and the "vcenter_admin" account was never used in later phases. Two distinct operators, one appliance, inside 72 hours.
⚠️ Assume contested, not compromised-once — A vCenter appliance exposed long enough to be hit by CVE-2026-59310 was almost certainly also scanned for CVE-2026-59309. Scoping an incident around a single CVE will leave a second actor's persistence in place. Enumerate every account in the vSphere SSO Administrators group and correlate creation events against actual authentication logs for the creating account.
The CVE-2026-59310 chain: syslog to cron to root
The initial artifact is a malformed cron file that crond logged as "zz-poc59310-syslog.log." The name is self-documenting: it references the CVE directly and indicates a proof-of-concept built after public disclosure. The "-syslog.log" suffix mirrors the vCSA remote syslog naming convention, but the file lands in /etc/cron.d rather than the configured syslog output directory. QUIRSO's read is that the actor abused the vCSA syslog server as a write primitive to drop files into a privileged execution path. Several files were malformed and never ran, but at least one executed successfully.
That successful execution issued a curl (or wget) fetch against 5.34.177.38:9861 to retrieve and run a backdoor, then deleted the cron log file behind it.
linuxFile: a WebSocket implant with its own crypto layer
The payload, tracked as linuxFile and also seen as "systemlog" and "linux_x86," is a compact remote command execution implant. It opens a WebSocket channel to its controller, receives instructions, executes them through /bin/sh, and returns output over the same channel.
The tradecraft is better than commodity. Per Szadkowski, the C2 address is XOR-obfuscated and decoded at runtime, and communications use the malware's own application-layer cryptography despite riding unencrypted ws:// transport. That combination defeats naive string extraction and blunts TLS-inspection-dependent detection at the same time. The implant reconnects automatically on failure and carries built-in persistence routines for both systemd and cron. One observed C2 endpoint: ws://intel.se9ly9upbhay.shop:8080/ws.
Persistence disguised as VMware telemetry
The actor leaned heavily on cron and named its jobs to blend into vCenter's own performance and statistics tasks. Three impersonating cron jobs were observed:
- vmware-vpxd-stats-*: appends the attacker's SSH public key to authorized_keys, establishing an SSH remote access channel
- vmware-perf-collect-*: drops a JSP web shell named "vmware-perf-update.jsp"
- vmware-perf-sync-*: drops the same web shell, then runs a Base64-encoded script that performs credential access and creates an "adminuser" account added to the vSphere SSO Administrators group
Additional accounts including "vcadmin" were added to vSphere. Separate cron jobs fetched a shell script named "esxi.sh" from 185.144.28.120:3232, which acts as a downloader and persistence installer for an architecture-specific reverse_ssh binary pulled from the same infrastructure. Further staging jobs created directories, downloaded executables, chmod'd them, and executed them against 192.255.141.13:8080 and 5.34.176.100:5244.
That last host is an operational security failure worth noting: 5.34.176.100:5244 exposed the actor's reverse SSH toolset through an open AList directory listing. Defenders get free visibility into the toolkit; the actor gets a lesson in not running file browsers on staging infrastructure.
Hunt list — Grep /etc/cron.d for entries matching vmware-vpxd-stats-, vmware-perf-collect-, and vmware-perf-sync-, plus any file matching zz--syslog.log. Look for vmware-perf-update.jsp on the appliance, unexpected keys in root's authorized_keys, and unrecognized systemd services. Block and alert on the listed IPs and on ws:// egress from vCenter appliances, which should never initiate outbound WebSocket connections.
What to do now
Patch CVE-2026-59310 with Broadcom's July 29, 2026 release and apply the CVE-2026-59309 authentication bypass fix in the same window. Then accept that patching an appliance compromised on or after August 3 evicts nothing: the SSH keys, systemd services, cron jobs, JSP web shell, and rogue SSO accounts all survive a patch. Treat any vCenter appliance that was internet-reachable during the exposure window as needing full compromise assessment, and pull vCenter management off any network path an attacker can reach from the internet. A five-day gap between disclosure and mass exploitation is the operating tempo now, and vCenter is not a system you get to patch on a monthly cycle.
Originally published on RedEye Threat Intelligence.
