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 victim IP addresses across 47 countries had already appeared (Infosecurity Magazine, German incident-response firm QUIRSO). QUIRSO cautions that some of those addresses belonged to hosting providers, cloud environments, or shared infrastructure, so the IP count is not a count of affected organizations. 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 or 8.0 U2f, depending on the deployed branch. VMware Cloud Foundation 5.x gets an async patch to 8.0 U3k, and for vCenter 7.0 Broadcom says to contact Broadcom Support if you have an extended support contract (Broadcom, Infosecurity Magazine).

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. The actor exploits the directory-traversal bug in vCenter's syslog server to plant files in /etc/cron.d, and cron then runs the attacker's commands as root. Many of those cron jobs run every minute, and some are deleted once they've served their purpose. One of them fetches a script that installs reverse_ssh, an open-source tunneling utility, which opens an outbound SSH connection to attacker-controlled infrastructure. Where it has root, the script prefers to install it as a systemd service that restarts it automatically (QUIRSO, 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 the researchers make of that: QUIRSO suspects the ransomware may not have been the campaign's primary objective. Its researcher Denis Szadkowski likened the deployment to a smokescreen, engineered to distract defenders from the main intrusion and to hinder analysis by encrypting the ESXi log files. QUIRSO's forensic analysis covered only one infected system, so it can't yet say whether the ransomware was deployed on other compromised systems (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, and at a manufacturer that can mean the domain controller, ERP, file server, and SQL server all running as VMs on the same cluster (DecryptionDigest, Preferred Data). We'd add the MES and historian servers a line depends on, which can live on the same clusters.

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 or 8.0 U2f depending on your branch. On VMware Cloud Foundation 5.x, apply the async patch to 8.0 U3k. On vCenter 7.0, contact Broadcom Support if you have an extended support contract. For anything else, including the Telco Cloud products, follow the response matrix in Broadcom's advisory.
  2. Assume compromise if your vCenter was internet-reachable or unpatched between July 29 and today, and hunt rather than just patch: check /etc/cron.d and the cron logs (CROND entries) for unrecognized jobs, since the actor deletes some jobs after use. Also check for systemd services you didn't create, 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.