Cybersecurity researchers have linked the exploitation of a newly patched security flaw in **Broadcom VMware vCenter** to a suspected China-nexus advanced persistent threat (APT). The attacks involve the exploitation of **CVE-2026-59310** (CVSS score: 9.8), a severe directory-traversal vulnerability in the **VMware vCenter Server** that could be weaponized by a malicious actor to execute arbitrary code. A fix for the flaw was released by **Broadcom** on July 29, 2026. German incident response company **QUIRSO** assessed with moderate confidence that the exploitation campaign targeting **CVE-2026-59310** is operated by a Chinese-speaking threat actor, likely working in the UTC+08:00 time zone, predominantly used in Chinese-speaking regions. "This assessment is based on the convergence of Chinese-language artifacts in attacker-created scripts, apparent reuse of research from a Chinese security publication, repeated operational use of Chinese-language tools and management software, victimology excluding mainland China, and activity patterns compatible with UTC+08:00 working hours," **QUIRSO** researchers **Maike Orlikowski**, **Çağatay Yürekli**, and **Denis Szadkowski** said. The activity, which commenced five calendar days after public disclosure of the flaw, is estimated to have compromised 361 unique victim IP addresses across 47 countries, with most infections scattered across Germany (55), the U.S. (41), Turkey (38), Iran (26), and France (25). ### Exploitation of CVE-2026-59309 One compromised **vCenter Server Appliance** analyzed by **QUIRSO** was targeted by both **CVE-2026-59310** and **CVE-2026-59309**, an authentication bypass that has also witnessed active scanning efforts. Evidence shows malicious activity consistent with the exploitation of **CVE-2026-59309** as early as August 1, 2026, followed by the creation of an administrative account on **vCenter**. No login events have been observed for the legitimate administrative account used to create this new account. The account creation originated from the IP address 146.59.252[.]178 and also involved **vSphere** discovery via the REST API on August 3 using User-Agent strings like "GoodMoodle-VCFleet/1.0," in an attempt to masquerade it as **VMware**-related activity.  **VCF Fleet** is a centralized management capability introduced by **Broadcom** in **VMware Cloud Foundation (VCF)** version 9.0 to deploy, scale, patch, and operate multiple **VCF** instances. It encompasses multiple components, including **VCF Operations**, **VCF Automation**, **vCenter**, **NSX Manager**, **vSphere Cluster**, and workload domains. **QUIRSO** stated there is no overlap between this activity and the chain of events involving the abuse of **CVE-2026-59310** on the same system starting August 3, adding the newly created "vcenter_admin" administrator account was not used in subsequent phases of the attack. ### Exploitation of CVE-2026-59310 For the exploitation of **CVE-2026-59310**, the first activity involved the **cron daemon** (aka **crond**) logging a malformed cron file called "zz-poc59310-syslog.log." In the next step, a curl command (or alternatively a wget command) is executed to retrieve a backdoor from "5.34.177[.]38:9861" and execute it, then remove the log file. The naming convention of the log file is significant as it directly references the **CVE** identifier and indicates it was a proof-of-concept (**PoC**) devised after details of the flaw became public knowledge. "The '-syslog.log' suffix also mirrors the **vCSA** remote syslog file naming convention, but the file appears under `/etc/cron.d` rather than the configured syslog output directory," **QUIRSO** explained. "This suggests that the **vCSA** syslog server was abused to place files in a privileged execution location. While some files were malformed and not executed by cron, at least one file successfully executed and placed the 'linuxFile' backdoor on the system." The **linuxFile** implant is designed to provide remote command execution capabilities to the attacker. It establishes a connection to its controller over a **WebSocket** channel to receive instructions, executes them through `/bin/sh`, and transmits the results back to the attacker. "The C2 [command-and-control] address is XOR-obfuscated and decoded at run-time, while communications are protected using the malware's own application-layer cryptography despite using an unencrypted `ws://` transport," **Szadkowski** told The Hacker News via email. "It also automatically reconnects on failure and contains routines for establishing persistence through **systemd** and cron." The threat actor behind the operation also relied extensively on cron to execute malicious payloads, including to fetch and run a shell script ("esxi.sh") from the IP address "185.144.28[.]120:3232." The shell script then serves as a downloader and persistence installer for an architecture-specific reverse **SSH** ("reverse_ssh") binary that's retrieved from the same infrastructure. Other cron jobs related to creating staging directories, downloading executables, changing their permissions, and running them, while referencing servers at "192.255.141[.]13:8080" and "5.34.176[.]100:5244." In what appears to be an operational security blunder, the latter has been found to expose the reverse **SSH** binaries toolset via an **AList** directory listing. A brief description of some of the various actions carried out by the threat actor is as follows: * Deploying "linuxFile" (aka systemlog or linux_x86), which connects to "ws://intel.se9ly9upbhay.shop:8080/ws" and establishes persistence via a **systemd** service. * Setting three cronjobs impersonating legitimate **VMware** services: `vmware-vpxd-stats-*` (facilitates an **SSH**-based remote access channel by adding the attacker's **SSH** public key to the authorized keys file), `vmware-perf-collect-*` (drops a **JSP** web shell named "vmware-perf-update.jsp"), and `vmware-perf-sync-*` (drops the same web shell and runs a Base64-encoded script that performs credential access and sets up a new account called "adminuser," which is then added to the **vSphere SSO Administrators** group. * Creating two additional accounts: adding "vcadmin" to **vSphere** with a Base64-encoded **Python** script dropped on disk via bash commands run in a cronjob and creating a **vSphere** admin account via an external **LDAP** "Add" operation against **vCenter's VMware Directory Service (vmdir)** from a remote client by using a pre-existing but compromised administrative account. * Creating a file named "`/etc/sudoers.d/vmware-perf`" with a configuration that grants the "perfcharts" service account unrestricted, non-interactive passwordless sudo access to root. * Running shell scripts like "`/tmp/.vmware-perf-upd.sh`" to obtain credentials for **vmdir** by querying the `HKEY_THIS_MACHINE\services\vmdir` registry location. If this method fails, it searches for **VMware's vmafd Python** module and calls `GetMachineName()`, `GetMachinePassword()`, and `GetDomainName()` to get the distinguished name and password associated with the **vCenter** machine account. The stolen credentials are used to conduct privileged directory modifications, including adding the aforementioned "adminuser" identity to the **Administrators** group. * Using **vSphere API** to perform discovery operations and "esxi.sh" to deploy the `reverse_ssh` client. * Creating local accounts on the **ESXi** hosts (e.g., "adminuser") to enable ransomware encryption. * Taking steps to evade detection, reduce forensic visibility, and blend into the **VMware** environment. The attack ultimately paves the way for the deployment of a ransomware on **ESXi** hosts that encrypts files with the ".babyk" extension, which is typically associated with **Babuk**-derived ransomware. It's not clear if this was the end goal of the campaign, or if the **Babuk**-derived payload was "selected opportunistically or even intentionally" to confuse attribution efforts. **QUIRSO** told the publication it cannot assess at this stage if the ransomware strain was deployed across other compromised systems as the analysis was limited to only one of the infected systems. However, based on the investigation so far, it's suspected that the deployment of the locker may not have been the primary objective in all cases.