Skip to content
HACKTECH
Exploited vulnerabilitiesReported Published 7 sources

VMware vCenter flaw CVE-2026-59310 exploited days after Broadcom's emergency patch

On 29 July 2026 Broadcom disclosed CVE-2026-59310, a CVSS 9.8 directory traversal flaw in the vCenter Syslog server that lets an unauthenticated attacker with network access to vCenter execute arbitrary code. It was one of five VMware vulnerabilities in the advisory, and BleepingComputer reported at the time that there was no indication of exploitation. Incident response firm QUIRSO reported that compromised systems began connecting to attacker infrastructure on 3 August and counted 361 victim IP addresses across 47 countries by 7 August, with the open-source reverse_ssh framework deployed for persistence. CISA added the flaw to its KEV catalogue on 18 August with a three-day deadline and later flagged it as used in ransomware campaigns.

  • VMware
  • vCenter
  • ESXi
  • hypervisors
  • reverse SSH
  • ransomware
  • CISA KEV

What the sources report

  • Broadcom's VMSA-2026-0006 advisory of 29 July covered five flaws in vCenter, ESX, Workstation and Fusion, including CVE-2026-59309, a CVSS 9.8 authentication bypass in the vCenter VMware Directory Service, and CVE-2026-47876, a CVSS 9.3 VMXNET3 out-of-bounds write that allows a virtual machine escape. Broadcom listed no workarounds, and its FAQ said the issues qualified as an emergency change (BleepingComputer).
  • The fixed vCenter releases are 9.1.0.0300, 9.0.2.0100, 8.0 U3k and 8.0 U2f, depending on the branch. Broadcom added the 8.0 U2f express patches on 3 August (Broadcom advisory).
  • QUIRSO counted 151 new victim IPs on 4 August, 343 by 5 August and 361 by 7 August. BleepingComputer reported that more than half were in Germany, the US, Turkey, Iran and France. QUIRSO cautioned that the number of victim organisations cannot be inferred from the IP addresses (SecurityWeek).
  • The attackers used reverse_ssh to keep an outbound control channel open, which gets around controls that block inbound connections. QUIRSO released a generic YARA rule for the tool and noted that legitimate use, such as penetration testing, also triggers it (BleepingComputer, SecurityWeek).
  • CISA's KEV entry was added on 18 August with a 21 August due date, requires forensic triage and lists ransomware use as 'Known'. In September Shadowserver tracked over 450 vCenter servers exposed online (BleepingComputer).
  • SecurityWeek reported that QUIRSO later attributed the activity to a China-linked threat actor and warned that CVE-2026-59309 had also been exploited. On 28 October CISA added CVE-2026-41709, a CVSS 2.7 ESX insufficient logging flaw from the same advisory, and CrowdStrike reported the same day that the China-nexus group Warp Panda had used it as a zero-day to reduce audit trail visibility.

What it means for your organisation

vCenter controls an organisation's virtual machines, so a pre-authentication flaw on a reachable vCenter puts the whole virtual estate at risk, and CISA's ransomware flag shows it is also an extortion target. Exploitation began five days after Broadcom's patch, which leaves little time for change processes that treat virtualisation management as routine maintenance. CrowdStrike says Warp Panda used the ESX logging flaw to reduce audit trail visibility, so hypervisor logs need forwarding off the host before an investigation depends on them.

What we check

  • Compare vCenter and ESX builds with Broadcom's fixed releases, and confirm the vCenter management and syslog services cannot be reached from the internet or from user networks.
  • Look for reverse_ssh binaries, unexpected new files and persistence on vCenter appliances, and outbound connections from vCenter to the internet. Check any YARA hits against authorised tooling.
  • Review vCenter SSO and local accounts, recent role changes, and any unregistered or unexpected virtual machines and snapshots.
  • Confirm that ESX and vCenter logs are forwarded off the host and correlated with network flow data.
  • Test segmentation between the virtualisation management plane, backup infrastructure and general corporate networks.

Sources

Services that cover these checks

  • Network & infrastructure testing

    Internal and external network testing, including Active Directory. Where scope allows we go from an unauthenticated foothold to domain-wide impact and document the whole chain: the exposed service or sprayed credential that got us in, each privilege escalation on the way, and the accounts and hosts it reached.

    Duration: 5 to 12 working days

  • Cloud configuration review

    An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • Red team & purple team

    Objective-based adversary simulation: we agree the objectives, try to reach them over several weeks and measure what your detection and response do along the way. Purple mode runs the same scenarios with your defenders in the room, tuning detection as each technique is replayed.

    Duration: 3 to 6 weeks

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works