VMware vCenter: five days from advisory to root, no workaround

Broadcom disclosed two critical VMware vCenter vulnerabilities on 29 July 2026 and stated, for both, that no workaround existed. Five days later an attacker was executing code as root on internet-facing vCenter appliances. By 5 August the incident response firm QUIRSO had observed 343 compromised addresses, on the way to 361 across 47 countries.

The important detail is not that the appliances were unpatched. It is that the flaw required no credential, so every control those organizations had positioned behind the login was waiting for an event that never occurred.

What actually happened

CVE-2026-59310 is a directory traversal vulnerability in the vCenter syslog server, rated CVSSv3 9.8 with the vector AV:N/AC:L/PR:N/UI:N: no privileges, no user interaction, network reachable. QUIRSO's reconstruction shows the traversal placing attacker-controlled content into /etc/cron.d, outside the directory the service writes to. Cron executed it as root. There was no privilege escalation stage, because there was nothing to escalate from.

Root access bought layered persistence, an outbound reverse_ssh channel to attacker infrastructure, and a single sign-on account named adminuser created using machine credentials recovered from the appliance. In the environment QUIRSO investigated it ended with encrypted files on the ESXi hosts carrying a .babyk extension, which is associated with Babuk-derived ransomware. Shadowserver has since distributed QUIRSO's victim data as a special report to the network owners concerned, recording reverse_ssh as present on every system in that set. More than half of the addresses sit in five countries: Germany, the United States, Turkey, Iran and France.

The gap: authentication was never reached

QUIRSO found no matching authentication events around the time the first malicious cron entries appeared. That observation contains the whole problem. These were not weak controls; they were good controls sitting where their design assumes.

• Single sign-on and MFA evaluate an identity once one is presented. A syslog listener is not a login surface, so nothing was ever presented.
• Monitoring worked well. QUIRSO rebuilt the intrusion from logs that survived the actor deleting the scripts that produced them. Detection describes what happened; it does not change whether it happened.
• Patching was the correct answer, and the only one Broadcom offered. It also carries a maintenance window, because vCenter is the control plane for the virtual estate.

What would have had to be true

This blog has covered vendors whose emergency guidance was to restrict a component to trusted networks. This is the other case. Broadcom offered no mitigation because there was none to offer, which leaves reachability standing alone.

Restricting a management plane to known source networks is not an exotic control. It is the first line of every hardening guide these appliances ship with. So why was any vCenter answering the internet on 3 August?

Because the list decays from the moment it is written. An administrator works from home, a contractor arrives, an on-call engineer connects from a hotel, a broadband provider reassigns an address overnight. The failure mode is asymmetric: an address left in too long is silent, while an address missing is an outage at three in the morning on the system that runs every virtual machine the company owns. So the range gets widened until it is no longer a control, or dropped as too much trouble.

The capability was never missing. What was missing is a current answer to which networks the administrators are working from, and vCenter is the case where that answer should have been shortest.

A staff portal has to answer everybody who works at the company, which is what makes restricting one genuinely hard. A management plane has to answer a handful of administrators. This was the easy case.

Where Veribound would have fitted

Agents attest that devices are still the ones the organization trusted, and the scoring engine turns those attestations into per-device decisions. What reaches the edge is a trusted origin: the network that device is connecting from, in practice its public address, while the device behind it is still trusted. Those origins are written into the address groups the organization's own firewall policy already references, and the customer's own equipment keeps enforcing its own rules, unchanged.

Applied here:

• The scan returns nothing, so the appliance never reaches a target list.
• The crafted request does not arrive, because the syslog service is never asked to parse a path it mishandles.
• The list maintains itself, which is the part that was failing, and it changes when an administrator changes network.

None of this is a workaround for CVE-2026-59310. Broadcom said no workaround exists and that remains accurate: the vulnerability is unchanged, and what changes is who is in a position to reach it.

The other limits are worth stating plainly. It would not have changed the outcome for an organization whose vCenter was reached from inside, by an attacker already holding a workstation or a VPN account, because internal network access satisfies Broadcom's precondition as well as external access does. It would not have interrupted the outbound command and control channel, which is an egress question rather than an origin question. And it would have done nothing about persistence or ransomware established after root, both of which followed from the appliance itself.

The claim is narrower than the incident, and it is the narrow claim that holds: on 3 August, the difference between an affected appliance and an unaffected one was whether it answered a stranger.

Source: Global Exploitation of CVE-2026-59310 by Suspected Chinese-Nexus APT & Related CVE-2026-59309 Activity, QUIRSO GmbH, 15 August 2026.