Eight days after Broadcom patched two critical VMware vCenter flaws, the trade press coverage of what happened next reads like a timeline of an intrusion in slow motion: mass opportunistic scanning within days of disclosure, then a suspected nation-state actor deploying ransomware on ESXi hosts by the following week. Reading three separate outlets side by side over that stretch, Infosecurity Magazine, Dark Reading and The Hacker News, shows a story that changed shape as it went, and what the three add up to together is not the vulnerability itself. It is how fast an opportunistic exploitation wave matured into a targeted, persistent operation, and how little of that second stage showed up in the first week of headlines.
What Broadcom Patched, and How Fast the Clock Started
On July 29, 2026, Broadcom shipped patches for two critical vCenter Server flaws: CVE-2026-59310, a directory traversal bug in the vCenter syslog server that allows arbitrary code execution, and CVE-2026-59309, an authentication bypass in the VMware Directory Service. Both carry a CVSS score of 9.8, both affect VMware Cloud Foundation, vSphere Foundation and vCenter 8.0, and Broadcom’s advisory lists no workaround for either, patching was the only option. The company credited Phil Brass and Matt South of Atredis Partners with reporting the pair.
CyberTech covered the first wave of exploitation when it became a five-day story: opportunistic scanning against unpatched vCenter instances began within days of the advisory going public, well before most enterprise change-management cycles could complete a patch. That is where most coverage of this flaw stopped a week ago. It is not where the story ended.
Media Partner
Three Outlets, Three Different Emphases
Infosecurity Magazine: the speed of opportunistic exploitation
Infosecurity Magazine reported the flaw was under active exploitation just five days after disclosure, framing the story around velocity: how little time defenders had between a critical advisory and the first confirmed attacks against unpatched, internet-facing instances.
Dark Reading: the breadth of the campaign
Dark Reading’s framing emphasized scale over speed, describing a global threat campaign against the flaw rather than isolated incidents, consistent with the kind of broad, automated scanning that typically follows a critical unauthenticated RCE in widely deployed infrastructure software.
The Hacker News: a narrower, more dangerous second act
By August 17, The Hacker News reported a materially different threat model. Citing research from the German incident-response firm QUIRSO, the outlet detailed a suspected China-nexus actor that used the same two flaws not for smash-and-grab access, but to establish persistence: a WebSocket-based backdoor, a reverse SSH binary, and web shells disguised as vCenter performance-update scripts, followed by unauthorized administrative accounts and, ultimately, Babuk-derived ransomware deployed directly on ESXi hosts across at least 361 systems in 47 countries. Germany, the United States, Turkey, Iran and France were the most affected.
That is the point where the three accounts genuinely diverge, and it is worth naming plainly. Infosecurity and Dark Reading both described what looked like a single event: broad, opportunistic scanning consistent with any financially motivated actor running mass exploitation against a fresh critical CVE. The Hacker News’s later reporting does not contradict that account, it describes a second, narrower operation layered on top of it: a threat actor patient enough to build persistence and move laterally to hypervisor-level ransomware rather than cash out on initial access alone. Read only the first week’s coverage, and the story is about patch velocity. Read all three together, and the story is about what opportunistic access gets used for once someone decides to keep it.
Why the Hypervisor Layer Is the Prize
The choice of target explains why an actor patient enough to build persistence would bother. ESXi hosts sit below the layer most enterprise endpoint detection and response tooling watches. A workstation or server running an EDR agent reports on its own compromise; the hypervisor hosting dozens of those same workstations and servers as virtual machines typically does not run any comparable agent at all. Encrypting a datastore at the hypervisor level takes down every virtual machine it hosts in one operation, which is precisely why ransomware operators have increasingly targeted ESXi directly rather than encrypting guest operating systems one at a time. A ransomware crew that reaches vCenter administrative access, as the actor QUIRSO tracked reportedly did, is not looking for a single server. It is looking for the console that controls all of them.
That also explains the choice of a Babuk-derived payload rather than a bespoke tool. Babuk’s source code has circulated publicly since 2021, and Linux and ESXi-targeting variants built on it require comparatively little original development work, an advantage for an actor whose primary investment went into the intrusion and persistence phase, not into building custom ransomware tooling from scratch.
What a Week of Coverage Adds Up To
The through-line the three accounts do not individually draw out is this: the exploitation of CVE-2026-59310 was never one campaign. It was at least two, running on different clocks. The first, the one Infosecurity and Dark Reading caught, was fast, loud and broad, the kind of mass scanning that shows up in honeypot telemetry within days and gets its own headline. The second, the one QUIRSO’s research and The Hacker News surfaced nearly three weeks after the patch, was slow, quiet and narrow, consistent with an actor that let the noisy opportunists provide cover while it built durable access.
That two-stage pattern is not unique to vCenter. CyberTech’s own coverage this month of a maximum-severity SAP Commerce Cloud flaw exploited within three days of its patch shows the same opening act: rapid, opportunistic exploitation of a critical, unauthenticated vulnerability the moment a patch (and the reverse-engineering trail it leaves) becomes public. What the vCenter case adds is the second act that most fast-moving stories never get the chance to show, because most security teams have moved on to the next advisory by the time it happens.
What It Means for the Security Leader
The practical risk here is not “patch vCenter.” Most organizations running vCenter or vSphere Foundation have likely already applied Broadcom’s July 29 fixes, or are in the process of it. The risk is treating a completed patch as the end of the incident timeline rather than the start of a compromise assessment. Any internet-facing or loosely segmented vCenter Server Appliance that was reachable and unpatched between July 29 and roughly mid-August should be checked for the specific indicators QUIRSO’s research surfaced, not just for patch status:
- Unexpected files in
/etc/cron.dnamed to resemble syslog output (the reported backdoor used a “-syslog.log” suffix designed to blend in with vCSA’s legitimate remote syslog naming convention) - Web shells or scripts named to mimic performance-monitoring utilities, such as
vmware-perf-update.jsp - Administrative accounts created outside normal change control
- Outbound WebSocket connections from vCenter or ESXi hosts that were not present in a known-good baseline
Security leaders should also separate the two response tracks the coverage collapses into one: patch management closes the vulnerability, but it does nothing to evict an actor who established access before the patch landed. Treat “we patched in time” and “we confirmed no persistence” as two different, both mandatory, checkboxes for any critical infrastructure flaw with a documented exploitation window measured in days rather than weeks.
There is also a governance lesson in how long the second act took to surface. Nearly three weeks passed between Broadcom’s patch and the public reporting of ransomware deployment on compromised ESXi hosts, well outside the window most incident response retrospectives and post-mortems are scoped to cover. Security teams that closed the CVE-2026-59310 ticket the week Broadcom’s patch shipped, and moved on, would have had no reason to revisit it by the time this second wave became public. Any vulnerability management program that treats “patched” as equivalent to “closed” for a critical, unauthenticated, internet-reachable flaw is building in exactly that blind spot. The fix is procedural as much as technical: hold a compromise-assessment review open for weeks, not days, after patching anything that scores a 9.8 and had a documented pre-patch exploitation window, and revisit it explicitly rather than assuming silence means the incident never happened.
Source: Broadcom Security Advisory
