CRITICAL: VMware vCenter CVE-2026-59310 Exploited in the Wild for RCE

Broadcom published VMSA-2026-0006 on July 29 and told everyone with a vCenter server to patch it immediately. Somebody else read the same advisory and got to work.

Five days later, on August 3, the first compromised vCenter servers started phoning home to attacker controlled infrastructure. Threat intelligence outfit QUIRSO has since tracked 361 unique victim IP addresses across 47 countries, with the heaviest concentrations in Germany, the United States, Turkey, Iran, and France. The vulnerability they are riding is CVE-2026-59310, a directory traversal flaw in the vCenter Syslog server that carries a CVSS score of 9.8 and requires no credentials, no authentication, and nobody clicking on anything.

This is a drop everything and patch it now situation. The five day gap between a public advisory and confirmed victims in dozens of countries is also a useful reminder of how much runway you actually get on infrastructure bugs, which is to say almost none.

The bug

CVE-2026-59310 lives in the Syslog server component of vCenter, and the root cause is the oldest story in the book. Improper restriction of pathname resolution, better known as failing to check whether a supplied path stays inside the directory you meant it to stay inside. An attacker with network access to the vulnerable service can walk outside the intended directory scope, reach resources that were never meant to be reachable, and from there achieve arbitrary code execution on the vCenter server itself. Broadcom's own advisory language is blunt about that last part, and the 9.8 rating reflects a network attack vector with low complexity and no privileges required.

There is a companion issue worth knowing about. CVE-2026-59309, also rated 9.8, is an authentication bypass in the VMware Directory Service, the vmdir component that vCenter leans on for identity. An attacker with network access can skip authentication entirely and land on the management plane with full control over the virtual infrastructure. The two together make an unpleasant pair, one to get in and one to own identity, and both were addressed in the same advisory.

Neither one has a workaround. Broadcom was explicit about that, which means the vendor patch is the entire remediation strategy. There is no configuration toggle, no registry key, and no clever firewall rule that the vendor is willing to bless as sufficient.

What you need to be running

The fixed builds are specific, so check them against what you actually have rather than what your asset database claims you have. vCenter Server 8.0 gets its fix in 8.0 U3k. The 9.0 line is patched in VMware Cloud Foundation and vSphere Foundation 9.0.2.0100, and the 9.1 line in 9.1.0.0300. Cloud Foundation 5.x customers get there through an async patch to 8.0 U3k. The blast radius extends past standalone vCenter as well, because anything that embeds or depends on it inherits the problem, and that includes VMware Cloud Foundation, vSphere Foundation, Telco Cloud Platform, and Telco Cloud Infrastructure.

How exploitation looks in the wild

The observed attack chain is refreshingly unsubtle, which is good news for anyone doing incident response. QUIRSO describes path traversal activity consistent with CVE-2026-59310 followed immediately by the deployment of a malicious cron job on the host. That cron job runs reverse_ssh, an open source tool for establishing reverse SSH connections back to infrastructure the attacker controls. The result is persistent remote access that survives reboots and does not depend on the original vulnerability remaining unpatched, which is the detail that should worry anyone who patched last week and considered the matter closed.

Patching does not evict someone who already has a cron entry and a reverse shell. If your vCenter was reachable and unpatched at any point between July 29 and the day you updated, patching was step one of two.

The reconnaissance side has been just as visible. Defused Cyber reported a spike in scanning against vCenter, with honeypots logging version fingerprinting through POST requests to /sdk/ calling RetrieveServiceContent, along with attackers walking the /websso SAML single sign on flow. That is not opportunistic background noise, that is somebody building a target list and checking builds before they spend an exploit on the wrong box.

The timing raises an eyebrow. QUIRSO notes the exploitation window correlates strongly with public disclosure, and the operational tradecraft on display suggests an advanced persistent threat actor rather than a commodity crew racing a proof of concept to market. Chinese linked groups have a long history in this neighborhood, with UNC5174 having weaponized VMware flaws in prior espionage campaigns, and vCenter has spent years as a recurring guest on the CISA Known Exploited Vulnerabilities catalog. Nobody should be surprised that the hypervisor management plane keeps attracting professionals.

Why vCenter is worth this much effort

If you want to understand why a well resourced actor would burn effort on a syslog parser, look at what sits behind it. vCenter is the control plane for the entire virtual estate. Whoever owns it can enumerate every virtual machine, snapshot them, clone them, mount their disks, deploy new workloads, harvest credentials from linked identity sources, and reach the ESXi hosts underneath. Ransomware crews figured this out years ago, which is why encrypting datastores from the hypervisor layer became standard playbook material. One compromised management server beats a hundred compromised endpoints, and it gets there without touching a single endpoint agent inside the guest operating systems.

That is also why the usual comfort of a flat internal network stops being comfortable. Plenty of organizations treat vCenter as an internal only service and therefore a lower patching priority, right up until someone phishes a workstation that sits on the same VLAN.

What to do about it

Patch to the fixed builds above, and treat it as an emergency change rather than something for the next maintenance window. Once you are patched, go hunting, because the patch fixes the door and not the person already standing inside the house. Review crontab entries on the vCenter appliance for anything you did not create, paying particular attention to entries invoking ssh or referencing unfamiliar binaries in temporary directories. Look for reverse_ssh artifacts and for outbound SSH connections originating from vCenter to destinations that are not your management jump hosts, because a vCenter appliance initiating outbound SSH to the internet is not normal behavior in any environment worth defending.

On the network side, pull firewall and proxy logs for outbound traffic from vCenter management interfaces going back to July 29 and look for consistent beaconing to unfamiliar domains. Inbound, check web and reverse proxy logs for POST requests to /sdk/ and for traffic hitting /websso paths from addresses that have no business being there. The syslog service logs are worth reviewing for path traversal patterns as well, though a careful attacker will have thinned those out on the way through.

Longer term, the boring architectural advice applies, as it usually does. The vCenter management interface should not be reachable from the internet, and it should not be reachable from the general user network either. Put it behind a jump host, restrict access to a dedicated management VLAN, require multifactor authentication for administrative access, and make sure your vCenter appliances fall under the same patch service level you apply to internet facing systems rather than the leisurely one you reserve for internal infrastructure.

If you run vSphere and you have not confirmed your build numbers today, that is the task for this morning. The people scanning for RetrieveServiceContent responses are not waiting for your change advisory board to convene.

The MSP angle

Every client running VMware just became a legitimate reason to pick up the phone, and explaining that you need to verify their hypervisor management plane was not backdoored between July 29 and today is a far easier conversation to open than a generic security check in. Compromise assessment engagements scoped tightly around this CVE sell themselves, because the cron and reverse SSH persistence means patching alone does not answer the question the client actually cares about. There is a durable recurring services angle here too in managed patching for virtualization infrastructure, since the clients most exposed are precisely the ones treating vCenter as furniture rather than as the crown jewel an attacker already knows it to be.