CISA: VMware vCenter CVE-2026-59310 Is Now a Ransomware Bug — Unauthenticated Root via Syslog Traversal

Introduction

CISA spent the weekend of September 13–14 updating the Known Exploited Vulnerabilities catalog to flag CVE-2026-59310 as used in ransomware campaigns. That is the new fact this week. The underlying bug is not new: Broadcom patched it on July 29 as a CVSS 9.8 directory traversal in the vCenter Syslog server. Unauthenticated attackers with network access get arbitrary code execution. QUIRSO later mapped 361 victim IPs in 47 countries, with reverse SSH persistence, and subsequent reporting described Babuk-derived ESXi encryptors dropping .babyk files. If you still have an unpatched or previously exposed vCenter, this is no longer an APT-only story.

What Happened

Broadcom advisory VMSA-2026-0006 (updated as .1 on August 3) describes CVE-2026-59310 as a path traversal in vCenter's Syslog server. No workaround exists. Fixed builds:

  • vCenter 9.1: 9.1.0.0300
  • vCenter 9.0: 9.0.2.0100
  • vCenter 8.0: 8.0 U3k or 8.0 U2f depending on branch
  • VMware Cloud Foundation 5.x: asynchronous patch to vCenter 8.0 U3k

The same advisory covered CVE-2026-59309, a CVSS 9.8 authentication bypass in VMware Directory Service (VMDir).

Exploitation started about five days after disclosure. QUIRSO watched compromised appliances call attacker infrastructure from August 3, with a surge on August 4, and 361 victim IPs by August 7. The observed chain on a vCenter Server Appliance: abuse syslog path handling to land content under /etc/cron.d (root, no login), stage the open-source reverse_ssh framework plus a linuxFile WebSocket backdoor, drop a JSP webshell in the Perfcharts app, grant the perfcharts service account passwordless sudo, harvest the vCenter machine-account credential, create extra vSphere SSO administrators, then encrypt ESXi VMFS. Large VMDKs were only partially encrypted (first 512 MB) and renamed with the .babyk extension associated with Babuk-derived ransomware.

CISA added CVE-2026-59310 to KEV on August 18 with a three-day federal clock. The September KEV update is the ransomware-use flag. Shadowserver still tracks 450-plus vCenter instances on the internet. CISA has now tagged 26 VMware CVEs as exploited over five years; nine of those have ransomware campaign use.

Why It Matters

vCenter is the control plane for the datacenter. Root there is root on every attached ESXi host's management path, every VM, every backup job the appliance can see. Ransomware crews figured this out years ago and built ESXi-specific encryptors; CISA saying this CVE is now in that playbook is the difference between "patch when you can" and "treat unpatched as an incident."

The syslog-to-cron.d primitive also means there may be no authentication event to hang a SIEM alert on. If your hunt is "failed logins on vCenter," you will miss this.

Who Is Affected

  • VMware vCenter Server 8.0 prior to U3k / U2f, 9.0 prior to 9.0.2.0100, 9.1 prior to 9.1.0.0300
  • VMware Cloud Foundation / vSphere Foundation trains called out in VMSA-2026-0006
  • Any appliance that was network-reachable — including "internal only" — before the patch was applied
  • ESXi hosts managed by those vCenters, plus every VM and backup sitting on their datastores
  • Internet-exposed vCenter (Shadowserver's 450+) — highest urgency

How to Protect Yourself

1. Confirm the running vCenter build and upgrade to the VMSA-fixed release. There is no workaround.

# VCSA shell
shell
vpxd -v
# or
rpm -q vpxd

Apply 9.1.0.0300, 9.0.2.0100, or 8.0 U3k/U2f per your branch. VCF 5.x: follow Broadcom's async patch to 8.0 U3k.

2. Hunt as if the box may already be owned, even after a successful upgrade. Highest-signal places:

# VCSA
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron
find /etc/cron.d -type f -mtime -60 -ls

# reverse_ssh / unexpected sshd children, outbound from vpxd/syslog
ss -tnp | grep -Ei 'ssh|vpxd|syslog'
ps aux | grep -Ei 'reverse_ssh|linuxFile'

# extra SSO admins
# from a workstation with PowerCLI:
# Get-SsoPersonUser | Where-Object { $_.AdminRoles }

Look for JSP under the Perfcharts application directory, passwordless sudo for service accounts, and new local or SSO administrators you did not create. QUIRSO published a generic YARA rule for reverse_ssh client binaries; it also matches legitimate use, so treat hits as leads.

3. On ESXi, look for Babuk-style artifacts if vCenter looks dirty:

# ESXi ESXCLI / SSH
find /vmfs/volumes -name '*.babyk' -o -name '*babyk*' | head
vim-cmd vmsvc/getallvms

Snapshot/isolate before you power through a recovery. Rotate vSphere SSO, ESXi root, backup-job, and AD service accounts that vCenter could reach.

4. Take vCenter off the internet. Management via VPN or dedicated jump hosts only. Put syslog listeners on a dedicated network. Subscribe to Broadcom VMSA and treat vCenter/ESXi advisories as emergency changes. CISA has now said ransomware crews are in this CVE; unpatched internet vCenter is a waiting encryptor.

Source