An advanced persistent threat actor has achieved persistent remote access to hundreds of VMware vCenter servers worldwide by exploiting a critical directory-traversal vulnerability patched less than two weeks ago. With no workaround available and exploitation actively underway across 47 countries, organisations running unpatched vCenter deployments face immediate risk to virtualised infrastructure spanning every sector.
The Vulnerability
CVE-2026-59310 is a directory-traversal flaw in the vCenter Syslog server component, rated CVSS 9.8. Exploitation requires only network access to the vCenter service — no authentication and no user interaction. An attacker able to reach vCenter over the network can traverse directory boundaries within the Syslog component, achieve remote code execution, and establish persistent access to the underlying host.
Broadcom issued advisory VMSA-2026-0006 on July 29, 2026, alongside a patch. No workaround exists: Broadcom states explicitly that patching is the only remediation. Affected versions span vCenter Server 8.x, 9.x, and the Cloud Foundation stack.
Exploitation Timeline and Scale
QUIRSO threat intelligence observed the first exploitation activity on August 3 — five calendar days after the patch release — consistent with attacker tooling built or adapted against the public advisory before organisations could complete patch cycles.
By August 13, QUIRSO had identified 361 victim IP addresses across 47 countries with confirmed connections to attacker-controlled infrastructure. Germany, the United States, Turkey, Iran, and France account for 185 of the observed victim IPs. The five-day window from patch to widespread exploitation is consistent with the threat actor having conducted pre-patch reconnaissance against exposed vCenter instances.
The attack chain is documented: path traversal through CVE-2026-59310, followed by deployment of a malicious cron job using reverse_ssh, an open-source SSH tunnelling tool, to establish persistent outbound access to attacker-controlled servers. The use of reverse_ssh avoids inbound firewall rules and is consistent with APT tradecraft observed in prior campaigns targeting virtualisation infrastructure.
Sector Impact
VMware vCenter is the primary management plane for virtualised environments across every critical sector. A compromised vCenter server gives the attacker hypervisor-level access to every virtual machine under management — including workloads processing clinical data in healthcare environments, trade and payment systems in financial institutions, and supervisory networks in OT-adjacent IT deployments. The persistence mechanism means that organisations without robust detection for outbound SSH tunnelling may not identify the compromise until data exfiltration or lateral movement has already occurred.
Organisations in the transport, logistics, and communications sectors have substantial VMware virtualisation footprints and should treat any unpatched vCenter deployment as potentially compromised.
Immediate Actions Required
Patch immediately. Broadcom’s advisory VMSA-2026-0006 provides the fixed versions. No workaround exists; this is not a vulnerability that can be mitigated through configuration hardening without applying the patch.
Audit reverse_ssh connections. Review outbound connections from vCenter hosts and ESXi hypervisors for SSH tunnels to external infrastructure. The attacker’s persistence mechanism creates persistent outbound SSH sessions that may not trigger standard alerting.
Check for cron job modifications. Inspect cron configurations on vCenter appliances for entries added after July 29. Unauthorised cron jobs are the documented persistence mechanism in confirmed exploitations.
Restrict vCenter access. If full patch deployment will take more than 24 hours, restrict network access to vCenter management interfaces to known administrative hosts only. This reduces the exploitable attack surface while patching proceeds.
Assume breach for unpatched instances. Any vCenter server reachable from the internet or from untrusted network segments that has not been patched since July 29 should be treated as potentially compromised and investigated accordingly, not simply patched and assumed clean.
The five-day exploitation window demonstrates that the threat actor maintained active operational readiness against this vulnerability class. Organisations with extended patch cycles for virtualisation infrastructure should treat this timeline as the current operational baseline, not an anomaly.