VMware vCenter RCE: Five Days from Patch to 361 Compromised Servers

Broadcom published advisory VMSA-2026-0006 on July 29, 2026, shipping patches for three critical vulnerabilities in VMware vCenter and ESXi. By August 3—five calendar days later—the first active exploitation was underway. By August 5, German digital forensics firm Quirso had counted more than 340 compromised IP addresses connecting to attacker infrastructure. By August 10, when Quirso published its findings, the tally stood at 361 victim addresses across 47 countries.

Five days is not a comfortable patch window. For anything reachable from a broad internal network—let alone the public internet—it's barely enough time to test an update in staging before threat actors are already through the door. If your vCenter appliance was accessible from outside a tightly controlled perimeter during that window, assume compromise until your logs say otherwise.

Three Critical Vulnerabilities in One Advisory

VMSA-2026-0006 covers five flaws total; three are rated Critical. Two live in vCenter, one in ESXi hosts.

• CVE-2026-59310 (CVSS 9.8) — vCenter Syslog RCE: A directory traversal flaw in vCenter's built-in Syslog server. An unauthenticated attacker with network access can traverse paths to read or write arbitrary files anywhere on the appliance, and from there execute code. No credentials required. This is the CVE under active, widescale exploitation.
• CVE-2026-59309 (CVSS 9.8) — vCenter Authentication Bypass: A flaw in VMware Directory Service that lets an unauthenticated network-adjacent attacker skip authentication entirely and gain unauthorized access to vCenter. Combined with CVE-2026-59310, an attacker can bypass the login screen and then run arbitrary code—two CVSS 9.8 flaws that chain cleanly.
• CVE-2026-47876 (CVSS 9.3) — ESXi VM Escape: An out-of-bounds write in the VMXNET3 virtual network adapter driver allows a VM administrator to break out of the guest OS and execute code on the underlying ESXi host. A guest-to-host escape means a compromised VM can pivot to own every other VM running on that host.

Broadcom confirmed no workarounds exist for any of these three. Patching is the only fix.

The Attack Chain: Syslog Server to Persistent Reverse Shell

The exploitation of CVE-2026-59310 followed a methodical sequence. Attackers used the directory traversal to achieve initial code execution on the vCenter appliance. They then wrote a malicious cron job that launches reverse_ssh, an open-source reverse shell framework built for exactly this scenario—it opens an outbound SSH connection to attacker-controlled infrastructure rather than waiting for an inbound connection.

That design detail matters operationally. A firewall rule preventing external hosts from connecting to vCenter does nothing against an outbound reverse shell. Once the cron job is in place and the tunnel is established, the attacker has persistent access that survives reboots, network changes, and even patching the original vulnerability. The flaw gets closed; the back door stays open.

Quirso assessed the campaign as the work of an advanced persistent threat actor based on its speed and geographic coordination, though specific attribution remains unconfirmed and indicators of compromise are being withheld pending law enforcement coordination. Historically, Chinese-nexus groups like UNC5174 have targeted VMware infrastructure for espionage—this campaign's profile is consistent, but no public attribution has been made.

Why vCenter Is Always the Crown Jewel

vCenter is centralized control for an entire VMware environment—virtual machines, ESXi hosts, storage, networking, user accounts, and permissions across the whole stack. Code execution on a vCenter appliance is effectively domain admin over your entire virtualized infrastructure. An attacker who owns vCenter can reconfigure VMs, pull disk snapshots, disable backup jobs, harvest credentials from guest memory, and move laterally to anything that vCenter manages.

For ransomware operators, that's the encryption target. For nation-state actors, it's the access needed to quietly copy everything. For both, vCenter exposure is a force multiplier—one foothold, total access.

That's the context behind the 5-day exploitation window. Broadcom's advisory went public, automated scanners identified exposed instances, threat actors refined their exploit, and mass compromise began—all before most organizations had cleared their change-control process. The speed of disclosure-to-exploitation has been trending downward for years; VMSA-2026-0006 is another data point on that line.

Two Problems to Solve, Not One

Patching CVE-2026-59310 closes the initial access vector. It does not remove a reverse_ssh cron job already installed before the patch was applied. Organizations face two separate remediation tasks: stopping new unauthorized access, and evicting attackers who got in during the exposure window.

An org that patched on August 5 may have closed the door but left an active reverse shell running. That tunnel doesn't announce itself in normal monitoring—it looks like outbound SSH traffic, which many environments permit freely.

Patch Versions and Detection Steps

Apply the following fixed releases immediately:

• vCenter 9.1: update to 9.1.0.0300
• vCenter 9.0: update to 9.0.2.0100
• vCenter 8.0: update to U3k or U2f branch
• ESXi (CVE-2026-47876): 9.1.0.0200, 9.0.2.0100, or 8.0 U3k

After patching, hunt for persistence artifacts on each vCenter appliance:

• SSH to the VCSA shell and run crontab -l as root; inspect /etc/cron.d/, /var/spool/cron/, and /etc/rc.local for anything unrecognized.
• Run ps aux | grep ssh and look for reverse_ssh processes or outbound SSH connections that don't terminate at infrastructure you own.
• Review netstat -tnp for established connections on unusual destination ports—reverse_ssh can be configured to use any port.
• Check VMware Directory Service authentication logs for unexpected logins between August 3 and today.
• Restrict vCenter management access to a VPN or jump host now, regardless of patch status. There is no scenario where vCenter should be directly internet-reachable.

At Falcon Internet, this is the kind of event that reminds us why infrastructure restores get drilled regularly—patching closes the hole, but if an attacker already built persistence inside, only a validated restore from a clean snapshot can guarantee you've actually evicted them.