Back to Blog

A Security Patch Dropped on July 29. Ransomware Was Spreading From the Same Hole Five Days Later.

Five days. That’s how long it took for a patch to become irrelevant for hundreds of organizations that hadn’t applied it yet.

On July 29, Broadcom released a fix for CVE-2026-59310, a critical flaw in VMware vCenter Server.[1] The vulnerability scored 9.8 out of 10 on the CVSS scale. By August 3, researchers had tracked 361 compromised servers across 47 countries. At least one victim ended up with ransomware on their systems before anyone from their IT team had a chance to react.[2]

What VMware vCenter Is and Why It Matters

If you’re not familiar with VMware, here’s the short version. Many businesses run multiple servers, but instead of buying a separate physical box for each one, they run virtualization software that lets one physical machine pretend to be several. VMware is the most common platform for doing this.

vCenter is the management layer that sits on top of all of it. It’s what IT teams use to control every virtual machine from a single console. And that’s exactly what makes it an attractive target: whoever compromises vCenter has a path to every virtual machine the server is running. One hole, all the keys.

What the Vulnerability Actually Does

CVE-2026-59310 is a directory-traversal flaw.[3] The basic idea is that an attacker sends a specially crafted request that tricks the server into stepping outside the directories it’s supposed to access. In this case, the flaw allowed unauthenticated remote attackers to execute arbitrary code with root-level privileges. No username. No password. Just a malicious request, and they own the system.

A related vulnerability, CVE-2026-59309, affecting VMware vSphere Client, was patched at the same time.

Five Days From Patch to Active Exploitation

Broadcom released the patches on July 29. By August 3, exploitation had already begun at scale.[1]

German incident response firm QUIRSO tracked 361 unique victim IP addresses across 47 countries, including 41 in the U.S. and 55 in Germany.[3] Researchers attributed the campaign with moderate confidence to a Chinese-speaking threat actor, based on compilation timestamps and the UTC+08:00 activity patterns of the attackers.

In confirmed incidents, the attack chain was straightforward and devastating. Exploitation of CVE-2026-59310 gave the attackers immediate root code execution on the vCenter appliance. From there they installed a backdoor, established reverse SSH tunnels for persistent access, and ultimately deployed ransomware derived from the Babuk family on compromised environments.[2]

Babuk ransomware is worth knowing about. Its source code leaked years ago, and criminal groups have been building custom variants ever since. The fact that a state-adjacent group is deploying it suggests this campaign had a financial component alongside whatever intelligence objectives were in play.

Why Small Businesses Should Care About This

On the surface, VMware vCenter sounds like an enterprise problem. And it’s true that not every small business runs it directly. But plenty do, and plenty of small business IT environments are managed by providers who run VMware infrastructure on behalf of their clients.

Here’s the scenario that should concern you. Suppose your IT environment runs on a virtualized server: one VM for your accounting software, one for your file storage, one for your line-of-business application, one for your email. They all feel like separate systems. But they’re all sitting on the same physical host, managed through vCenter. An attacker who compromises vCenter doesn’t need to find a vulnerability in each of those applications individually. They already have the keys. Everything on that server is now within reach, and ransomware can move across all of it at once.

The Window Has Gotten Very Short

The five-day gap between patch release and active exploitation isn’t unique to this story. It’s becoming the norm. A few years ago, organizations might have had weeks or even months before attackers built working exploits for a newly disclosed vulnerability. That time has compressed sharply.

Part of the reason is that when a vendor like Broadcom releases a patch, security researchers analyze the difference between the patched and unpatched code to understand exactly what was fixed. That analysis gets published quickly, and sophisticated threat actors read the same research. The patch itself becomes a roadmap for building the exploit.

What this means practically: “we’ll patch it next maintenance window” is no longer an acceptable response to a CVSS 9.8 vulnerability under active exploitation. The maintenance window needs to become the same week.

One Question to Ask Your IT Team

You don’t need to become a VMware expert. You need one answer from whoever manages your servers: has CVE-2026-59310 been patched, and when?

The fix is included in VMware vCenter GA release 8.0 Update 4b and the corresponding vSphere Client update, both released July 29.[1] If your provider manages a VMware environment on your behalf, this should have been done during the first week of August. If it wasn’t, that’s important to know.