The spies got there first. The ransomware crews just took over their access.

CVE-2026-59310 is a CVSS 9.8 directory traversal in the VMware vCenter syslog server. Broadcom patched it on 29 July 2026. Exploitation began five days after disclosure. On 15 September, CISA updated its Known Exploited Vulnerabilities entry to confirm what defenders had been dreading: ransomware operators have joined a campaign that until then looked like quiet espionage.

Seven weeks separate the patch from that confirmation. For a lot of organisations, those seven weeks are not a gap in a timeline. They are the period during which someone else was administering their virtual estate.

WHAT ACTUALLY HAPPENED

The flaw lives in the syslog service on vCenter Server. An unauthenticated attacker can traverse outside the intended path and write where they should not, which ends in arbitrary code execution on the appliance. No credentials, no user interaction, no phishing email. Just network reachability to a management service.

The first wave was disciplined. Operators used the flaw to deploy a reverse SSH tool — a small persistent callback that dials out from vCenter to attacker infrastructure, so no inbound firewall rule has to be touched and nothing looks like a listening backdoor. Investigators confirmed compromises at 361 IP addresses across 47 countries. That is not opportunistic scanning. That is a campaign with a target list.

Then the profile changed. CISA's KEV update on 15 September flagged the CVE as abused in ransomware operations. Shadowserver still tracks more than 450 vCenter servers exposed directly to the internet — seven weeks after a fix existed.

WHY VCENTER IS THE PRIZE

vCenter is not a server. It is the control plane for every server you run.

From that single appliance an operator can enumerate every virtual machine in the estate, snapshot them, mount their disks, detach them, migrate them, or power them off in bulk. Ransomware crews worked this out years ago: you do not need to deploy an encryptor to a thousand Windows hosts and fight a thousand EDR agents. You take the hypervisor layer and encrypt the datastores underneath.

That is the part most security programmes have not internalised. Your endpoint detection runs inside the guest operating systems. The attack happens below them. When the storage under a VM is encrypted, the agent inside that VM is not bypassed or disabled — it simply never sees anything, because from its perspective the disk just stopped existing.

The same asymmetry applies to logging. Most organisations ship Windows and Linux event logs to a SIEM with care, and forward vCenter logs either partially or not at all. The single most privileged machine in the data centre is frequently the least observed.

THE ACCESS HANDOFF

The most important detail in this story is not the vulnerability. It is the transition.

Intrusion sets are not monoliths, and access is a commodity. A crew with the skill and patience to weaponise a fresh vCenter flaw within five days is not necessarily the crew that wants to send a ransom note. Espionage-aligned operators want persistence and silence. Access brokers want revenue. When a foothold has yielded what it was going to yield — or when it starts looking likely to be discovered — it gets sold.

So the profile of an intrusion can change completely without any new exploitation taking place. The door was opened in early August by someone who wanted to watch. It was walked through in September by someone who wants to be paid.

This is why "we patched it" and "we are fine" are different statements. Patching removes the entry path. It does not remove the tenant. If an operator established a reverse SSH callback, added an SSH key, created a local account or extracted service credentials in August, every one of those survives the update you applied last week. You closed a window that nobody needs to use any more.

WHAT PATCHING DOES NOT UNDO

Remediation on this CVE has two halves, and most teams only did one.

Apply the fixed build, yes. Then work on the assumption that the appliance was compromised, and prove otherwise — because with seven weeks of public exploitation and a confirmed campaign at 361 addresses, "probably not us" is a hope, not a finding.

The things to go and look at are not exotic.

Outbound SSH from vCenter to anything on the internet. The appliance should almost never initiate sessions outward, so netflow or firewall logs from late July onward will answer this quickly.

The appliance's authorized_keys files and local account list. Any key or account you cannot map to a named administrator and a change ticket is a finding.

Administrative sessions in the vpxd and audit logs at odd hours, from unfamiliar source addresses, or from accounts that had not been used in months. If those logs have already rolled, that absence is itself worth documenting.

Scheduled tasks, cron entries and startup scripts on the appliance, which is where persistence is cheapest to hide.

Newly registered virtual machines and unexplained snapshots. A snapshot of a domain controller that nobody requested is an exfiltration staging step, not an operational accident.

If any of that turns up, you are running an incident, not a patch cycle — and rebuilding vCenter from a known-good image is usually faster and more defensible than trying to clean it.

WHAT TO DO NOW

PATCH, THEN INVESTIGATE — apply the fixed build immediately, then treat the appliance as suspect until hunting says otherwise; the order matters, but the second step is the one that gets skipped.

TAKE MANAGEMENT OFF THE PUBLIC INTERNET — vCenter, ESXi and their APIs belong behind a segmented administration network reached through a jump host with MFA, never on a routable public address; those 450 exposed servers are the next advisory's victim list.

SEPARATE VIRTUALISATION IDENTITY — if the account that administers vCenter is the same domain admin that administers your file servers, one compromise is both.

FORWARD HYPERVISOR LOGS OFF-BOX — an attacker with root on the appliance can edit its local logs, but cannot rewrite the copy already sitting in your SIEM.

TEST A RESTORE THAT DOES NOT NEED VCENTER — prove you can bring critical workloads back directly on an ESXi host, and prove your backups are immutable and offline.

MEASURE YOUR PATCH LATENCY ON THE CONTROL PLANE — count the days between vendor advisory and production patch for hypervisor, identity and network management systems specifically; that number is your real exposure window, and five days is the benchmark attackers are now setting.

THE UNCOMFORTABLE PART

Nothing about this intrusion required a novel technique. The vulnerability was public. The patch existed. The exposure was visible to anyone running a scanner, including Shadowserver, which publishes the count for free.

What made it work was organisational, not technical: management interfaces left exposed because it was convenient during a migration, a patch cycle that treats infrastructure appliances as lower priority than user endpoints, and a monitoring strategy that stops at the operating system boundary.

Virtualisation infrastructure is the highest-leverage target in the building and, in most estates, the least monitored asset in it. Attackers have fully absorbed that. Defensive programmes largely have not.

Do you know, right now, whether your vCenter is reachable from the public internet — and can you say with evidence who logged into it in August?