If your organization runs virtual machines, there is a good chance VMware vCenter sits somewhere behind the scenes managing them. It is the control tower for VMware environments: the single console that administrators use to manage every ESXi host, every virtual machine, and every piece of virtualized infrastructure in a data center. That central role is exactly what makes CVE-2026-59310 so serious. It is not a flaw in one application running on one server; it is a flaw in the system that manages all the servers.
The vulnerability, tracked as CVE-2026-59310, carries a maximum-severity CVSS score of 9.8. It allows an attacker with nothing more than network access to a vCenter instance, no username, no password, no prior foothold, to execute arbitrary code with system-level privileges. Broadcom patched it on July 29, 2026. Five days later, a threat actor began exploiting it in the wild, and by the time researchers finished counting, over 360 systems in 47 countries had been compromised. On at least one of those systems, the intrusion ended with ransomware on the ESXi hosts.
How this came to light
Broadcom disclosed CVE-2026-59310 as part of security advisory VMSA-2026-0006, published on July 29, 2026. The advisory addressed five vulnerabilities across VMware's virtualization portfolio, three of which were rated critical. Patches were made available at the same time the advisory went public, giving organizations their first opportunity to remediate.
There was no meaningful grace period. German digital forensics and incident response firm QUIRSO identified compromised vCenter systems establishing contact with attacker-controlled infrastructure starting on August 3, 2026, just five calendar days after the patch was released. QUIRSO's findings came from an incident response engagement rather than proactive scanning; the firm was called in to investigate a compromise and, in doing so, uncovered a much broader campaign.
"While the attacker might have had prior knowledge of the vulnerability, the strong correlation between the time of disclosure and exploitation suggests the disclosure as the initial starting point for the campaign," QUIRSO noted in its research.
What is CVE-2026-59310?
CVE-2026-59310 is a directory-traversal vulnerability in the Syslog server component of VMware vCenter. According to Broadcom's advisory, a malicious actor with network access to vCenter can exploit the flaw to execute arbitrary code, with no authentication required and no user interaction needed on the victim's end.
The root cause
The vCenter Syslog server is responsible for accepting and writing log data. The path-traversal flaw allows an attacker to manipulate file paths passed to that service so that data is written outside the directory it is meant to stay in. In practice, this lets an unauthenticated network attacker place a file in a location on the vCenter Server Appliance (vCSA) where it will be picked up and executed, most notably the /etc/cron.d directory, which the system's cron daemon treats as a source of privileged, automatically executed jobs.
Because vCSA runs as a Linux appliance and the Syslog service typically executes with elevated privileges, a successfully placed cron file gives the attacker code execution as root from the very first step of the intrusion. There is no intermediate privilege-escalation stage; the initial access vector and the path to full system control are the same flaw.
What an attacker can do
Once an attacker can place and trigger an arbitrary cron job on the vCSA, the practical outcome is complete compromise of the appliance. From there, an attacker with root access to vCenter has a foothold that extends to everything vCenter manages: ESXi hosts, virtual machines, stored credentials, and the VMware Directory Service (vmdir) that underpins authentication across the environment.
Broadcom has stated plainly that there are no workarounds or mitigations for CVE-2026-59310. Patching is the only remediation path.
The other critical flaws patched alongside it
VMSA-2026-0006 addressed five vulnerabilities in total. The table below summarizes all of them, since organizations patching vCenter should address the full advisory in one pass rather than treating CVE-2026-59310 in isolation.
| CVE | CVSS v3.1 | Component | Vulnerability Type | Authentication Required? |
|---|---|---|---|---|
| CVE-2026-59309 | 9.8 (Critical) | VMware Directory Service (vmdir) | Authentication bypass | No |
| CVE-2026-59310 | 9.8 (Critical) | vCenter Syslog server | Directory traversal leading to RCE | No |
| CVE-2026-47876 | 9.3 (Critical) | ESX / Workstation / Fusion (VMXNET3 adapter) | Out-of-bounds write; VM escape | Requires local admin privileges inside a VM |
| CVE-2026-41703 | Moderate | ESX / Workstation / Fusion | Out-of-bounds read; information disclosure or DoS | Varies |
| CVE-2026-41709 | Low | ESX | Insufficient logging | N/A |
CVE-2026-59309 deserves particular attention alongside CVE-2026-59310. It is an unauthenticated bypass of vCenter's authentication layer via vmdir, also rated a maximum 9.8, and it too requires only network access. Security firm Defused Cyber reported a spike in scanning consistent with CVE-2026-59309 probing, including fingerprinting requests to /sdk/ and walks of the /websso SAML flow. QUIRSO found evidence that CVE-2026-59309 was exploited on at least one of the systems it examined, separately from the CVE-2026-59310 activity, though QUIRSO's own researchers have said there is not yet enough evidence to link the two exploitation efforts to the same infrastructure or intrusion set with high confidence.
CVE-2026-47876 is a VM escape vulnerability in the VMXNET3 virtual network adapter. It is less immediately reachable than the two vCenter flaws since it requires local administrative privileges inside a guest VM first, but it is still worth prioritizing, since an attacker who has already compromised a VM through any means could use it to break out to the underlying ESXi host.
Who is affected?
The vulnerability affects VMware vCenter Server and the products that bundle it. The table below summarizes affected and fixed versions.
| Product | Affected Versions | Fixed In |
|---|---|---|
| VMware vCenter Server | 9.1.x, below 9.1.0.0300 | 9.1.0.0300 |
| VMware vCenter Server | 9.0.x, below 9.0.2.0100 | 9.0.2.0100 |
| VMware vCenter Server | 8.0 (various updates), below 8.0 U3k / 8.0 U2f | 8.0 U3k or 8.0 U2f, depending on branch |
| VMware Cloud Foundation | Bundled vCenter versions above | Update per branch |
| VMware vSphere Foundation | Bundled vCenter versions above | Update per branch |
| VMware Telco Cloud Infrastructure / Telco Cloud Platform | Versions bundling affected vCenter | Update per branch |
Broadcom has confirmed there is no workaround or mitigation short of patching. Given the volume and speed of exploitation observed, and the fact that the flaw has been added to CISA's Known Exploited Vulnerabilities catalog, patching should be treated as an emergency change rather than something scheduled into a routine maintenance window.
Active exploitation: what we know
The timeline of exploitation is unusually compressed, even by the standards of critical vulnerabilities that draw immediate attacker interest.
July 29, 2026: Broadcom discloses CVE-2026-59310 and releases patches.
August 3, 2026: QUIRSO first observes compromised vCenter systems reaching out to attacker-controlled command-and-control infrastructure, five calendar days after disclosure.
August 4, 2026: The campaign accelerates sharply, with 151 additional victim IP addresses observed connecting to attacker infrastructure in a single day.
August 5, 2026: 343 of the eventual 361 total victim IP addresses, roughly 95 percent, have already been compromised.
August 7, 2026: QUIRSO's tally reaches 361 unique victim IP addresses across 47 countries. It is worth noting that IP addresses do not map one-to-one with organizations; some belong to hosting providers or shared infrastructure, so the true count of affected organizations may differ from the raw IP total.
The heaviest concentrations of victims were in Germany (55 IPs), the United States (41), Turkey (38), Iran (26), and France (25), together accounting for more than half of all observed victims.
The attack chain
QUIRSO's technical analysis traced the intrusion in detail on at least one compromised appliance. The first artifact observed was a malformed cron file named zz-poc59310-syslog.log, logged by the cron daemon. The name is telling: it directly references the CVE identifier and reads as a file generated by a proof-of-concept exploit built after public disclosure. The file's naming convention also mimics vCSA's legitimate remote syslog file naming, but it appeared under /etc/cron.d rather than the configured syslog output directory, confirming that the Syslog service itself was the vehicle used to place files in a privileged, automatically executed location.
From there, a curl or wget command retrieved a backdoor from attacker infrastructure and executed it before the log file was removed to reduce forensic traces. The payload, a custom implant researchers refer to as "linuxFile" (also seen as "systemlog" or "linux_x86"), connects out to a WebSocket-based command-and-control channel, decodes its C2 address at runtime using XOR obfuscation, and layers its own application-level encryption on top of an otherwise unencrypted ws:// transport. It re-establishes persistence through both systemd and cron if disrupted.
The attacker also used cron extensively to stage further tooling, including a shell script that served as a downloader and persistence installer for an architecture-specific build of reverse_ssh, an open-source SSH-based reverse-shell framework. Because reverse_ssh initiates outbound connections from the compromised host to attacker infrastructure, it lets the intruder maintain remote access while bypassing inbound firewall rules that would normally block unsolicited connections. reverse_ssh is dual-use, legitimately used in penetration testing, so its presence alone is not proof of compromise; QUIRSO cautions that it becomes a high-priority indicator only in combination with unauthorized installation, unexpected outbound traffic, or execution on an otherwise vulnerable vCenter appliance.
Later stages of the intrusion showed a deliberate effort to blend in with legitimate VMware operations. Three cron jobs were created using names that mimic genuine VMware services: one added the attacker's SSH key to the authorized-keys file to open a direct access channel, and two others dropped a JSP web shell and ran a Base64-encoded script that harvested credentials and created new administrative accounts, including adding one to the vSphere SSO Administrators group. The attacker also modified /etc/sudoers.d to grant a service account unrestricted, passwordless sudo access to root, and used vCenter's own vmafd Python module or registry data to retrieve the credentials associated with the vCenter machine account, which were then used to conduct further privileged directory modifications.
"Exploitation of CVE-2026-59310 provided the actor with immediate, non-interactive code execution in a root context on the vCenter Server appliance," QUIRSO researchers explained. Every subsequent command ran as root from the outset, without any separate privilege-escalation step.
A suspected China-nexus actor, and a ransomware twist
QUIRSO assessed with moderate confidence that the campaign is operated by a Chinese-speaking threat actor, likely working within the UTC+08:00 time zone. That assessment rests on several converging signals: Chinese-language artifacts found in attacker-created scripts, apparent reuse of research published in a Chinese-language security outlet, repeated use of Chinese-language tooling and management software, a victim list that conspicuously excludes mainland China, and activity patterns consistent with UTC+08:00 working hours.
On at least one compromised system, the intrusion culminated in the deployment of Babuk-derived ransomware on ESXi hosts, encrypting files with a .babyk extension. QUIRSO has not confirmed whether this occurred more broadly, since its detailed forensic analysis was limited to one system. Notably, researchers believe the ransomware may not have been the campaign's primary objective; it may instead have served as a smokescreen, encrypting ESXi log files to destroy forensic telemetry and complicate defenders' analysis of the broader intrusion, while also potentially misdirecting attribution efforts.
In a follow-up analysis, QUIRSO also linked the same threat actor to a public GitHub repository disguised as a routine Linux temp-file cleanup utility. Behind that cover story, the tool was found to systematically delete evidence of the intrusion from /tmp directories and to distribute updated reverse_ssh binaries through GitHub releases, an unusual and notably brazen use of a public code-hosting platform as part of the attacker's infrastructure.
Detection
Because this campaign relies on cron, systemd persistence, and outbound reverse-shell connections rather than traditional malware dropped to disk in obvious locations, detection should focus on behavioral indicators rather than file signatures alone.
# Look for unexpected or suspicious entries under /etc/cron.d on vCSA appliances
ls -la /etc/cron.d/
cat /etc/cron.d/* 2>/dev/null | grep -v "^#"
# Check for cron or systemd units referencing curl, wget, or unusual outbound hosts
grep -rE "curl|wget" /etc/cron.d/ /etc/systemd/system/ 2>/dev/null
# Review sudoers.d for unauthorized entries
ls -la /etc/sudoers.d/
cat /etc/sudoers.d/* 2>/dev/null
Additional indicators worth hunting for:
- Unexplained administrative or SSO accounts, particularly ones added to the vSphere SSO Administrators group without a corresponding change-management record or a login event for the legitimate account that supposedly created them.
- Outbound connections from vCenter or ESXi hosts to unfamiliar IP addresses or domains over SSH or WebSocket protocols, especially where the destination is not part of normal VMware licensing, telemetry, or update infrastructure.
- Unfamiliar JSP files or web shells dropped into vCenter's web application directories.
- Modified
authorized_keysfiles on vCSA appliances containing SSH public keys that administrators do not recognize. - Unusual REST API activity against vCenter, especially requests using non-standard or suspicious User-Agent strings, which QUIRSO observed being used to disguise attacker reconnaissance as legitimate VMware Cloud Foundation Fleet management traffic.
QUIRSO has published a generic YARA rule for detecting reverse_ssh binaries, available in its public detection repository. Because reverse_ssh has legitimate uses, any detection should be corroborated with the other indicators above before being treated as confirmed malicious activity.
What should you do?
1. Determine your exposure
Identify every vCenter Server instance in your environment, including those bundled inside VMware Cloud Foundation, vSphere Foundation, or Telco Cloud deployments, and check the running version against the affected ranges above. Pay particular attention to any vCenter instance reachable from the internet or from any network segment containing lower-trust or less-controlled hosts.
2. Patch immediately
There is no workaround for CVE-2026-59310. Upgrade to one of the following:
- vCenter 9.1: version 9.1.0.0300
- vCenter 9.0: version 9.0.2.0100
- vCenter 8.0: version 8.0 U3k or 8.0 U2f, depending on your branch
Consult Broadcom's advisory, VMSA-2026-0006, for the complete version matrix across Cloud Foundation, vSphere Foundation, and Telco Cloud products, and apply the same update cycle to address the other four vulnerabilities patched in the same release, particularly CVE-2026-59309.
3. Restrict network exposure while you patch
Since no interim mitigation exists, the closest available substitute is reducing reachability. Remove vCenter management interfaces from direct internet exposure if they are currently exposed, and restrict access to the smallest practical set of administrative source addresses, ideally behind a VPN with multi-factor authentication, while patches are staged.
4. Hunt for signs of prior compromise
Given that exploitation began within days of disclosure and CISA has added this vulnerability to its Known Exploited Vulnerabilities catalog with an unusually short remediation window, treat any internet-exposed vCenter instance that was unpatched between July 29 and your patch date as potentially compromised until proven otherwise. Run the detection checks above, review cron, sudoers, and SSO administrator group membership for unauthorized changes, and check for reverse_ssh artifacts using QUIRSO's published YARA rule.
5. Rotate credentials on systems with signs of compromise
If any indicators of compromise are found, treat vCenter machine account credentials, any SSO or local administrative credentials, and SSH keys on the affected appliance as compromised. Rotate them, and review ESXi hosts managed by the affected vCenter instance for unauthorized local accounts, since the observed campaign created accounts on ESXi hosts specifically to enable follow-on ransomware encryption.
6. Check for ransomware and log tampering on managed ESXi hosts
Where compromise is confirmed or suspected, inspect ESXi hosts for files encrypted with a .babyk extension and for gaps or tampering in ESXi log files, which the observed campaign used to erase forensic evidence. The presence of encrypted logs should be treated as a strong signal that deeper forensic investigation, beyond the affected vCenter appliance itself, is warranted.
Summary
| CVE | CVE-2026-59310 |
| CVSS Score | 9.8 (Critical, CVSSv3.1) |
| Type | Directory Traversal (CWE-22) leading to Remote Code Execution |
| Component | VMware vCenter Syslog server |
| Affected | vCenter 9.1 below 9.1.0.0300; vCenter 9.0 below 9.0.2.0100; vCenter 8.0 below 8.0 U3k / U2f; VMware Cloud Foundation, vSphere Foundation, and Telco Cloud products bundling these versions |
| Attack vector | Network, unauthenticated, no user interaction required |
| Disclosed | July 29, 2026 (VMSA-2026-0006) |
| Workaround available? | No, Broadcom has confirmed none exists |
| Active exploitation? | Yes, confirmed by QUIRSO beginning August 3, 2026 |
| Attributed to | Suspected China-nexus APT (moderate confidence) |
| Scale of exploitation | 361 unique victim IPs across 47 countries as of August 7, 2026 |
| Observed follow-on impact | reverse_ssh persistence; on at least one system, Babuk-derived ransomware on ESXi hosts |
| Related critical flaw | CVE-2026-59309, vmdir authentication bypass, also CVSS 9.8, patched in the same advisory |
| CISA KEV status | Added August 18, 2026 |
| Full fix | Upgrade to vCenter 9.1.0.0300, 9.0.2.0100, or 8.0 U3k / U2f |
VMware vCenter is the kind of system where a single compromise does not stay contained; it is the management plane for everything else. A vulnerability with no workaround, active exploitation within five days of disclosure, and a confirmed path to ransomware on managed ESXi hosts is not one to leave for the next change window. If you need help determining your exposure, verifying whether any of your vCenter instances show signs of the activity described above, or coordinating an emergency patch cycle, get in touch. This is precisely the kind of fast-moving, high-stakes situation CrowdSOC exists to help with.