Infrastructure · 15 Aug 2026 · Rob Nidschelm

Patching vCenter Is Not Enough Once the Attacker Owns the Control Plane

A vCenter compromise changes the job from vulnerability management to incident response. The patch closes CVE-2026-59310. It cannot revoke an attacker’s shell, remove persistence or prove that the virtualisation control plane is trustworthy.

Broadcom disclosed CVE-2026-59310 on 29 July 2026 as a critical directory-traversal vulnerability in the VMware vCenter Syslog server. An attacker with network access can exploit it to execute arbitrary code. The CVSS 3.1 vector is the worst practical combination for an enterprise management appliance: network reachable, low complexity, no privileges and no user interaction.

Broadcom released fixes on the same day. Five days later, incident responders at QUIRSO began seeing compromised vCenter systems connect to attacker-controlled infrastructure.

That is the point where the story stops being only about patch speed. A vulnerable server needs an emergency update. A server that may already have executed attacker code needs an investigation.

The patch closes the door, not the session

Patching CVE-2026-59310 removes the vulnerable path. It does not terminate a command channel that the attacker established earlier. It does not remove a copied binary, restore an altered trust relationship or explain what the attacker did while vCenter was under their control.

This distinction is easy to lose during an emergency. Vulnerability management asks whether the affected version has been replaced. Incident response asks a harder set of questions:

• Did exploitation occur before the patch was applied?
• What ran on the vCenter appliance?
• Did the attacker establish persistence?
• Which outbound systems did vCenter contact?
• Were administrator roles, certificates, sessions or integration credentials changed?
• Can the organisation still trust the management plane and the evidence it reports?

A successful patch is necessary. It is not an attestation that the environment is clean.

What Broadcom has fixed

Broadcom’s current advisory, VMSA-2026-0006.1, lists these fixed vCenter releases:

• vCenter 9.1.x: 9.1.0.0300
• vCenter 9.0.x: 9.0.2.0100
• vCenter 8.0 Update 3: 8.0 U3k
• vCenter 8.0 Update 2: 8.0 U2f

The 8.0 U2f express patch was added when Broadcom updated the advisory on 3 August. Broadcom recommends Update 3k or newer because the Update 2 patch addresses the critical CVEs in this advisory but does not include the wider set of security and bug fixes.

VMware Cloud Foundation 5.x uses the asynchronous patching path to 8.0 U3k. Telco Cloud Platform and Telco Cloud Infrastructure users should follow the product-specific knowledge-base instructions linked from the response matrix.

There is no workaround. The patches are cumulative, and these vCenter updates are not eligible for vCenter Quick Patch. Broadcom says vSphere 7.0 is affected but is already out of general support. Customers with extended support must use those channels for patches. The vendor says organisations should presume that vSphere 6.5 and 6.7 are affected because products past general support are not evaluated in the advisory process.

The version question is therefore straightforward: supported systems need the appropriate fixed build now, while unsupported deployments need an urgent upgrade or an agreed support path. The compromise question remains separate.

Exploitation moved faster than the patch cycle

QUIRSO’s findings come from evidence collected during an incident-response engagement. The company reports that affected systems first connected to attacker infrastructure on 3 August, five calendar days after disclosure.

The observed campaign then expanded quickly:

• 151 new victim IP addresses first appeared on 4 August.
• By 5 August, 343 of the eventual 361 addresses had appeared.
• By 7 August, QUIRSO had identified 361 victim IP addresses across 47 countries.
• Germany, the United States, Turkey, Iran and France were the five most affected countries. Together they accounted for 185 of the 361 observed addresses.

Those figures need careful language. An IP address is not the same as an organisation, a physical server or a confirmed victim company. Hosting providers, cloud networks, shared infrastructure and network address translation can all distort the relationship. QUIRSO therefore reports victim IPs, not 361 breached organisations.

The timing is still important. Approximately 95% of the observed addresses appeared by 5 August. The campaign did not wait for every change window, asset owner or upgrade plan to align.

BlackTree has previously argued that the patch window has effectively disappeared. This campaign shows the next problem. Once exploitation has occurred, faster patching can prevent another entry, but it cannot erase the first one.

The reverse connection changes the investigation

After compromise, QUIRSO says the attacker deployed the open-source reverse_ssh framework for persistence and remote access.

The tool is legitimate and dual use. Its documented features include automatic connect-back, remote shells, SSH port forwarding, file transfer and multiple transports. In this campaign, the important behaviour is the direction of travel: the compromised vCenter system initiates an outbound connection to the operator.

That matters because many management networks are designed primarily to block unsolicited inbound access. An outbound command-and-control channel can pass through a very different set of firewall, proxy and monitoring decisions. Once connected, a reverse shell can give the operator remote access without exposing a conventional inbound management service.

QUIRSO has published a generic YARA rule for standard reverse_ssh client binaries. A match is an investigative lead, not proof of malicious activity. The rule detects a public tool that may also be present in authorised penetration-testing environments.

Defenders should therefore combine file detection with context:

• Search the vCenter appliance for reverse_ssh binaries and related execution evidence.
• Review running and historical processes, child shells and unexpected command interpreters.
• Examine systemd units, scheduled jobs, startup scripts, new SSH keys and other persistence locations for unauthorised changes.
• Review DNS, proxy, firewall, flow and packet metadata for unexpected outbound connections from vCenter.
• Look beyond the published campaign window. Start with 29 July, retain a buffer for possible earlier knowledge, and pay particular attention to 3 through 7 August.
• Correlate any YARA match with file provenance, timestamps, parent processes and network destinations.

Do not assume that removing one binary ends the incident. Arbitrary code execution gives an attacker the opportunity to add another access path, steal credentials or modify system configuration.

When vCenter is compromised, the control plane becomes evidence

vCenter is not just another server. It is the control plane for virtual machines, ESX hosts, permissions, networks, templates, snapshots and much of the operational history administrators use to explain what happened.

That concentration of authority changes the trust model after compromise.

An attacker with code execution on vCenter may be able to observe or manipulate the same records responders normally consult. vCenter task history and appliance logs remain valuable, but they should not be the only source of truth. Validate them against evidence collected outside the control plane:

• ESX host logs gathered directly from the hosts
• identity-provider and privileged-access records
• firewall, proxy, DNS and network-flow telemetry
• storage and backup platform logs
• configuration records exported before the incident
• independent inventories of hosts, virtual machines, networks and administrators

This is the same broader lesson seen when trusted security tooling became the supply-chain attack. Trust is not a permanent property of a component. It is a relationship that needs boundaries, external evidence and a way to be re-established after failure.

A vCenter compromise response checklist

The response should run in two tracks. Close the vulnerability quickly, and investigate whether the attacker crossed the threshold before it closed.

1. Preserve evidence first. Capture volatile process and network state where operationally safe. Export relevant logs to a trusted location. Preserve firewall, DNS, proxy and flow data before retention periods remove it.

   
   

2. Contain deliberately. Restrict vCenter ingress to authorised management sources and limit egress to required destinations. If active command-and-control is suspected, coordinate isolation with virtualisation, network and incident-response teams. Avoid destroying evidence through an unplanned power-off.

   
   

3. Apply the fixed version. Use the current Broadcom response matrix for the deployed branch. Confirm the installed build after the update. Patching remains urgent even when an investigation is already under way.

   
   

4. Hunt for known and unknown persistence. Use QUIRSO’s YARA rule, but also look for unexpected services, jobs, keys, binaries, scripts, accounts and configuration changes. A clean YARA result cannot exclude a modified build or a different persistence method.

   
   

5. Review outbound activity. Identify every unusual destination contacted by the appliance, not only known malicious indicators. Reverse tunnels are especially useful when defenders allow broad internet egress from management systems.

   
   

6. Audit control-plane changes. Review new or modified SSO users, groups, roles, permissions, certificates, trusted endpoints, plugins and integrations. Examine virtual-machine creation, deletion, snapshot, console, template, network and host-management activity.

   
   

7. Rotate exposed trust material. Invalidate active sessions and rotate credentials, tokens, certificates or service accounts that the compromised appliance could access. Prioritise highly privileged identities and integrations that can reach ESX hosts, backup systems, storage, identity services or automation platforms.

   
   

8. Validate hosts independently. Compare ESX hosts, virtual machines, networks and permissions against known-good records outside vCenter. Investigate discrepancies from the hosts and supporting platforms rather than relying only on the compromised manager.

   
   

9. Rebuild when trust cannot be demonstrated. If arbitrary code execution is confirmed, or if telemetry is too weak to establish what happened, rebuilding vCenter from a known-clean source may be safer than trying to prove that every attacker change has been found. Recovery should include re-establishing certificates, integrations and administrative trust, followed by close monitoring for renewed callbacks.

   
   

10. Reduce the next blast radius. Keep vCenter off the public internet, require access through a controlled management path, apply strict egress rules and forward logs to a system the appliance cannot rewrite.

    
    

What has changed since the first advisory

As of 15 August 2026, Broadcom’s public advisory has not changed since the 3 August addition of the vCenter 8.0 U2f express patch. The vendor FAQ still says Broadcom has no information suggesting in-the-wild exploitation. Broadcom has not publicly incorporated QUIRSO’s campaign findings into the advisory.

CISA has now confirmed active exploitation. The agency added CVE-2026-59310 to its Known Exploited Vulnerabilities catalogue on 18 August, with a 21 August remediation deadline for US federal civilian agencies. CISA classifies exploitation as active, the attack as automatable and the technical impact as total. That change removes the article’s earlier caveat that the vulnerability was absent from KEV.

Neither absence should be treated as evidence that exploitation did not occur. Vendor confirmation, government cataloguing and incident-response evidence are different signals with different validation processes and publication timelines. The defensive decision should be based on the strongest available evidence, not on the slowest status page.

What is confirmed, and what is not

Broadcom confirms the vulnerability, its critical severity, the arbitrary-code-execution path, the affected supported branches, the fixed versions and the absence of a workaround. QUIRSO confirms its observation of 361 victim IP addresses in 47 countries and the use of reverse_ssh in the incident evidence it analysed.

QUIRSO now assesses with moderate confidence that the campaign centred on CVE-2026-59310 was operated by a Chinese-speaking actor probably working in a UTC+8 environment. The company does not attribute the activity to a named group or the Chinese state, and it treats the possible CVE-2026-59309 access track as potentially separate.

The most defensible conclusion is operational: any vulnerable, network-accessible vCenter system during the exposure period needs urgent patching. Any system that was internet exposed, produced suspicious outbound traffic or shows campaign indicators needs incident response. Patching alone cannot prove that the environment is clean, because a fixed vulnerability says nothing about what executed before the fix.

Update, 21 August 2026: QUIRSO’s follow-up investigation now documents a possible parallel access track involving CVE-2026-59309 and creation of the vcenter_admin account. It also traces the likely CVE-2026-59310 campaign through vCenter and ESXi access to Babuk-derived ransomware. QUIRSO assesses with moderate confidence that the latter campaign was operated by a Chinese-speaking actor probably working in a UTC+8 environment. The company does not attribute it to a named group or the Chinese state, and it cautions that the earlier authentication-bypass activity may involve a different actor.

CISA has now confirmed active exploitation. The agency added CVE-2026-59310 to its Known Exploited Vulnerabilities catalogue on 18 August, with a 21 August remediation deadline for US federal civilian agencies. CISA classifies exploitation as active, the attack as automatable and the technical impact as total. That change removes the article’s earlier caveat that the vulnerability was absent from KEV.

The follow-up investigation shows two tracks and a destructive end state

QUIRSO’s follow-up separates two sets of activity on the investigated vCenter appliance. The distinction matters because a timeline can contain more than one intruder, and combining every action into one campaign can create false attribution and the wrong containment assumptions.

The first track began on 1 August and is consistent with possible exploitation of CVE-2026-59309, Broadcom’s critical authentication bypass in VMware Directory Service. After vCenter-targeted probing, the directory-service logs recorded creation of an administrative account named vcenter_admin and its addition to privileged groups. QUIRSO found no corresponding login event for the legitimate administrator identity shown as creating the account.

That is strong evidence for an unauthorised identity change, but QUIRSO does not claim a definitive link to the later campaign. The vcenter_admin account was used for discovery and was not observed elsewhere in the subsequent attack chain. The source address and unusual GoodMoodle-VCProbe/1.0 and GoodMoodle-VCFleet/1.0 user agents could not be connected to the later infrastructure or tools. QUIRSO therefore treats this as a separate activity track that may involve another actor.

The second track began on 3 August and most likely used CVE-2026-59310 for unauthenticated root-level code execution through the vCenter Syslog server. Cron files carrying names such as zz-poc59310-syslog.log staged a backdoor and further tooling. The actor established reverse SSH persistence, performed discovery, accessed vSphere credentials and moved from the appliance into the ESXi estate.

The impact phase shows why control-plane compromise cannot be closed as a normal appliance patch. Local adminuser accounts were created on ESXi hosts shortly before encryption. A ransomware binary named backup and a helper script named run.sh were placed on a shared datastore. The script stopped running virtual machines, prepared the hosts to execute the payload and launched encryption against mounted VMFS volumes. Encrypted files received the .babyk extension associated with Babuk-derived ransomware. QUIRSO also found that ESXi logs were encrypted, removing telemetry that could have explained more of the hypervisor activity.

Babuk lineage is not reliable attribution. The builder has been publicly available since its 2021 leak and Babuk-derived ESXi ransomware is used by multiple actors. QUIRSO says the payload may have been selected opportunistically or even used to make attribution harder.

The company’s attribution assessment applies to the campaign centred on CVE-2026-59310. QUIRSO assesses with moderate confidence that it was operated by a Chinese-speaking threat actor probably working in a UTC+8 environment. The assessment combines Chinese-language artefacts, apparent reuse of Chinese security research, repeated use of Chinese-language tools and management software, victimology that excluded mainland China, and activity patterns compatible with UTC+8 working hours.

That does not establish a named Chinese threat group or state direction. The most defensible label is QUIRSO’s own: an uncategorised Chinese-nexus intrusion set.

Responders should add the new evidence to the original hunt:

• review VMware Directory Service events for creation or privilege changes involving vcenter_admin and other unexpected SSO identities;
• search web and API logs for the two GoodMoodle user agents and unexplained discovery requests;
• inspect cron locations and process history for filenames containing poc59310, unexpected downloaders and root-level shell execution;
• audit vSphere SSO and every connected ESXi host for newly created adminuser or other local administrators;
• look for the backup ransomware binary, run.sh, the .babyk extension, forced virtual-machine shutdowns and changes to ESXi execution settings; and
• treat missing or encrypted ESXi logs as an incident finding, not as evidence that no activity occurred.

The follow-up turns the control-plane argument into an observed attack chain. The attacker did not stop at persistence on vCenter. The compromised manager became the route into the hypervisors and the mechanism for maximising operational damage.

Sources and further reading

• Broadcom: VMSA-2026-0006.1 security advisory
• Broadcom and VMware: VMSA-2026-0006 questions and answers
• QUIRSO: Active exploitation of CVE-2026-59310
• QUIRSO: Generic YARA rule for reverse_ssh clients
• NHAS: reverse_ssh project documentation
• CISA: Known Exploited Vulnerabilities Catalog
• BleepingComputer: Critical VMware vCenter flaw exploited for reverse SSH access
• QUIRSO: China-nexus assessment, parallel CVE-2026-59309 activity and Babuk-derived ransomware
• Canadian Centre for Cyber Security: CISA KEV update for CVE-2026-59310