Patched July 29, compromised by August 5

Broadcom shipped the fix on July 29, 2026. The first compromised systems called home to the attacker on August 3. By August 5, about 95% of the eventual victims were already there [1].

That is the story in three dates. Nobody here was hit by a zero-day. Every one of the 361 victim IP addresses that incident response firm QUIRSO identified belonged to a system with a patch available and five days to apply it.

Five days to patch a hypervisor management plane. If your first reaction is that nobody moves that fast on vCenter, you are right, and that is the finding rather than the excuse.

The flaw is CVE-2026-59310, a directory traversal in the vCenter syslog server that a network-reachable attacker can turn into arbitrary code execution [3]. Broadcom rated it 9.8 and published no workaround [2].

What happened

Broadcom’s advisory, VMSA-2026-0006.1, fixed five issues across ESX, vCenter, Workstation and Fusion. Two of them were vCenter flaws rated 9.8: CVE-2026-59309, an authentication bypass in the VMware Directory Service, and CVE-2026-59310, the syslog server directory traversal. Both were privately reported, and neither carried a workaround [2].

QUIRSO found the campaign through an incident response engagement on a compromised vCenter Server Appliance, then mapped it outward. Their count is 361 unique victim IP addresses across 47 countries, spanning technology firms, universities, research organisations and telecoms providers. Germany led with 55, followed by the United States with 41, Turkey with 38, Iran with 26 and France with 25, so five countries accounted for slightly more than half. No victims were identified in mainland China [1].

The speed is the part worth sitting with. First observed victims on August 3, five calendar days after the advisory. Another 151 victim IPs appeared on August 4. By August 5, 343 of the eventual 361 had already been seen [1].

QUIRSO is careful about what those numbers mean, and so am I. Some addresses belong to hosting providers, cloud environments or shared infrastructure, so the IP count is not an organisation count [1].

On August 13, 2026, the Shadowserver Foundation issued a special victim notification report built on QUIRSO’s data, sending it to affected network owners and national CERTs. Their framing was blunt: the reverse_ssh persistence mechanism was deployed on all victims reported, and those systems should be considered fully compromised [4].

Read the sources against each other, though, and the corroboration is thinner than it first looks. Shadowserver’s report is built on QUIRSO’s data rather than on an independent scan, so the 361 figure has one origin rather than two. Nothing else cited here reaches a victim count separately, and no public file hashes have been published that would let a defender pivot on their own telemetry and check the scope for themselves. None of that makes the reporting wrong, and the intrusion detail is specific enough to act on. It does mean the numbers rest on a single team’s visibility, so treat the 361 as a floor that happened to be measured, not as the size of the campaign.

Why this matters

vCenter is not a server, it is the thing that owns your servers. Compromise a web application and you have a web application. Compromise the vSphere management plane and you have every virtual machine it manages, plus the ability to power them off. The blast radius is the entire estate, which is exactly what played out here.

Five days is the patch window now. Hypervisor management is one of the slowest things in most change calendars, because patching it means a maintenance window and a nervous conversation about downtime. That caution is reasonable in isolation and it is now a liability. The assets we patch slowest are the assets with the largest blast radius, and attackers have noticed.

There was also no privilege escalation step. The initial access already ran as root, because the vulnerable service runs as root [1]. Plenty of defensive thinking assumes a gap between an attacker getting code running and an attacker owning the box, and that gap is where detection normally happens. Here there was none.

One more thing, and it is the detail I would put in front of a security manager. CISA added this CVE to the Known Exploited Vulnerabilities catalog on August 18, 2026, with a remediation deadline of August 21 [6]. That is twenty days after Broadcom shipped the patch, fifteen days after exploitation began, and thirteen days after the campaign had already reached about 95% of its eventual victims.

The listing is correct and it is useful. For this campaign it is also an epitaph. A programme that waits for KEV membership before it moves started work on day twenty of something that was finished by day seven. KEV records what has been confirmed; it was never built to be an early warning. Treat it as a floor, and keep a second trigger for critical, internet-facing, unauthenticated flaws in infrastructure you cannot afford to lose.

Technical breakdown

The intrusion QUIRSO documented runs from unauthenticated code execution to encrypted datastores in roughly 42 hours.

The entry point deserves a moment. A syslog server is a logging component, the least glamorous service on the appliance, and its path handling let content land somewhere the system would execute from. QUIRSO could find no authentication events or active sessions around the first malicious entries, and the commands ran as root, which is what led them to path traversal as the likeliest initial access vector [1]. The dropped filenames even carried the CVE number, which is how a defender reading crond errors could have caught it on day one.

From there the actor lived off standard tooling: cron jobs running on the minute, shell downloaders, native Linux utilities, and payloads staged across several different internet-accessible services rather than one server [1]. Little of it is exotic. All of it is quiet.

The credential step is the elegant part. Rather than cracking anything, the payload recovers the vCenter machine account credential from the appliance’s own configuration, with a fallback path for different vCenter versions, then uses it to authenticate to the local directory service and create an SSO administrator [1]. That is the hinge of the whole intrusion: it converts root on the appliance operating system into administrative control of the vSphere directory. One of the scripts carries a comment written in Chinese [1].

Then the tidying up. Binaries checked for virtualised environments and analysis tools. Files prefixed with a dot. Scheduled tasks named to resemble genuine VMware services. Jobs deleted once they had served their purpose. QUIRSO makes a point defenders should take with them: system logging still retained evidence of several commands after the files and tasks themselves were gone [1].

Impact came on August 4. Local admin accounts were created on each ESXi host purely to enable encryption, virtual machines were forcibly terminated, and the vSphere HA agent was removed to impair failover. Datastore volumes were encrypted with the .babyk extension, with large virtual disks only partially encrypted, the first 512 MB, which is enough to ruin them and fast enough to finish [1]. The ESXi logs were encrypted along with everything else, destroying the telemetry that would have explained what happened.

On attribution, QUIRSO is disciplined and I will match them. They assess with moderate confidence that the operator is a Chinese-speaking actor probably working in a UTC+8 environment, based on Chinese-language artifacts in scripts, apparent reuse of research from a Chinese security publication, Chinese-language tooling, victimology that excludes mainland China, and working-hour patterns [1]. They state they have insufficient evidence to associate the campaign with a named Chinese group or to conclude state direction, and track it as an uncategorised Chinese-nexus intrusion set [1]. The Babuk-derived ransomware is explicitly not evidence of identity: the builder leaked in 2021 and derivatives are used widely, possibly here to frustrate attribution [1]. Reporting has followed the same framing [5].

Separately, activity on August 1 involving CVE-2026-59309 created an administrative account on the same appliance, but QUIRSO could not link it to the main chain and groups it as possibly a different actor [1]. Two independent parties may have walked through two doors in the same advisory.

What defenders should do Monday morning

Immediate, within 24 hours. Answer one question first: is any vCenter or ESXi management interface reachable from the internet? Then patch vCenter to 9.1.0.0300, 9.0.2.0100, 8.0 U3k or 8.0 U2f [2]. If an exposed vCenter was unpatched at any point after July 29, 2026, patch it and then treat it as a suspected compromise, because the patch closes the door and evicts nobody.

Near term, this week. Hunt on the appliance. Review vSphere SSO Administrators and SystemConfiguration.Administrators membership and validate every account against a person. Look for systemd services and cron entries with VMware-sounding names that no change record explains, JSP files under the Perfcharts web application directories, unexpected sudoers drop-in files, and additions to root’s authorized_keys. Check outbound connections originating from vCenter, since reverse_ssh calls out rather than listening, which slips past controls watching only for unsolicited inbound traffic [1]. On ESXi, confirm execInstalledOnly is enabled. Then verify your backups are offline or immutable, and that a restore works when vCenter itself is unavailable.

Structural, this quarter. Get the management plane off the internet permanently, behind a VPN or jump host, and add it to whatever process would catch it being republished. Build the SSO administrator group alert and route it somewhere a human reads. Reclassify hypervisor and management-plane patching as an emergency change, separate from the general server calendar, because a five day window does not fit a monthly one. And register your netblocks with Shadowserver, which is free and is how a good number of these victims learned they were victims [4].

Checklist

• vCenter and ESXi management interfaces are not reachable from the internet
• vCenter patched to 9.1.0.0300, 9.0.2.0100, 8.0 U3k or 8.0 U2f
• Any exposed and unpatched vCenter treated as suspected compromise, not just patched
• vSphere SSO Administrators membership reviewed, every account tied to a person
• Alerting in place for changes to SSO administrator groups
• Appliance checked for unexplained systemd services and VMware-lookalike cron jobs
• Perfcharts web directories checked for JSP files
• Root authorized_keys and sudoers drop-ins reviewed
• Outbound connections from vCenter monitored, not just inbound
• ESXi execInstalledOnly enabled
• Backups offline or immutable, and a restore tested without vCenter
• Netblocks registered with Shadowserver for victim notification

The window, not the flaw

The vulnerability will be forgotten by October. The number worth remembering is five, as in the days between a fix existing and hundreds of organisations losing their virtual estate.

Most patch programmes are built around a rhythm: assess, schedule, test, deploy. For hypervisors that rhythm is measured in weeks, because the downtime is real and the risk of breaking production is real too. This campaign did not care. It found exposed systems, walked in as root, and was encrypting datastores before most change advisory boards had met.

So here is the position, and most patch policies do not encode it. We rank patching urgency by CVSS and by whether somebody else has already confirmed exploitation. We rank change risk by how much downtime the maintenance window costs. Both rankings push the hypervisor management plane toward the back of the queue, and blast radius never enters the arithmetic at all. The asset that owns every other asset ought to sit at the front of that queue. In most programmes it sits at the back, and this campaign is what that costs.

You cannot win the five day race every time. You can arrange to rarely run it, which is the real return on taking the management plane off the internet. It will not make you immune to the next 9.8. It buys you the time to install that one like a professional rather than a firefighter.