361 vCenter servers were compromised five days after the patch went public

CVE-2026-59310 is a directory-traversal flaw in Broadcom VMware vCenter, CVSS 9.8, allowing a network-accessible attacker to execute arbitrary code. Broadcom patched it in late July 2026.

German security firm QUIRSO found it being exploited during an incident response engagement, and then went looking for the scale of it.

The numbers

That last row is the one to hold onto. Public disclosure was in late July. Compromised systems started calling home on 3 August — five days later.

QUIRSO's read:

the strong correlation between the time of disclosure and exploitation suggests the disclosure as the initial starting point

Which is to say: the attacker did not have this before the advisory. They read the advisory, built the exploit, and were landing on hosts inside a working week.

The firm believes the activity is attributable to an APT actor, while stating that is unconfirmed.

The persistence is deliberately boring

The chain is path traversal, then a malicious cron job running reverse_ssh — an open-source tool that establishes an SSH connection outward to attacker infrastructure.

Reverse SSH is chosen because it inverts the direction of the connection. Perimeter controls are built to inspect what comes in; a host that dials out on a protocol it legitimately uses passes most of them.

QUIRSO adds a caution that deserves repeating:

The presence of reverse_ssh should not, by itself, be treated as proof of malicious activity

It is a legitimate administration tool. Finding it means investigate, not conclude — a distinction that gets lost when an IoC list travels without its context.

A second vCenter flaw is being scanned for

Defused Cyber separately reported increased scanning against CVE-2026-59309 (CVSS 9.8), an authentication bypass in vmdir.

Two 9.8s in the same product in the same window, one confirmed exploited and one being scanned, means vCenter is having the kind of month that ends with a KEV entry and a mandatory-patch directive.

Why five days is the real finding

The disclosure-to-exploitation interval is the number that should change behaviour. A patch cycle built around monthly maintenance windows assumes attackers need weeks. Here they needed five days, on a management plane.

And vCenter is a management plane. It is not a workload; it is the thing that controls the workloads, holds credentials to them, and can create, clone or destroy them. Compromising vCenter is closer to compromising a domain controller than to compromising a server.

We have made this point about the Cisco FMC zero-day and about Kemp LoadMaster reaching CISA's KEV catalogue, and the shape does not change: internet-reachable management interfaces get exploited fast, because the payoff justifies the effort.

What to do

• Patch CVE-2026-59310 now if you have not. Late July's release; check the build number rather than assuming.
• Check for cron jobs on vCenter appliances. You should be able to account for every entry. Anything invoking an SSH client outward is worth an investigation.
• Hunt outbound SSH from vCenter to anything that is not yours. This is the highest-value single detection here.
• Check whether vCenter is reachable from the internet at all. For most estates the honest answer is that it should not be, and the reason it is dates to a migration nobody revisited.
• Track CVE-2026-59309 too. Scanning is the stage before exploitation, not a separate event.