One vCenter Patch, Two Unauthenticated Bugs, 361 Servers Already Hit

361. That is the number of vCenter servers Shadowserver had confirmed compromised across 47 countries when it pushed a special victim-notification report on August 13 - and the bug behind that number is not even the worse of the two Broadcom patched on July 29.

VMSA-2026-0006 shipped fixes for five vulnerabilities in vCenter and ESX. Two are unauthenticated, network-reachable, and rated CVSS 9.8. CVE-2026-59310, a directory-traversal bug in the vCenter Syslog server, is the one German incident-response firm QUIRSO caught being exploited for remote code execution starting August 3, five days after disclosure, with a persistence mechanism that survives a reboot. CVE-2026-59309 is the one that should worry you more: an authentication bypass in the VMware Directory Service, the embedded SSO domain that every vCenter, linked ESX host, and connected plugin in your environment trusts to decide who gets in.

No confirmed mass exploitation of CVE-2026-59309 has surfaced yet. Take that as a warning, not as reassurance. Attackers are already inside the same appliance class through its sibling bug, and a working authentication bypass into the identity plane that governs an entire virtualization estate rarely stays quiet for long once its neighbor is being actively worked.

If you do not run self-hosted vCenter or ESX - if your virtualization is fully outsourced to a cloud provider with no on-prem appliance in your inventory - this one genuinely is not yours. If you, or an MSP acting on your behalf, run even one on-prem vCenter Server reachable from anywhere on your network, keep reading. That describes most mid-market and small-business virtualization deployments Red Hound sees, because vCenter is usually the one console holding credentials to everything else.

vCenter earns that role by design. It is the one appliance most virtualization teams intentionally expose to more of the network than anything else it manages, because provisioning, backup, monitoring, and disaster-recovery tooling all need a path to reach it. That convenience is exactly why an unauthenticated bug here is worse than the identical bug in almost any other appliance on the network - it was already trusted by everything else long before the vulnerability existed.

What's actually broken in VMSA-2026-0006

Broadcom credits Phil Brass and Matt South of Atredis Partners with finding both flagship bugs. CVE-2026-59309 lets a network-adjacent attacker bypass authentication entirely and reach the vCenter management plane with no credentials. CVE-2026-59310 lets an unauthenticated attacker walk a directory-traversal path in the Syslog server into arbitrary code execution on the appliance itself. Both carry a CVSSv3.1 base score of 9.8: network attack vector, no privileges required, no user interaction. Broadcom lists no workaround for either. The same advisory also patches three lower-severity ESX bugs - an out-of-bounds write in the VMXNET3 virtual network adapter, an out-of-bounds read, and an insufficient-logging flaw - but the two 9.8s are what turned this into an active-exploitation story within a week of disclosure.

The facts, in one place

• Advisory: VMSA-2026-0006.1, published July 29, 2026, updated August 3.
• Worst bugs: CVE-2026-59309 (VMDir authentication bypass) and CVE-2026-59310 (Syslog server directory traversal to code execution), both CVSS 9.8.
• Patched: vCenter 9.1.x to 9.1.0.0300, vCenter 9.0.x to 9.0.2.0100, vCenter 8.0 to 8.0 U3k; ESXi 9.1.x to ESXi-9.1.0.0200, ESXi 9.0.x to ESXi-9.0.2.0100, ESXi 8.0 to U3k, U3j, U3i, or U2f; VMware Cloud Foundation 5.x via an async patch.
• CISA KEV status at publication: neither CVE is listed, despite confirmed active exploitation of one of them.

The persistence mechanism that outlives your patch window

QUIRSO's investigation, reported by The Hacker News and confirmed in Shadowserver's special report, traced a consistent attack chain: exploit the CVE-2026-59310 directory-traversal path, drop a cron job into the vCenter appliance's own crontab, and use that cron job to launch reverse_ssh, an open-source tool that opens an outbound SSH connection to attacker-controlled infrastructure. The cron entry runs at startup and on a recurring interval, so the foothold survives a reboot. Because the connection is outbound, it walks straight past firewall rules written to keep people out rather than watch what a trusted appliance calls home to.

The growth curve is the part that should change how you think about your response window. Shadowserver and QUIRSO logged 151 victim IP addresses by August 4, 343 by August 5, and 361 across 47 countries - concentrated in Germany, the United States, Turkey, Iran, and France - within days of the campaign starting. QUIRSO's own assessment: the strong correlation between the disclosure date and the first observed exploitation points to the public advisory itself as the starting gun for the campaign. Nobody had to reverse-engineer a silent patch diff. The advisory was the map.

Verify the build before you trust the patch

Patching stops new exploitation. It does not undo a cron job that already ran. Confirm the running version first, on every vCenter and ESXi host in your inventory, not just the one someone remembers standing up.

# Run against each vCenter Server Appliance over SSH.
# vpxd prints the build the running service was compiled at -
# compare it against the fixed builds in VMSA-2026-0006.1, not just the major version.
ssh root@vcenter.internal "vpxd -v"

# Target builds: vCenter 9.1.x -> 9.1.0.0300, 9.0.x -> 9.0.2.0100, 8.0 -> 8.0 U3k

# On each ESXi host:
esxcli system version get

The vSphere Client's own About page is not a reliable check by itself. Environments running VMware Cloud Foundation apply the async patch to the underlying vCenter on a different track than a standalone deployment, and a linked-mode group can end up with one member current while the others sit on the vulnerable build long after someone believes the whole environment is patched. Check every member individually.

If the build predates the fix and the appliance has been reachable from anywhere outside a tightly scoped management network since July 29, do not treat the patch as the end of the incident. Move to the hunt below before you close the ticket.

Hunt for reverse_ssh even on a patched appliance

QUIRSO's indicator is specific enough to search for directly: a cron-launched reverse_ssh process holding open an outbound connection the appliance has no legitimate reason to maintain.

# On the vCenter appliance (root shell or console access):

# 1) Look for an injected cron entry - anything referencing reverse_ssh,
#    a hidden dotfile path, or a binary outside the normal appliance tree.
crontab -l 2>/dev/null | grep -Ei "reverse_ssh|\.cache/|/tmp/\."

# 2) Search common writable paths for the dropped binary or its config.
find / -xdev \( -iname "reverse_ssh*" -o -iname ".rvssh*" \) 2>/dev/null

# 3) List established outbound connections - a vCenter appliance has
#    no routine reason to be acting as an SSH client.
ss -tnp 2>/dev/null | awk '$1=="ESTAB"{print}' | grep -v ":443\|:902\|:389\|:636"

Treat a hit as a confirmed compromise, not a suspicious finding. Shadowserver's report classifies every listed IP as fully compromised specifically because the persistence mechanism was already installed by the time it was observed, and legitimate operational use of reverse_ssh on a vCenter appliance is rare enough that a match deserves an incident response, not a follow-up ticket.

It is also worth checking whether the original traversal attempt is still sitting in your logs. The appliance's own reverse-proxy access log records the raw HTTP request path reaching the Syslog server; a directory-traversal payload aimed at that endpoint reads distinctly differently from routine syslog forwarding traffic, and it is worth a manual pass even if your log pipeline has no alert built for it yet. Finding the request without finding the cron job tells you someone tried and either failed or has not returned to finish the job.

Why VMDir deserves domain-controller-grade attention

VMware Directory Service, the component CVE-2026-59309 breaks, is the identity backbone of the vsphere.local SSO domain - the service that decides whether a login to vCenter, an ESX host joined to that domain, or a third-party backup or monitoring tool with a service account succeeds. I treat any system that plays that role the same way I treat a domain controller in an on-prem Active Directory environment: own the directory, and you inherit trust across everything federated to it, not just the one console you logged into.

Most vCenter hardening guidance still reads like it is protecting a management tool. It is protecting an identity provider that happens to also manage virtual machines, snapshots, and the credentials other tools use to reach them. Restrict vCenter's management interface to a dedicated administrative network the way you would a domain controller. Audit who and what authenticates against vsphere.local the way you would audit domain admin group membership. Neither control would have stopped CVE-2026-59310's directory traversal, but both shrink what an attacker gets once CVE-2026-59309, or whatever comes after it, eventually gets a working public exploit.

Push vpxd and VMDir authentication events to whatever SIEM already ingests your domain controller security log, and alert on the same anomalies you already watch for there: a spike in failed binds, authentication from a source IP nobody on the team recognizes, or an administrative session opened outside a normal maintenance window. Most environments already built that pipeline for Active Directory. Extending it to vsphere.local is a configuration change, not a new tool to buy.

Assume compromise on any vCenter unpatched since August 3

Patch to the fixed builds on every vCenter Server and ESXi host this week - there is no workaround, so patching is the only control Broadcom offers. Then run the hunt above regardless of whether the appliance was already current, because a build number only proves you closed the door on the day you checked it; it does not prove nobody walked through it before then. If you find the cron entry or the unexplained outbound connection, isolate the appliance, rotate every credential VMDir could authenticate - vCenter admin accounts, linked-mode partners, and any service account tied to backup, monitoring, or disaster-recovery tooling - and scope the incident from there rather than assuming a reboot fixed it.