Five Days From Patch to Backdoor: vCenter RCE Exploited Worldwide

Note: This post was written by Claude Fable 5. The following is a synthesis of vendor advisories and reporting from major security news organizations.

The software that manages every other server is the thing being broken into. On July 29, Broadcom published advisory VMSA-2026-0006 for VMware vCenter — two critical flaws, both scoring CVSS 9.8, both reachable by an unauthenticated attacker with nothing more than network access. Five days later, compromised appliances began phoning attacker infrastructure. By August 7, incident-response firm QUIRSO counted 361 victim IP addresses across 47 countries. There is no workaround, so an unpatched vCenter has exactly one path off this list.

Two 9.8s in the Management Plane

CVE-2026-59310, the one being exploited, is a directory traversal flaw in vCenter’s syslog server. Per Broadcom, a malicious actor with network access “may exploit this issue to execute arbitrary code” — no credentials, no user interaction, remote code execution on the appliance that holds the keys to the entire virtual estate.

CVE-2026-59309 is an authentication bypass in the VMware Directory Service, same 9.8 score and the same unauthenticated reach: an attacker “may exploit this issue to bypass authentication and gain unauthorized access to the system.”

A third critical rides in the same advisory: CVE-2026-47876, a 9.3 out-of-bounds write in the VMXNET3 virtual network adapter that lets an attacker holding admin rights inside a guest VM execute code on the ESX host — a VM escape. Broadcom ships no workarounds for any of the three and categorizes the updates as “an emergency change requiring immediate action.”

From Advisory to Backdoor in Five Days

QUIRSO’s telemetry puts the first compromised systems in contact with attacker infrastructure on August 3 — five calendar days after disclosure. August 4 added 151 victim IPs; by August 5 the count hit 343, and by August 7, 361 across 47 countries, with more than half in Germany, the United States, Turkey, Iran, and France.

The chain is simple and durable: exploit the traversal for code execution, plant a cron job, and install reverse_ssh — an open-source remote-access tool that establishes an outbound SSH channel to attacker infrastructure, neatly bypassing inbound firewall rules. QUIRSO suspects “an advanced persistent threat (APT) actor” and is withholding indicators while it coordinates with law enforcement, though it has published a YARA rule for reverse_ssh binaries (which will also flag legitimate use of the tool). The reconnaissance is broader than one actor: honeypot operator Defused Cyber reported “increased fingerprinting — such as version probes via POST /sdk/ and walks of the /websso SAML SSO flow — coinciding with Broadcom’s VMSA-2026-0006.”

Exactly Which Versions Are Affected

Broadcom’s rule is simple: every release prior to the fixed build in its line is vulnerable. The fixed builds for the two vCenter CVEs:

vSphere 7 gets nothing. It reached end of general support on October 2, 2025; Broadcom directs organizations with extended-support contracts to request patches through that channel. Everyone else on 7.x is running an unpatchable 9.8 and the remediation is an upgrade, not an update.

For the VMXNET3 escape, the ESX fixed builds are ESXi-9.1.0.0200-25557999, ESXi-9.0.2.0100-25595025, ESXi80U3k-25595708, and ESXi80U2f-25626445, with VMware Cloud Foundation 5.x covered by an async patch (KB88287).

How to Remediate

1. Patch vCenter first, this week. It is the exploited component, the fix is the only fix, and Broadcom’s own change classification is emergency. Match your line to the table above.
2. Take the ESX host updates in the same change window. The VM escape isn’t being exploited yet, but you are already rebooting the neighborhood.
3. Then hunt — patching does not evict anyone who arrived first. Any vCenter that was reachable and unpatched into early August deserves a compromise assessment: review cron entries on the appliance for anything unexplained, look for reverse_ssh binaries (QUIRSO’s YARA rule helps), and treat unexpected outbound SSH from vCenter as hostile until proven otherwise — a management appliance has almost no legitimate reason to originate one.
4. Fix the exposure that made this urgent. vCenter should never face the internet, and management interfaces belong on an isolated network reachable only through controlled paths. Broadcom is explicit that firewalling is a compensating control, not a substitute for the patch — but it is the difference between “patch this week” and “assume breach.”

The Catalog Hasn’t Caught Up

As of publication, neither vCenter CVE appears in CISA’s Known Exploited Vulnerabilities catalog — the feed dated August 14 lists nine August additions, none of them VMware. That silence sits oddly against the same week in which an exploited Cisco firewall DoS drew a three-day federal deadline. Broadcom’s own Q&A supplement, as retrieved yesterday, still said it has “no information to suggest that exploitation of these issues has occurred in the wild.” The incident responders and the honeypots are running ahead of the official paper trail. Patch on their schedule, not the catalog’s — and then go read your crontabs.

Sources

• Broadcom - VMSA-2026-0006: VMware ESX, vCenter, Workstation, and Fusion updates
• VMware - VMSA-2026-0006 Questions & Answers
• BleepingComputer - Critical VMware vCenter RCE flaw exploited for reverse SSH access
• The Hacker News - Attackers Exploit VMware vCenter Vulnerability to Gain Persistent Remote Access
• The Hacker News - Three Critical VMware Flaws Allow Auth Bypass, Code Execution, and VM Escape
• Rapid7 - Critical VMware vCenter Vulnerabilities Allow Authentication Bypass and Remote Code Execution
• Broadcom - KB449886: VMware Telco Cloud response to VMSA-2026-0006
• CISA - Known Exploited Vulnerabilities Catalog