Broadcom Disclosed a 9.8 in vCenter on July 29. Exploitation Started Five Days Later, and 95% of the 361 Victims Were Hit Inside 48 Hours.
- Patrick Duggan
- 2 minutes ago
- 4 min read
The interesting number in this campaign is not 9.8. It is five days, and then forty-eight hours.
The bug
[CVE-2026-59310](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-59310) is a directory traversal in the VMware vCenter Syslog server that lets an unauthenticated attacker with network access execute arbitrary code. CVSS 9.8. Broadcom disclosed it on July 29, 2026.
Note where it lives. Not in the vSphere Client, not in an authentication path — in the syslog receiver. The component whose entire job is to accept data from other machines without being precious about it. Logging infrastructure is routinely exempted from the scrutiny applied to front doors, because it is thought of as write-only plumbing that nobody reaches from outside. This is what happens when that assumption is wrong on a box that controls the hypervisor.
The clock
July 29 — disclosure
August 3 — first compromised systems begin connecting to attacker infrastructure. Five days.
August 4 — 151 additional victim IPs appear
August 5 — 343 of the 361 observed addresses, roughly 95%, have been seen
361 IP addresses across 47 countries. More than half concentrated in Germany, the United States, Turkey, Iran and France.
That shape is worth staring at. Five days from public disclosure to first exploitation is the reconnaissance-and-tooling window. Then the curve goes nearly vertical: essentially the entire observed victim population inside about forty-eight hours of the first hit.
This is not a campaign that grew. It is a sweep — a target list assembled in advance from internet-wide scanning and then worked through as fast as connections allow. The attacker knew who was vulnerable before they had a working exploit, which is the ordinary condition of the internet now and still surprises people.
We track this as weaponization latency: the distance between a CVE existing and it being used against real hosts. Five days is comfortably inside the window in which most enterprises are still scheduling the change ticket.
What they leave behind
After gaining access the operator deploys reverse_ssh — an open-source SSH-based reverse-shell framework offering outbound connect-back channels, port forwarding, file transfer, multiple transports and remote shell management.
Three things follow from that choice.
It is outbound. Your perimeter rules about inbound SSH are irrelevant; the vCenter host dials out. If your egress policy from the management network is permissive — and in most estates it is, because management hosts need to reach vendor update services — this establishes cleanly.
It is off-the-shelf and public. No custom implant to signature, no unique artefact to hunt. It looks like a legitimate administration tool because it substantially is one, which pushes detection off the file and onto the behaviour.
It is persistence, not payload. Nothing about this campaign so far indicates ransomware or destruction. Somebody is establishing durable access to hypervisor management planes in 47 countries and has not yet said what it is for. That is either intelligence collection or inventory for later, and neither is comforting.
Why vCenter specifically is the wrong thing to lose
A vCenter compromise is not a server compromise. vCenter is the control plane for every virtual machine beneath it — the place from which guests can be cloned, snapshotted, mounted, migrated or powered off, and where credentials for the whole estate frequently rest.
An attacker with vCenter does not need to compromise your domain controller. They can copy it.
Ransomware crews worked this out years ago, which is why hypervisor-layer encryption became standard practice. The 361 hosts in this campaign have not been encrypted. They have been made reachable, quietly, from outside.
What to do
Patch [CVE-2026-59310](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-59310) now if you have not. It is nearly two weeks past disclosure and more than a week into a confirmed active sweep — the assumption should be that any exposed instance was found.
Hunt outbound before you hunt inbound. The indicator here is your vCenter appliance initiating SSH-shaped connections to hosts it has no business talking to. Check egress logs from the management network for the window since August 3, not just today.
Restrict what the syslog receiver can hear. If the vCenter syslog port is reachable from anything other than the specific hosts that ship it logs, that is the actual finding, and it is true regardless of this CVE.
Assume the pre-existing scan. The five-day gap between disclosure and exploitation was not spent finding you. It was spent building the exploit. You were already on the list.
Ninety-five percent, as always. We hold no first-party indicators on this campaign — the timeline and victim counts are the published research, and if our own telemetry surfaces overlap with those 361 addresses we will publish it with timestamps either way.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=broadcom-disclosed-a-9-8-in-vcenter-on-july-29-exploitation-started-five-days-later-and-95-of-the
Comments