vCenter under siege: CVE-2026-59310 and why ransomware crews go straight for the hypervisor

An unauthenticated directory traversal in the vCenter Syslog server has moved from APT tooling to ransomware playbooks. Here is how to assure the virtualisation layer that everything else depends on.

Broadcom patched CVE-2026-59310 in VMware vCenter on 29 July 2026 and described the fix as an emergency. CISA added the vulnerability to its Known Exploited Vulnerabilities catalogue on 18 August 2026 and, within days, flagged that ransomware groups were using it. By mid-September, reporting described multiple ransomware operators exploiting the flaw to gain network access, and Shadowserver was still tracking more than 450 vCenter servers exposed on the internet.

The vulnerability

CVE-2026-59310 is a directory traversal in the vCenter Syslog server that enables unauthenticated arbitrary code execution. Researchers reported that a suspected advanced persistent threat actor began exploiting it first, deploying reverse SSH tooling, and that more than 361 compromised IP addresses across 47 countries were observed. Ransomware affiliates followed, as they reliably do once an exploit for widely deployed infrastructure becomes available.

Why the hypervisor is the prize

Ransomware operators learned several years ago that encrypting a few hundred virtual machines from the hypervisor is faster, quieter and more devastating than encrypting endpoints one by one. vCenter is the management plane for that layer. Compromising it gives an attacker:

  • inventory of every virtual machine, including domain controllers, backup servers and databases;
  • the ability to snapshot, clone or export VM disks, which is a data exfiltration path that bypasses in-guest controls;
  • the ability to power off, delete or encrypt datastores at scale;
  • credentials and tokens for integrations with backup, monitoring and automation platforms.

Endpoint detection rarely sees any of this. The hypervisor is below the operating systems it protects.

An assurance checklist for the virtualisation layer

Patching CVE-2026-59310 is necessary but not sufficient. These are the controls we verify in assessments and the gaps we most often find in incident response.

Exposure

  • vCenter and ESXi management interfaces must never be reachable from the internet. Access should pass through a hardened management network with multi-factor authentication.
  • Disable or firewall services that are not required, including Syslog receivers exposed beyond the management network.

Identity

  • Separate vCenter administrative identities from Active Directory domain administrators. A domain admin compromise should not automatically become a hypervisor compromise, and vice versa.
  • Enforce MFA for vCenter access and remove standing administrative rights in favour of time-bound elevation.
  • Review and prune service accounts used by backup, automation and monitoring tools; they are frequently over-privileged.

Backups

  • Keep backup infrastructure outside the virtualisation trust boundary, with immutable storage and credentials that vCenter administrators cannot read.
  • Test restoration of a domain controller and a core application from an isolated backup at least quarterly.

Visibility

  • Forward vCenter and ESXi logs to a SIEM and alert on new local accounts, SSH enablement, snapshot and export operations, datastore changes and logins from unexpected networks.
  • Baseline ESXi configuration and file integrity so that unexpected binaries, which are a hallmark of ransomware deployment, are detectable.

Response readiness

  • Document how to isolate the management network, revoke sessions and rebuild vCenter from a known-good image. During an incident is the wrong time to discover that the only person who knows the root password has left.

If you were exposed

If a vCenter server with the vulnerable build was reachable from the internet at any point between late July and the patch date, assume exposure. Preserve vCenter logs, ESXi logs and authentication records before they roll, look for reverse SSH tooling and new persistence on the appliance, and review hypervisor activity for snapshots or exports you did not initiate. If you find any of these, engage incident response before touching the environment further.

Sources

This article is provided for general information and reflects public sources and the authors' professional opinion at the date of publication. Vulnerability details and recommendations change quickly; validate them against vendor advisories and your own environment before acting.