There is a practical difference between compromising a server and compromising the thing that controls every server. VMware vCenter is the second category: it is the single pane of glass that administers the entire ESXi hypervisor fleet, holds domain credentials and talks to every virtual machine in the environment. On July 29, 2026 Broadcom published advisory VMSA-2026-0006 covering two critical flaws in it. Five days later, active exploitation was already running at global scale.
The two critical flaws in VMSA-2026-0006
CVE-2026-59310 is a directory traversal vulnerability in the vCenter syslog server, with a CVSS 3.1 score of 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and classified as CWE-22. An attacker with network access to vCenter, holding no credentials and requiring no user interaction, can execute arbitrary code. Its companion is CVE-2026-59309, also 9.8 with the same vector, an authentication bypass in the VMware Directory Service (vmdir) classified as CWE-303, incorrect implementation of an authentication algorithm. Both were published on the NVD on July 30, 2026.
- VMware vCenter 9.1.x before 9.1.0.0300, 9.0.x before 9.0.2.0100 and 8.0 before U3k
- VMware Cloud Foundation 9.1.x, 9.0.x and 5.x
- VMware vSphere Foundation 9.1.x and 9.0.x
- VMware Telco Cloud Infrastructure 3.0
- VMware Telco Cloud Platform 5.1.x, 5.0.x, 4.x and 3.0
The fix ships in VMware Cloud Foundation and vSphere Foundation 9.1.0.0300, in 9.0.2.0100 and in vCenter Server 8.0 U3k. There is no official workaround that replaces the patch, which means the only real answer is to update.
How the flaw is exploited
The vulnerable component is the syslog service of the vCenter Server Appliance. A log server is a classic and slightly ironic target: its entire job is to accept untrusted data from external sources and write that data to disk. When the destination file path is built from attacker-controlled content without normalization, a traversal sequence escapes the log directory and the service starts writing wherever the attacker wants. And a process that can write to any path on the system, running with high privilege, is code execution one indirect step away.
# Concept of the flaw (CWE-22), not a working exploit.
# The log destination is built from external input:
/var/log/vmware/syslog/<attacker_controlled_value>.log
# With no path normalization, the traversal sequence escapes the directory:
../../../../etc/cron.d/update
# Result: the body of the syslog message becomes the contents of a file
# under /etc/cron.d, and the appliance's own cron executes it.
# Arbitrary file write becomes command execution, with no memory exploit.It is worth noticing what this chain does not require. No memory corruption, no ASLR bypass, no shellcode. It is missing input validation on a file path, the same bug class that has existed since the 1990s, in a critical infrastructure product in 2026. That is exactly why file path review is still a mandatory checklist item in application pentest.
What happens after the first command
Telemetry published by QUIRSO, the German incident response firm that tracked the campaign, shows an operation far more organized than opportunistic scanning. After initial access, the attacker fetches the backdoor with curl or wget, installs an implant that opens a command and control channel over WebSocket, and secures persistence through several redundant paths at once.
- Redundant persistence: cron entries, systemd services and SSH key injection, plus reverse_ssh, an open source tool used to keep a reverse session open to attacker infrastructure
- Escalation: passwordless sudo configuration and creation of the attacker's own administrative accounts on the appliance
- Credential theft: direct extraction from vmdir, the directory that holds the identity of the entire vSphere environment
- Lateral movement: ESXi host discovery through the REST API and use of the vSphere API itself to operate on them
- Final impact: deployment of Babuk-derived ransomware on ESXi hosts, encrypting files with the .babyk extension
One detail in QUIRSO's analysis deserves attention from anyone doing incident response: the researchers suspect the ransomware may have been a distraction rather than the real objective. Encryption is loud by nature, it forces the victim to look at the incident. When it shows up at the end of a chain that already included directory credential theft and access to the virtualization API, it is worth considering that the extortion served to cover up whatever had already left the environment.
Five days between the patch and mass exploitation
QUIRSO detected the first compromised systems talking to command and control infrastructure on August 3, 2026, five calendar days after disclosure. Activity tied to CVE-2026-59309 had already appeared on August 1. In total there were 361 unique compromised IP addresses across 47 countries, concentrated in Germany (55), the United States (41), Turkey (38), Iran (26) and France (25). As of this post's publication neither flaw had been added to CISA's Known Exploited Vulnerabilities catalog, a useful reminder that absence from KEV is not evidence of absence of exploitation.
QUIRSO attributes the campaign, with moderate confidence, to a China-nexus actor, based on Chinese-language artifacts in the attacker's scripts, reuse of Chinese-origin research and tooling, victimology that excludes mainland China, and an activity pattern consistent with the UTC+08:00 time zone. Attribution is always probabilistic and does not change the technical response, but it helps calibrate expectations: a state-aligned actor with that level of organization does not leave the environment because the ransomware was contained.
Triage: how to tell whether you were already compromised
If your vCenter was exposed and unpatched at any point between July 29 and today, applying the update fixes the vulnerability but does not undo a prior compromise. This campaign's persistence survives the patch, because it no longer depends on the flaw. The minimum triage is to hunt for the persistence mechanisms described above, and it should come before you consider the case closed.
# Triage on the vCenter Server Appliance (read-only, changes nothing).
# 1. Installed version, to confirm whether it is patched
vpxd -v
# 2. Suspicious scheduled tasks (the most direct persistence vector)
ls -la /etc/cron.d/ /etc/cron.daily/
crontab -l
# 3. Recently created or modified systemd services
ls -lat /etc/systemd/system/ | head -20
# 4. SSH keys injected into any account
find / -name authorized_keys -type f -exec ls -la {} \; 2>/dev/null
# 5. Passwordless sudo rules added
grep -rn NOPASSWD /etc/sudoers /etc/sudoers.d/ 2>/dev/null
# 6. Local accounts created after the advisory date
ls -la /home/- Apply the patch first, but treat patching and triage as two separate tasks
- Take vCenter out of direct internet exposure, it should never be reachable outside the administration network
- Rotate vmdir credentials and vSphere service accounts if there is any sign of compromise
- Review administrative accounts on the appliance and on the ESXi hosts, looking for recent creation
- Confirm that ESXi host backups sit outside the reach of whoever administers vCenter
Why the virtualization layer deserves its own scope
In most pentest scopes we receive, the virtualization layer shows up as supporting infrastructure, when it shows up at all. The focus goes to the exposed application, the API, the perimeter. But vCenter concentrates three things at once: identity (through vmdir), execution control (through the vSphere API) and disk access to every virtual machine in the environment. Compromising an application server gives the attacker a server. Compromising vCenter gives them the data center.
The pattern repeating across recent critical cases is always the same: the highest-value target is not the most visible system, it is the system that administers the others. It is worth checking today whether your test scope includes the console that controls everything, or whether it got filed under internal network and was never actually tested.