On July 29, 2026, Broadcom published VMSA-2026-0006, disclosing five vulnerabilities in VMware ESX, vCenter, Workstation, and Fusion. Two of them — CVE-2026-59309 and CVE-2026-59310 — carry a CVSSv3.1 base score of 9.8 and can be triggered by an unauthenticated attacker with nothing more than network access to vCenter (Rapid7).

Five days later, someone was using them. By August 5, an estimated 95% of what would become 361 compromised vCenter servers across 47 countries had already been hit (Infosecurity Magazine, German incident-response firm QUIRSO). CISA added CVE-2026-59310 to its Known Exploited Vulnerabilities catalog on August 18 (CISA). That's the pattern the past two years of vCenter and ESXi disclosures have trained defenders to expect: a critical flaw in the layer everything else runs on top of, exploited faster than most organizations can patch it.

What's actually broken

CVE-2026-59309 is an authentication bypass in vCenter's Directory Service (VMware Directory Service, vmdir). CVE-2026-59310 is a directory-traversal flaw in vCenter's Syslog server that an attacker can use to write arbitrary files and, from there, execute code on the underlying host (Rapid7). Broadcom has published no workarounds for either — patching is the only remediation. Fixes are available in VMware Cloud Foundation and vSphere Foundation 9.1.0.0300, VMware Cloud Foundation and vSphere Foundation 9.0.2.0100, and VMware vCenter Server 8.0 U3k.

Neither bug is exotic. A directory-traversal flaw in a logging service, chained into arbitrary code execution, is a well-understood vulnerability class. What makes it dangerous here is where it lands: vCenter is the single management plane for an organization's entire vSphere estate — every ESXi host, every VM, every resource pool, all controlled from one console. Compromising vCenter doesn't get an attacker one server. It gets them administrative reach into whatever that vSphere cluster runs.

Five days from patch to compromise

QUIRSO's research team found the campaign during an incident-response engagement and assessed with moderate confidence that it's the work of a Chinese-speaking threat actor, likely operating in the UTC+08:00 time zone, though attribution to a specific known group hasn't been made public (QUIRSO, The Hacker News).

The attack chain itself is efficient rather than elaborate. After exploiting the directory-traversal bug, the actor drops a malicious cron job into the vCenter appliance's crontab, configured to run at startup and at regular intervals so the foothold survives a reboot. That cron job launches reverse_ssh, an open-source tunneling utility, which opens an outbound SSH connection to attacker-controlled infrastructure (The Hacker News, Infosecurity Magazine). Because the connection is outbound and uses a standard protocol, it's the kind of traffic a lot of network monitoring is tuned to ignore.

In at least one documented case, the intrusion escalated to Babuk-derived ransomware deployed against ESXi hosts (The Hacker News). What's notable is what researchers make of that: several have floated the theory that the ransomware isn't necessarily the objective, but a smokescreen — noisy enough to pull incident responders' attention toward file recovery while the quieter access the reverse-SSH backdoor provides goes unaddressed (The Hacker News). Whether or not that theory holds for every victim, it's the right way to think about any ransomware note that shows up on infrastructure this valuable: it may be the least important thing that happened during the intrusion.

Why this isn't just a data-center story

Financial services, healthcare, government, managed service providers, and manufacturing all show up as high-exposure sectors in the coverage of this campaign, for the same underlying reason: vSphere is what a large share of enterprise data centers run on, including the servers that host MES, historian, and other production-adjacent systems that manufacturers depend on to keep a line running (DecryptionDigest, Preferred Data).

That's the connection worth sitting with. Most OT security programs are built to watch the boundary between IT and the plant floor — segmentation, protocol-aware monitoring, PLC-facing detection. Few are built to watch the virtualization layer that IT and OT-adjacent systems both quietly depend on. If the historian server, the MES database, or the engineering workstation's golden image all live as VMs under a compromised vCenter, an attacker with root on that management plane doesn't need to touch a single PLC to affect production. They can clone a VM, exfiltrate a disk image wholesale, or simply take the host down. Dragos's Q2 2026 ransomware data already showed that IT-side disruption alone is enough to stop a manufacturing line — this campaign is a reminder that the disruption doesn't even need to originate in IT proper. It can start one layer further down, in infrastructure most security teams never model as an attack surface at all.

What to do now

  1. Patch immediately if you haven't. There are no workarounds for CVE-2026-59309 or CVE-2026-59310 — move to VMware Cloud Foundation/vSphere Foundation 9.1.0.0300 or 9.0.2.0100, or vCenter Server 8.0 U3k.
  2. Assume compromise if your vCenter was internet-reachable or unpatched between July 29 and today, and hunt rather than just patch: check the appliance crontab for unrecognized entries, and look for reverse_ssh binaries or outbound SSH connections to unfamiliar infrastructure.
  3. Inventory what actually runs under each vSphere cluster. If you can't quickly answer "what production-adjacent systems live as VMs under this vCenter," that's the same visibility gap that lets a compromise go unnoticed.
  4. Take vCenter off the general network. Management-plane access belongs on a restricted management network, not reachable from the same segment as general enterprise traffic — the same segmentation logic OT teams already apply to engineering workstations.
  5. Don't let a ransomware note end the investigation. If Babuk-derived ransomware shows up on affected ESXi hosts, treat it as a signal to look harder for the access it may be covering, not as the incident's conclusion.

Where MBCTG fits

This campaign sits at exactly the seam our OT security services are built to cover: the infrastructure layer underneath production systems that traditional OT monitoring doesn't reach and traditional IT vulnerability management doesn't prioritize highly enough, fast enough. Passive asset visibility that maps what actually runs on a compromised vCenter — not just the vCenter itself — is what turns "we patched it" into "we know nothing was taken first."

Our 24/7 SOC is positioned to catch exactly the behavior this campaign relies on going unnoticed: an unfamiliar outbound SSH tunnel, a cron job that shouldn't be there, activity on a management plane outside a change window. If you're running vSphere anywhere near production and haven't confirmed you're patched and haven't hunted for signs of prior compromise, that's the conversation worth having this week. Talk to an MBCTG expert.