Attackers Actively Exploit a Critical VMware vCenter Flaw in 47 Countries

Attackers are actively exploiting a critical, unauthenticated remote code execution flaw in VMware vCenter, and the incident response firm that caught the campaign says it has already identified 361 victim IP addresses spread across 47 countries. Broadcom patched the bug, tracked as CVE-2026-59310, on July 29. Exploitation began just five days later, according to SecurityWeek and the German incident response firm QUIRSO, which first documented the activity.

What CVE-2026-59310 Actually Does

CVE-2026-59310 is a directory traversal vulnerability in the Syslog server component of VMware vCenter, the management console most VMware-based data centers use to run their virtual machine fleets. It carries a CVSS score of 9.8 out of 10. Broadcom’s own security advisory, VMSA-2026-0006.1, describes it plainly: a malicious actor with network access to vCenter can exploit the flaw to execute arbitrary code. Exploitation does not require any authentication, only network reach to the vCenter service, and no workaround exists, so patching is the only fix.

Broadcom credited the discovery to Phil Brass and Matt South of Atredis Partners. The fix landed in vCenter 9.1.0.0300, vCenter 9.0.2.0100, and vCenter 8.0 U3k or 8.0 U2f, covering VMware Cloud Foundation, VMware vSphere Foundation, and standalone vCenter Server deployments.

A Second Critical Flaw Shipped in the Same Advisory

The same July 29 advisory also patched CVE-2026-59309, a separate authentication bypass vulnerability in vCenter’s Directory Service that likewise scores 9.8 on the CVSS scale and shares the exact same affected versions and fixes. Quirso and SecurityWeek have so far only reported active exploitation of CVE-2026-59310, not CVE-2026-59309, but administrators patching one should patch both, since Broadcom ships the fixes together.

How Fast the Exploitation Campaign Moved

According to Quirso, the first confirmed connections from compromised vCenter servers back to attacker-controlled infrastructure appeared on August 3, just five days after Broadcom’s disclosure. The pace accelerated quickly from there: by August 4, 151 more victim IP addresses had shown up, and by August 5, 343 of the eventual 361 identified IPs, about 95 percent of the total, had already connected. Germany, the United States, Turkey, Iran, and France accounted for 185 of the 361 IPs between them, roughly half.

Quirso was careful to note that an IP address count is not the same as a count of victim organizations. “The exact number of victim organizations cannot be inferred from these IP addresses, as an IP address does not necessarily correspond to a unique company or physical system. Some addresses belong to hosting providers, cloud networks, or shared infrastructure,” the firm said.

From Path Traversal to a Persistent Backdoor

Quirso’s writeup describes a consistent attack chain: the attacker abuses the path traversal flaw to reach the Syslog service, plants a malicious cron job for persistence, and then installs reverse_ssh, an open source, Go-based SSH reverse-shell framework. Because reverse_ssh initiates an outbound connection back to attacker infrastructure, it slips past firewall rules that only block unsolicited inbound traffic. The Hacker News reported the same pattern: path traversal activity consistent with the flaw, followed by a cron job that establishes the reverse_ssh backdoor.

Quirso published a generic YARA rule on its GitHub so defenders can hunt for reverse_ssh builds on their own systems. The firm also cautioned that reverse_ssh has legitimate penetration-testing uses, so a detection alone is not proof of compromise; SecurityWeek reported that organizations with internet-facing vCenter systems should corroborate any hit with other signs, such as unauthorized installation locations and unexpected outbound connections.

What vCenter Administrators Should Do Now

There is no workaround for either CVE-2026-59310 or CVE-2026-59309, so the only remediation is applying Broadcom’s update:

• vCenter 9.1.x: update to 9.1.0.0300
• vCenter 9.0.x: update to 9.0.2.0100
• vCenter 8.0: update to 8.0 U3k or 8.0 U2f

Given that the campaign compromised the vast majority of its eventual 361 victim IPs within 48 hours of first appearing, administrators running an affected version should treat this as an emergency change, not a routine maintenance window. Anyone who has not yet patched should also check for the reverse_ssh indicators Quirso published, since a vCenter server compromised before patching will still have the backdoor installed after the update is applied; patching closes the hole but does not remove an attacker who is already inside.