Inside CVE-2026-59310: Root Cause Analysis of the VMware vCenter RCE Vulnerability

CVE-2026-59310 Root Cause Analysis 

A critical VMware vCenter vulnerability, CVE-2026-59310, was actively exploited in the wild within days of its disclosure. It’s giving attackers a permanent back door into sensitive, virtualized infrastructure. Some vulnerabilities never see the light of day in actual exploitation, but that is not the case here. As of August 14th 2026, about 361 systems have already been compromised across 47 countries [2].  

CVE-2026-59310 is a critical directory traversal vulnerability in the VMware vCenter Syslog Server. It was disclosed along with a few other serious vulnerabilities in the VMware ecosystem on July 29th, 2026. To describe it simply: an unauthenticated attacker with network access to the vCenter appliance can craft a specially formatted request that traverses the filesystem. This in turn can allow for the execution of arbitrary code as root on the host. 

Some reports state that CVE-2026-59310 is being exploited in conjunction with CVE-2026-59309, an authentication bypass vulnerability that was also announced in VMSA-2026-0006.1 [1]. Based on Vali Cyber’s analysis, CVE-2026-59309 is NOT required for an attacker to successfully exploit CVE-2026-59310. 

Broadcom received the report privately and released an emergency patch the same day it disclosed the flaw. There were no workarounds and no mitigations. Just: patch now. 

Vali Cyber analyzed the vulnerability in VMware vCenter Server 8.0U3e (build 24674346) and determined the root cause. 

 

Directory Traversal in /etc/rsyslog.conf 

The core issue resides in /𝚎𝚝𝚌/𝚛𝚜𝚢𝚜𝚕𝚘𝚐.𝚌𝚘𝚗𝚏, a configuration file for the rsyslog service. Rsyslog is a service that receives inbound syslog messages from applications. vCenter’s rsyslog has capabilities to receive logs for the various ESX hosts that it manages. Each ESX host has its log file placed in a separate directory and a separate file under the /𝚟𝚊𝚛/𝚕𝚘𝚐/𝚟𝚖𝚠𝚊𝚛𝚎/𝚎𝚜𝚡/ directory. These files are created using a capability called dynfiles, where a file path is dynamically generated by rsyslog based on the parameters from the incoming syslog message. In /𝚎𝚝𝚌/𝚛𝚜𝚢𝚜𝚕𝚘𝚐.𝚌𝚘𝚗𝚏, the following line exists to create log files for each ESX host: 

$template esxLoc,"/var/log/vmware/esx/%hostname%/%hostname%-syslog.log" 

This line has a directory traversal problem, because “hostname” is an untrusted input the attacker controls, and it is not escaped. This issue allows an attacker to create arbitrary directories in the filesystem with the name hostname, and arbitrary files with the name %hostname%-syslog.log. 

rsyslog.conf has another critical issue. It does not escape control characters due to the following line: 

$EscapeControlCharactersOnReceive off 

The lack of escaping enables an attacker to create multiline files, which is critical to achieve remote code execution (RCE). 

 

Achieving Remote Code Execution 

Attackers can leverage this vulnerability to achieve RCE by creating a file in the /𝚎𝚝𝚌/𝚌𝚛𝚘𝚗.𝚍 folder. This folder holds cronjobs that execute as a specified user on a recurring basis. So, an attacker can create a job that executes as root every minute. In practice, this capability is often used to establish communication with an attacker-controlled command and control server. This behavior has been observed in the wild: the reported campaign dropped a cron file whose name mimicked the vCSA syslog convention, ending in -syslog.log, which cron executed to pull down a second-stage backdoor before deleting itself [2]. 

The full attack chain provides reliable, unauthenticated remote code execution as root on the vCenter appliance, leading to the extremely high CVSS score of 9.8. It is trivially simple to exploit. Vali Cyber has developed a PoC. Due to the recency and severity of the issue, we will not publicly publish the PoC at this time.  

 

Why Does this Matter? 

  1. vCenter is the “Key” to Your Data Center

vCenter is like the centralized nervous system of a VMware virtual infrastructure. Compromised vCenter means control over: ESX hypervisors, Virtual Machines, and network protections. It also often means access to credentials and certificates, along with backup configs. If an attacker has vCenter access, they most probably have your entire virtual environment. 

  1. Directory Traversal Without Authentication

This vulnerability requires no authentication, just network access to the vCenter Syslog Server endpoint and a specially crafted syslog message.  Often out of necessity, vCenter appliances are exposed to management networks or, worse, to the internet (often through poorly configured NAT rules or VPN misconfigurations). When paired with something like a VPN exploit, an exploit like this can be very helpful to threat actors.  

  1. The Attack Window Was Barely Five Days

From disclosure and patch to first confirmed exploitation was barely five days [2]. In this age of AI-driven research and production, zero-day and n-day attacks are happening quicker than in the past. Even when vendors patch fast, the threat actors are faster. Most organizations do not have the time or resources to patch immediately when a patch becomes available, which introduces even higher risk for them, as they might be inadvertently walking into an active exploitation campaign the moment the patch went public. 

 

Immediate Actions 

If you run VMware vCenter, patch it now. 

Broadcom provided the following patched versions [1]: 

  • 9.1 > 9.1.0.0300  
  • 9.0 >  9.0.2.0100  
  • 8.0  > 8.0 U3k or 8.0 U2f (depending on branch)  

 

This shouldn’t be treated as optional since we’ve seen active exploitation of the issues solved in these patches.  

 

Can’t Patch Immediately? 

As stated above, patching immediately isn’t always possible. While there are no official workarounds or mitigations from Broadcom, there are still some measures you can take. 

  1. Isolate the vCenter Syslog Server from untrusted networks. Ensure it is not accessible from the internet or from networks that should not have management access to vCenter. 
  2. Restrict access to the Syslog Server endpoints using firewall rules or ACLs. You should only allow traffic from known, trusted management networks. 
  3. Audit vCenter logs for signs of directory traversal attempts or unusual authentication patterns. 
  4. Review outbound network connections from vCenter appliances. Any unexpected outbound SSH or tunnel connections should be treated as a confirmed compromise until proven otherwise. 

 

ZeroLock 

ZeroLock from Vali Cyber is currently the only preemptive security solution for the VMware ecosystem. As a security tool, it provides advanced behavior-based detection for Linux and hypervisor hosts to combat advanced attacks like these. 

In the campaigns exploiting CVE-2026-59310, the vCenter compromise is the entry point. The attacker’s goal is to pivot into the ESX estate and deploy ransomware on the hypervisors, which in the reported activity used a Babuk-derived payload that encrypts files with the .babyk extension [2]. Ransomware and unauthorized binaries executing on ESX hosts are exactly what ZeroLock is built to stop. ZeroLock delivers behavior-based runtime protection for Linux and hypervisor hosts, so when an attacker controls vCenter, the hypervisors they are trying to reach stay defended.

If you are concerned about your virtualized infrastructure, reach out to us for discussions around virtualization security, risk assessment and the threats facing virtual infrastructure.  

 

References 

[1] Broadcom, VMSA-2026-0006.1, VMware ESX, vCenter, Workstation, and Fusion updates address multiple vulnerabilities, 29 July 2026. https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017 

[2] The Hacker News (reporting QUIRSO analysis), Suspected China-Nexus Actor Exploits VMware vCenter Flaw, Deploys Babuk-Derived Ransomware, 17 August 2026. https://thehackernews.com/2026/08/suspected-china-nexus-actor-exploits.html