Of all the servers in an enterprise, vCenter is close to the worst one to lose — it’s the control plane for the entire virtual datacenter, the single console that manages every ESXi host and every VM. CVE-2026-59310 is an unauthenticated, CVSS 9.8 remote code execution flaw in vCenter’s Syslog Server, and attackers are already using it at scale: a suspected APT compromised 361 victims across 47 countries within days of disclosure. If you run vCenter, this is a patch-today situation. Here’s the flaw, the campaign, and exactly what to do.
What the bug is
CVE-2026-59310 is a directory-traversal vulnerability in the vCenter Syslog Server, rated CVSS 9.8. There’s a grim irony to it: the Syslog Server exists to collect logs, and this flaw turns that log collector into a doorway into the operating system. An unauthenticated attacker with network access to vCenter can exploit the traversal to write to locations they shouldn’t and ultimately execute arbitrary code on the appliance — no credentials, no user interaction.
The reason this rates as a genuine emergency rather than just another high-CVSS bug is where it lands. Code execution on vCenter isn’t code execution on one server — it’s a foothold on the machine that controls all of them. From vCenter, an attacker can reach every ESXi host and every virtual machine in the estate. It’s the exact position ransomware crews dream of, because it lets them encrypt an entire virtual environment from one box.
This is not theoretical — it’s a live, global campaign
Broadcom published the advisory on July 29. A suspected advanced persistent threat actor began exploiting the flaw on August 3 — less than a week later. The scale and speed are the story:
- 361 unique victim IP addresses across 47 countries were identified.
- 151 new victims were compromised on August 4 alone.
- About 95% of observed victims were reached by August 5.
That’s not opportunistic spraying that fizzles out — it’s a coordinated campaign that hit nearly its entire observed victim set inside 48 hours. If your vCenter was internet-reachable and unpatched during that window, you should assume it was at least probed.
The attack chain: from traversal to reverse SSH
Researchers observed a consistent pattern. First, path-traversal activity matching the vulnerability. Then, once code execution was achieved, the attackers established persistence by planting a malicious cron job that launches reverse_ssh — an open-source tool for opening SSH connections back to attacker-controlled infrastructure.
That choice of tooling is deliberate and worth noting for defenders. reverse_ssh is a legitimate open-source project, not bespoke malware, so it doesn’t trip signature-based detection the way custom implants do. The persistence lives in a cron job — a normal, expected part of any Linux appliance — and the outbound connection is just SSH. It’s the same “hide inside the legitimate” playbook we keep seeing: the malicious activity is built from ordinary parts, so detection has to focus on anomalies (a cron job that shouldn’t exist, an outbound SSH session from an appliance that has no business making one) rather than known-bad indicators.
Affected versions and fixes
There is no workaround — you must patch to a fixed build:
- vCenter 9.1.x → fixed in 9.1.0.0300
- vCenter 9.0.x → fixed in 9.0.2.0100
- vCenter 8.0 → fixed in 8.0 U3k or 8.0 U2f (Broadcom revised the advisory on August 3 to add the 8.0 U2f express patch)
What to do now
- Patch immediately to the fixed build for your branch. For an unauthenticated, actively-exploited 9.8 on your virtualization control plane, this jumps every other queue.
- vCenter should never be internet-facing. The management plane belongs on an isolated administration network, reachable only from trusted jump hosts. If yours is exposed to the internet, that is the finding to fix first — isolate it now, then patch.
- Hunt for the persistence. On the vCenter appliance, review cron jobs (system and per-user crontabs,
/etc/cron.*) for entries you didn’t create, look forreverse_sshor unexpected SSH processes and outbound SSH connections, and check the Syslog Server logs for path-traversal patterns around and after early August. - Assume breach if you were exposed and unpatched during the campaign window. Given exploitation predated many organisations’ patch rollouts, a clean patch does not undo a compromise that already happened — investigate before you consider it resolved.
- Extend the review to ESXi and your VMs. Because vCenter compromise cascades downward, don’t stop at the appliance. Check for unexpected activity on managed hosts and any signs of lateral movement.
The bigger lesson: management planes are the real crown jewels
vCenter, hypervisor consoles, cloud control panels, domain controllers, CI/CD orchestrators — these management planes are worth more to an attacker than any single application, because owning one means owning everything beneath it. They deserve a different tier of protection: never internet-exposed, reachable only through hardened admin paths, monitored aggressively, and patched on the shortest possible timeline. CVE-2026-59310 is a textbook demonstration of why. A directory-traversal in a log collector became a route to the entire virtual estate, and a global campaign turned that into hundreds of compromises in days.
The bottom line
CVE-2026-59310 is an unauthenticated CVSS 9.8 RCE in VMware vCenter’s Syslog Server, exploited within a week of disclosure across 361 victims in 47 countries, with cron-based reverse_ssh persistence. Patch to 9.1.0.0300 / 9.0.2.0100 / 8.0 U3k or U2f today, get vCenter off any internet-facing path, hunt for rogue cron jobs and reverse-SSH sessions, and treat any exposed-and-unpatched appliance as potentially breached. When the control plane falls, everything under it falls with it.
Sources: The Hacker News · BleepingComputer · Infosecurity Magazine · Dark Reading. Confirm the exact fixed build for your deployment in Broadcom’s advisory before acting.