For years, cybersecurity strategy has assumed organizations would have time to patch newly disclosed vulnerabilities before attackers could weaponize them. That assumption is rapidly breaking down. In 2025 alone, more than 48,000 CVEs were published, while the median disclosure-to-exploitation window for internet-facing infrastructure shrank to roughly 10 hours. Even more concerning, 28.93% of tracked exploits were observed before a CVE was publicly disclosed, leaving defenders with no patch available at all.
CVE-2026-59310, a critical VMware vCenter Server remote code execution vulnerability, demonstrates this reality. Although Broadcom released a patch on July 29, 2026, attackers began exploiting the flaw within just five days, ultimately deploying ransomware against ESXi environments worldwide. Modern attack timelines have become faster than traditional patch management processes can reliably support.
As attackers increasingly target hypervisors and critical virtualization infrastructure, organizations need controls that can protect systems during the gap between disclosure and remediation. Runtime exploit prevention, privileged access controls, and behavioral detection provide a preemptive layer of defense that can block exploitation attempts before patches are deployed, reducing exposure during the period when organizations are most vulnerable.
Vali Cyber analyzed CVE-2026-59310 in VMware vCenter Server 8.0U3e (build 24674346) to better understand how this attack path was exploited and how organizations can defend against similar threats moving forward.
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?
-
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.
-
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.
-
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.
What CVE-2026-59310 Tells Us About Modern Vulnerability Management
The security industry has long relied on patching as the primary response to newly disclosed vulnerabilities. Patching remains essential, but the assumptions behind that strategy are changing.
Vulnerability disclosures continue to climb, AI is accelerating both vulnerability discovery and exploit development, and the disclosure-to-exploitation window continues to shrink. Increasingly, the race is no longer between attackers and patch deployment. It’s between attackers and the beginning of the patching process.
CVE-2026-59310 demonstrates the reality of that shift. Broadcom released a patch on the day of disclosure, yet attackers were exploiting the vulnerability within days. The issue wasn’t patch availability. It was the gap between disclosure and deployment.
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.
- 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.
- Restrict access to the Syslog Server endpoints using firewall rules or ACLs. You should only allow traffic from known, trusted management networks.
- Audit vCenter logs for signs of directory traversal attempts or unusual authentication patterns.
- 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: Preemptive Hypervisor Security
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