A patch closes a hole. It does not evict whoever already climbed through it. In five days this August, one of them did — 361 victims across 47 countries, on appliances many of which were already patched.
On July 29, 2026, Broadcom published VMSA-2026-0006, an emergency advisory for a pair of critical flaws in VMware vCenter Server: CVE-2026-59309, an authentication bypass in VMware Directory Service, and CVE-2026-59310, a directory traversal flaw in the vCenter Syslog server that lets an unauthenticated attacker with network access execute arbitrary code. Both carry a CVSS score of 9.8. Broadcom shipped fixed builds the same day: vCenter 9.1.0.0300, 9.0.2.0100, and 8.0 U3k or U2f depending on branch.
Five days later, on August 3, German incident-response firm QUIRSO recorded the first confirmed compromise. By August 4, new victims were arriving at a rate of 151 a day. By August 5, ninety-five percent of what would become 361 unique victim IP addresses across 47 countries had already been hit. The affected sectors were technology, software, cybersecurity, academia, research, and telecommunications, and QUIRSO's data showed one country conspicuously absent from the victim list: mainland China.
QUIRSO tracks the campaign as a suspected Chinese-nexus intrusion set, at moderate confidence. The basis is circumstantial but consistent: Chinese-language code comments, a toolset that leans on Chinese-language security research, UTC+8 working hours in the attacker's activity, and a victim list that excludes the one country you would expect a domestic actor to spare. QUIRSO has been explicit that this is not enough to name a known group. Their own writeup calls it an “uncategorized Chinese-nexus intrusion set,” not an attributed APT with a name a reader would recognize.
What the attackers did after getting in is the more interesting story, and it is documented in more direct detail than the disclosure itself. Compromised vCenter appliances got a reverse SSH connection out, using the open source reverse_ssh framework, an outbound-only channel that also happens to route around most perimeter firewall rules built around inbound traffic. Persistence went in two directions: fake cron jobs disguised as legitimate VMware scheduled tasks, and new SSO administrator accounts created directly on the compromised vCenter Directory Service. Some victims saw payloads staged through AList, an open source file-listing tool being used here as an ad hoc delivery server. Before encryption, the attackers stopped VMware's High Availability agent on each host, the service whose entire job is to notice a failed virtual machine and restart it elsewhere. Then came the payload: Babuk-derived ransomware, encrypting ESXi datastores and appending the extension .babyk.
Here is the detail that should outlast the news cycle. QUIRSO's COO and co-founder, Denis Szadkowski, put it in one sentence that is worth reading twice: “If the threat actor exploited the flaw in a vulnerable vCenter instance and used reverse_ssh, the attacker's access will persist even after the software is updated to a fixed version.” Patching vCenter closes CVE-2026-59310. It does nothing to the reverse SSH tunnel an attacker already opened, the SSO account already created, or the cron job already scheduled. Szadkowski's own phrase for the situation is exact: “it is essentially a race between exploitation and patching.” An organization that patched on schedule and moved on has not necessarily done anything wrong. It may simply have lost a race it did not know it was running.
Initial access — July 29 to August 3. Broadcom's advisory disclosed two independently exploitable, unauthenticated, network-reachable vulnerabilities in the same management plane on the same day: an authentication bypass in VMware Directory Service (CVE-2026-59309) and a directory-traversal-to-RCE flaw in the vCenter Syslog server (CVE-2026-59310), both CVSS 9.8. QUIRSO's tracked campaign centers on exploitation of CVE-2026-59310; their reporting notes related activity around CVE-2026-59309 without establishing the precise chaining between the two. Rapid7's own advisory analysis, published at disclosure, stated plainly that there was “no known evidence of exploitation or scanning in the wild for either CVE” and no public proof-of-concept at that point. Four days later, that had changed.
Command and control — August 3 onward. Once inside, the operators deployed reverse_ssh, a legitimate open source penetration-testing utility repurposed as an outbound C2 channel. Outbound SSH traffic from a vCenter appliance is exactly the kind of connection most perimeter monitoring is not tuned to flag, because it looks like the appliance reaching out for updates or telemetry, not an attacker reaching in.
Persistence — parallel to C2. Two mechanisms ran side by side: cron jobs disguised to resemble legitimate VMware scheduled tasks, giving the attacker a way back in even if the SSH tunnel were noticed and killed, and new administrator accounts created directly in VMware Directory Service. A new SSO admin account does not look like malware. It looks like a colleague nobody remembers approving.
Staging — as needed. Some intrusions used AList, an open source file browser and hosting tool, to stage additional payloads for retrieval, which is a lower-friction way to move tooling onto a compromised host than standing up dedicated attacker infrastructure that a threat intelligence feed might already know about.
Defense evasion — immediately pre-impact. Before encrypting anything, the operators stopped the VMware High Availability agent on affected hosts. HA's function is to detect a failed or unresponsive virtual machine and restart it on another host in the cluster. An operator mid-encryption does not want VMware helpfully restarting the machine they are still working on, or triggering alerts tied to unexpected VM state changes. Killing HA first is a small step with an outsized effect on how cleanly the rest of the attack proceeds.
Impact. Babuk-derived ransomware encrypted ESXi datastores, appending .babyk to affected files. QUIRSO's own writeup includes a caution that should shape how this detail is read: Babuk's source code leaked in 2021 and has since been adopted by numerous unrelated threat actors. A Babuk-derived payload is now closer to a commodity choice than a signature, which means it tells you less about who did this than the operational tradecraft around it does.
Most coverage of this campaign will read as a straightforward patch story: critical flaw, emergency fix, attackers moved fast, here is the timeline. That framing is accurate and it is also the less important half of what happened.
The real exposure is what Szadkowski named directly: the compromise and the patch are not the same event, and closing one does not undo the other. An organization running vulnerability management well, patching within days of an emergency advisory, can still be running a fully patched vCenter with an attacker's reverse SSH session, a fake cron job, and an admin account it never approved sitting inside it. The patch fixes what let the attacker in. It says nothing about what the attacker did once they were there, and by design, it cannot, because a code fix for CVE-2026-59310 has no way to know that a specific customer's Directory Service now contains an account it should not.
This is also why the China-nexus attribution, while a legitimate research finding, is close to beside the point for a defender deciding what to do this week. Whether the operator is a state-linked group, a criminal affiliate borrowing state-linked tradecraft, or something QUIRSO has not yet categorized changes very little about the actual defensive question, which is: does this specific environment show evidence of the specific persistence mechanisms this campaign is known to use, independent of who is behind the keyboard.
The technique that deserves the most attention here is not the initial vulnerability. Directory traversal to RCE in a syslog service is a familiar shape. What is less familiar, and more durable as a lesson, is the deliberate order of operations after access: establish an outbound channel that evades inbound-focused monitoring (T1572.001 — Protocol Tunneling), lay two independent persistence mechanisms rather than one (T1053.005 — Scheduled Task/Job: Scheduled Task and T1136 — Create Account), stage tooling through a legitimate-looking file host rather than dedicated infrastructure (T1608.001 — Stage Capabilities: Upload Malware), and only then disable the one platform service most likely to interfere with the final step (T1489 — Service Stop) before executing impact (T1486 — Data Encrypted for Impact).
None of these steps individually would stop most security teams in their tracks. Together, in this sequence, they describe an operator who assumed the vulnerability would eventually be patched and built persistence that does not depend on the vulnerability staying open. That assumption was correct. The vulnerability was patched, in most cases within days. The persistence, in an unknown number of those cases, was not found in the same window.
A vulnerability management program that patched VMSA-2026-0006 within its normal SLA did the right thing, on schedule. It also, in this specific case, would not have been enough on its own, because the advisory addressed the door, not whoever might already be standing in the hallway.
The gap is not a patching failure. It is a validation failure: the absence of a routine, repeatable way to test whether a specific ransomware family's actual behavior, not a generic “ransomware simulation,” would be caught by the controls in front of it, and whether the specific persistence techniques this campaign is known to use are things the environment can actually detect rather than things it is merely assumed to detect. Controls that exist on paper, an EDR agent deployed, a SIEM rule that mentions ransomware, a backup policy that has never been tested against a live encryption event, do not answer the question a board asks after reading a story like this one: could this have happened to us, and would we have known.
Three actions, in order of how quickly they close the actual exposure this campaign demonstrated, not just the CVE:
First, hunt for the persistence, not just the patch level. Before treating a vCenter environment as remediated, check specifically for the indicators this campaign is known to leave: unexpected SSO administrator accounts, cron jobs that do not match a known VMware baseline, outbound SSH sessions to unfamiliar destinations, and any period where the HA agent was stopped without a documented maintenance window.
Second, treat “patched” and “clean” as two different claims. A patch confirms the vulnerability is closed. It says nothing about what happened in the window before it was applied. Any organization that had an internet-reachable, unpatched vCenter instance between July 29 and its own patch date should treat that window as a forensic question, not a closed ticket.
Third, ask whether a Babuk-derived encryption event, specifically, would be caught, not ransomware in the abstract. This is where the evidence problem becomes structural rather than incidental. digiDations built the Isolator component of ATLAS™ specifically for this class of question: detonating real, working ransomware, including known-family payloads, inside ACL-isolated containment with full post-test snapshot rollback, so a security team can see how their actual controls respond to an actual encryption attempt rather than to a synthetic simulation of one. The output is not a report that says “vulnerable” or “not vulnerable.” It is Sigma and Suricata detection rules generated directly from what the test revealed, so the gap it finds becomes something the SOC can act on the same day rather than a line item in next quarter's roadmap.
None of this replaces patching quickly. Broadcom's same-day emergency patch was the right response, and applying it fast was the right call for every organization that did. The point is narrower and, this time, better evidenced than usual: a patch answers the question “is the door still open.” It was never designed to answer “who already came through it, and what did they leave behind.” Only testing against what the attacker actually did can answer that one.