vCenter CVE-2026-59310: exploited in five days

On July 30 we wrote about the two CVSS 9.8 vCenter bugs and said the lack of known exploitation was a scheduling detail, not a reprieve. Here's the schedule: five days. CVE-2026-59310, the directory traversal in the vCenter Syslog server, was disclosed on July 29 and attacker infrastructure started receiving callbacks from compromised hosts on August 3.

What actually happened

QUIRSO's threat research team found the campaign during an incident response engagement and is tracking a suspected APT actor. Per QUIRSO's writeup and The Hacker News, the numbers are ugly and fast: first callbacks on August 3, another 151 victim IPs on August 4, and 343 of the eventual 361 — about 95% — seen by August 5. Final count: 361 unique victim IP addresses across 47 countries, with more than half in Germany, the United States, Turkey, Iran and France.

The post-exploitation is boring in the way that works. After landing code execution through the traversal flaw, the attacker deploys reverse_ssh, an open-source framework, via cron jobs. That gives an outbound command-and-control channel and persistence that survives a reboot. Outbound is the important word — a firewall configured to block inbound connections does nothing about a host that dials out on its own.

Broadcom shipped fixed builds in VMSA-2026-0006 on July 29 (vCenter 8.0 U3k, 9.0.2.0100, 9.1.0.0300). There is still no workaround. Anyone who patched inside a week was fine. Everyone else had roughly a weekend.

Why this vCenter exploitation timeline matters for your business

Your patch SLA is the whole story. If your MSP's contract says thirty days for criticals, this bug owned the cluster on day five and sat there for twenty-five more. A monthly patch window is a reasonable policy for most software and a fatal one for internet-reachable management planes. Split the policy: an emergency track for anything unauthenticated, network-reachable and rated 9-plus, measured in days.

Egress filtering is the control most small networks skip. reverse_ssh works because the compromised host is allowed to open arbitrary outbound connections. A hypervisor management interface has no legitimate reason to reach the open internet. Deny outbound by default from the management VLAN, allow the handful of destinations it actually needs, and the persistence step fails even when the exploit lands.

Patched is not the same as clean. If your vCenter was internet-reachable between July 29 and the day you patched, patching closed the door on a host that may already have a resident. Check for unexpected cron entries, unknown outbound SSH sessions, and new accounts. Then ask your provider — in writing — for the exact patch date, not the month.

Most of you don't own the vCenter. Your MSP does, and your servers are tenants on it. That makes their patch timeline your risk register.

Sources: QUIRSO Threat Research, The Hacker News.