Hackers Are Exploiting a Critical VMware vCenter Flaw Five Days After Broadcom Patched It

What happened

Attackers are actively breaking into internet-facing VMware vCenter servers through CVE-2026-59310, a critical flaw that Broadcom patched only at the end of July. The German digital-forensics firm QUIRSO says it first spotted compromised systems calling out to attacker infrastructure on August 3, 2026, five calendar days after the fix went public. By the time QUIRSO published its findings in mid-August, it had counted 361 unique victim IP addresses spread across 47 countries.

Broadcom disclosed the bug in advisory VMSA-2026-0006 on July 29, 2026, and rated it 9.8 out of 10, the top of the CVSS severity scale. That gap between disclosure and mass exploitation is the story here. It is short enough that any organisation still running an exposed vCenter should assume it is being scanned right now.

The flaw: CVE-2026-59310

CVE-2026-59310 is a directory-traversal vulnerability in the vCenter Syslog server. In plain terms, a request can be crafted to escape the directory it is supposed to stay inside and reach files it should never touch. Broadcom's advisory says an attacker with network access to vCenter can chain that into arbitrary code execution, and that this requires no authentication. There is no workaround. Broadcom's guidance is to patch, and only patch.

The same July 29 advisory carried a second critical entry, CVE-2026-59309, also rated 9.8. Both have drawn scanning traffic, but it is CVE-2026-59310 that the tracked campaign is weaponising. A 9.8 that is unauthenticated and reachable over the network is close to the worst combination a defender can be handed: nothing stands between an exposed port and code running on the box.

Five days from patch to attack

According to QUIRSO's writeup, the intrusions follow a consistent pattern. The attacker triggers the path-traversal flaw, then drops reverse_ssh, an open-source tool that opens an outbound SSH tunnel back to a server the attacker controls. Because the connection is initiated from inside the victim network, it slips past firewalls and controls that are watching for inbound SSH rather than outbound. Once the tunnel is up, the operator has a durable foothold on the vCenter host.

The scale ramped quickly. QUIRSO recorded its first hits on August 3 and saw the campaign peak the next day, August 4, with 151 new victim IPs in a single day. Of the 361 systems it identified, more than half sat in just five countries: Germany, the United States, Turkey, Iran and France, which together accounted for roughly 185 of the addresses.

QUIRSO attributes the activity to a "suspected advanced persistent threat" but stops short of naming a group. Its reasoning is timing: the tight correlation between Broadcom's disclosure and the first compromises points to the advisory itself as the starting gun, which is the behaviour of a well-resourced actor watching vendor bulletins and turning patches into working exploits within days. VMware bugs have a history here: Chinese-linked operators have weaponised earlier vCenter and ESXi flaws. But as of QUIRSO's report, there is no confirmed attribution for this one.

Why vCenter is the target

vCenter is not just another server. It is the console that manages an entire VMware estate: the ESXi hypervisors, and through them every virtual machine running on them. An attacker who owns vCenter is one step from the guest workloads themselves: domain controllers, databases, backup servers. This is exactly the position ransomware crews want, because from the hypervisor they can encrypt dozens of VMs at once without ever touching the operating systems inside them.

That is why a single unauthenticated flaw in this product carries weight that the same bug in a leaf application would not. Compromising one vCenter can mean compromising the data centre it runs.

What administrators should do

Broadcom's fixed builds, listed in VMSA-2026-0006, are:

• VMware Cloud Foundation / vSphere Foundation 9.1: update to 9.1.0.0300.
• VMware Cloud Foundation / vSphere Foundation 9.0: update to 9.0.2.0100.
• vCenter Server 8.0: update to 8.0 U3k, or 8.0 U2f depending on the branch you run.

Patching closes the door, but it does not undo a break-in that already happened. Anything exposed to the internet between July 29 and the day you applied the fix should be treated as potentially compromised. QUIRSO published a YARA rule on August 10 to hunt for reverse_ssh, and the practical checks are the obvious ones: look for unexpected outbound SSH connections from vCenter, review cron and scheduled tasks on the appliance, and inspect the syslog service for tampering. If the host was reachable and unpatched, hunt before you assume you are clean.

What happens next

Two things usually follow a campaign like this. Public exploit code tends to appear once a flaw is confirmed exploitable in the wild, which widens the pool of attackers from one suspected APT to opportunistic crews and commodity ransomware. And US and European agencies frequently add flaws under this kind of active exploitation to their must-patch catalogues, putting government networks on a hard deadline.

The core lesson is uncomfortable but not new: for internet-facing management planes like vCenter, a vendor patch is now the opening move in a race, not the end of one. Five days was all the margin defenders got this time. The organisations that lost that race are the ones that will spend the coming weeks working out how far the intruders got.