Skip to main content
CVE-2026-59310 Critical Patch Available

CVE-2026-59310: VMware vCenter Path Traversal Exploited Across 47 Countries

CVE Details

CVE ID CVE-2026-59310
CVSS Score 9.8
Severity Critical
Vendor Broadcom / VMware
Product vCenter Server
Patch Status Available
Published August 18, 2026
EPSS Score 45.9%
CISA Patch Deadline ⚠ August 21, 2026 Federal deadline passed

Background

vCenter Server is the central management plane for VMware virtualised environments — the console that provisions, configures, and monitors ESXi hosts and every virtual machine running on them. Compromise of vCenter is functionally compromise of the entire virtualisation estate it manages.

Broadcom disclosed CVE-2026-59310 on July 29, 2026: a directory traversal vulnerability in vCenter’s Syslog server component that lets an unauthenticated, network-adjacent attacker write files outside the intended directory structure, with a path to arbitrary code execution. CISA added it to the Known Exploited Vulnerabilities catalog on August 18, 2026, with a remediation deadline of August 21. By that point, exploitation had already been running for over two weeks — active attacks began August 3, just five days after public disclosure.

Technical Mechanism

CVE-2026-59310 lives in vCenter’s Syslog server, the component that ingests log messages from ESXi hosts and other infrastructure sources. A directory traversal flaw in how the service handles file paths for incoming log data allows a crafted syslog message to escape the intended log directory and write to arbitrary locations on the vCenter host filesystem.

The specific mechanics of the path traversal payload have not been made fully public, consistent with Broadcom’s disclosure approach for vCenter vulnerabilities historically. What is established is the outcome: an unauthenticated attacker with network access to the vCenter Syslog service can plant a file in a location of their choosing, and that write primitive is sufficient to achieve code execution on the host — a pattern common to traversal bugs that intersect with any component that later executes, imports, or loads written content (scheduled jobs, service configuration, plugin directories).

Broadcom lists no workaround for this vulnerability. Patching is the only remediation path.

Real-World Exploitation Evidence

The exploitation timeline here is unusually well documented for a vCenter flaw. A suspected advanced persistent threat actor began exploiting CVE-2026-59310 on August 3, 2026 — five days after the July 29 disclosure. Security researchers tracking the campaign identified rapid scaling: 151 new victims by August 4, growing to 361 unique victim IP addresses across 47 countries within roughly a week.

Victim concentration skewed toward Germany, the United States, Turkey, Iran, and France, together accounting for over half of confirmed compromises — a spread suggesting broad opportunistic scanning against internet-reachable or otherwise exposed vCenter instances rather than a narrowly targeted campaign.

The observed post-exploitation pattern: path traversal activity consistent with the vulnerability, followed by deployment of a malicious cron job to establish persistence. Attackers used reverse_ssh, an open-source reverse SSH tunnelling framework, to maintain remote command-and-control access to compromised hosts while potentially evading conventional firewall egress rules that would block more obvious C2 channels.

Impact Assessment

vCenter compromise gives an attacker administrative reach over the entire managed virtualisation environment — the capability to create, modify, clone, or destroy virtual machines; extract VM disk images (and any credentials or data they contain); and pivot into every network segment reachable from managed hosts. For most enterprise environments, vCenter is one of the highest-value targets on the network precisely because of that blast radius.

Specific to this campaign:

  • Persistent remote access via reverse_ssh survives simple network filtering and may not trigger conventional outbound C2 detection
  • A compromised vCenter host is a pivot point into every ESXi host and VM it manages
  • Cron-based persistence means a reboot or patch alone does not guarantee remediation — the planted persistence mechanism must be located and removed
  • Given the geographic and volume spread of victims, treat internet-reachable or loosely segmented vCenter deployments as a high-probability target regardless of organisation size or sector

Affected Versions

ProductAffectedFixed Version
vCenter Server 9.1prior to 9.1.0.03009.1.0.0300
vCenter Server 9.0prior to 9.0.2.01009.0.2.0100
vCenter Server 8.0prior to U3k / U2f branch fix8.0 U3k or U2f (branch-dependent)
VMware Cloud Foundationbundled vCenter versions as aboveapply corresponding VCF patch
VMware Telco Cloud Infrastructure / Platformbundled vCenter versions as aboveapply corresponding vendor patch

Remediation Steps

  1. Patch immediately to the fixed vCenter build for your branch — 9.1.0.0300, 9.0.2.0100, or the appropriate 8.0 U3k/U2f update. There is no supported workaround; patching is the only remediation.

  2. Assume compromise if exposed since August 3 and your instance was unpatched. Given the scale of the campaign (361+ confirmed victims), any internet-reachable or loosely firewalled vCenter instance running an affected version during this window should be treated as potentially compromised pending investigation.

  3. Hunt for reverse_ssh persistence, specifically unexpected cron jobs on the vCenter appliance and outbound SSH-like connections to unfamiliar hosts. Review /var/spool/cron and systemd timers on the VCSA for unrecognised entries.

  4. Restrict Syslog service exposure. vCenter’s Syslog ingestion should not be reachable from untrusted networks. Segment it behind the same access controls applied to the vCenter management interface itself.

  5. Rotate credentials stored in or accessible from vCenter if compromise is confirmed or suspected — service account credentials, SSO integration secrets, and any stored ESXi host credentials.

Detection Guidance

Host indicators:

Check for unexpected cron entries or systemd timers on the vCenter Server Appliance that weren’t part of a known change. Look specifically for entries invoking ssh, curl, or unfamiliar binaries.

crontab -l (check all users, including root and service accounts)
ls -la /etc/cron.d/ /var/spool/cron/crontabs/

Network indicators:

Outbound SSH or SSH-like traffic from the vCenter appliance to unfamiliar external IP addresses is a strong reverse_ssh indicator, particularly on non-standard ports.

protocol:tcp AND src_ip:<vcenter_appliance_ip>
| stats count by dst_ip, dst_port
| where dst_port NOT IN (443, 902, 5480)

Log indicators:

Review vCenter Syslog service logs around and after August 3, 2026, for malformed or unusually structured log messages that may represent path traversal payloads — sequences containing repeated ../ patterns or absolute path indicators in fields expecting relative log paths.

Timeline

DateEvent
2026-07-29Broadcom discloses CVE-2026-59310 and releases patched versions
2026-08-03Active exploitation begins, five days post-disclosure
2026-08-04151 new victims identified in a single day
2026-08-07Total confirmed victims reach 361 across 47 countries
2026-08-18CISA adds CVE-2026-59310 to the Known Exploited Vulnerabilities catalog
2026-08-21CISA BOD 26-04 mandatory remediation deadline for federal agencies

References