By Two CVSS 9.8 vulnerabilities in VMware vCenter are being chained in active attacks right now. CVE-2026-59309 lets unauthenticated attackers bypass authentication entirely. CVE-2026-59310 turns that access into remote code execution. Broadcom disclosed both on July 29. By August 3 — five days later — real environments were already compromised. Broadcom offers no workaround. Patching is the only option.
What the Two Flaws Are — and Why Chaining Them Is Devastating
CVE-2026-59309 lives in vmdir, the VMware Directory Service that powers vCenter Single Sign-On. Classified as CWE-303 — a broken authentication algorithm — it lets any attacker with network access to TCP port 389 or 636 impersonate an administrative user without a single valid credential. No password, no token, no user interaction required.
CVE-2026-59310 sits in the vCenter Syslog server. It is a directory traversal flaw that lets an unauthenticated attacker write arbitrary files to the system, which in practice means code execution with SYSTEM privileges on the vCenter host.
Chained together, they produce a clean, unauthenticated path to full vCenter control: bypass authentication with CVE-2026-59309, then drop and execute a payload with CVE-2026-59310. vCenter is the management plane for every ESXi host, every virtual machine, every datastore, and every virtual network in your estate. Own vCenter, own everything beneath it.
How Fast Attackers Moved
Five days. That is the window between Broadcom’s July 29 disclosure and the first confirmed compromises on August 3. By August 5, attackers had already hit 343 of the eventual 361 victim IP addresses — roughly 95% of all victims — within 72 hours of exploitation beginning.
Rapid7 published a working proof-of-concept on August 11, which accelerated the attack surface further. This is not a new pattern: prior vCenter CVEs from 2021 and 2023 were exploited within days of disclosure. Attackers have learned to treat vCenter disclosures as time-limited opportunities, and the data shows they are right to do so.
As of today, security firm QUIRSO GmbH has tracked 361 confirmed victim IP addresses across 47 countries. Germany, the United States, Turkey, Iran, and France lead the count. Meanwhile, Trustwave researchers identified 5,271 vCenter instances accessible from the open internet via Shodan — every one of them a potential target.
What Attackers Leave Behind: The reverse_ssh Backdoor
Exploitation does not end with code execution. After gaining access via CVE-2026-59310, attackers deploy reverse_ssh — an open-source, Go-compiled reverse shell tool — to establish persistence. The key detail: it dials outbound rather than accepting inbound connections, bypassing firewall rules designed to block unsolicited access. It mimics legitimate SSH traffic and reconnects automatically if the session drops.
This matters for an important reason: if your vCenter was compromised before you applied the patch, the backdoor may still be present after patching. Patching closes the entry point, not the existing access. You need to audit your environment for active reverse_ssh connections and known indicators of compromise in addition to updating the software.
Affected Versions and the Fix
The following product versions are affected and must be updated immediately:
| Product | Affected | Fixed Version |
|---|---|---|
| vCenter Server 8.0 | Yes | 8.0 U3k |
| vSphere Foundation 9.0.x | Yes | 9.0.2.0100 |
| vSphere Foundation 9.1.x | Yes | 9.1.0.0300 |
| Cloud Foundation 9.0.x / 9.1.x | Yes | Bundled with above |
Broadcom has been explicit: there are no workarounds for CVE-2026-59310. No firewall rule, no configuration change, no feature disable reduces risk. The only remediation is updating to the patched version. Patches are cumulative and do not require prior updates. Get the fix from the Broadcom support portal (VMSA-2026-0006).
Five Things to Do Right Now
- Check your vCenter version. Log into the vSphere Client, navigate to Administration > Deployment > System Configuration, and confirm your exact build number against the affected versions above.
- Apply the patch immediately. vCenter Server 8.0 U3k, vSphere Foundation 9.0.2.0100, or 9.1.0.0300 depending on your branch. No workarounds exist — there is no substitute for updating.
- Audit for reverse_ssh connections. Check for outbound SSH connections from vCenter hosts that do not match your known management traffic. Look for unknown processes with established outbound SSH sessions.
- Check for indicators of compromise. Review Rapid7’s ETR and QUIRSO GmbH’s research for attacker-controlled infrastructure indicators. Cross-reference your network logs against known command-and-control addresses.
- Segment vCenter from the internet. If your vCenter management interface is reachable from outside your network, fix that today. 5,271 internet-exposed vCenter instances is 5,271 reasons this keeps happening.
The exploitation of CVE-2026-59310 follows a pattern the industry keeps refusing to learn from: critical vCenter flaws are weaponized within days of disclosure, and organizations that delay patching management infrastructure pay the price. Full technical analysis is available in BleepingComputer’s coverage and the Rapid7 ETR linked above.
