CVE-2026-59310

Sources: ^{[1][2][3][4][5][6][7][8][9][10]}

Sources: ^{[1][3][5][6][7]}

What vCenter is: VMware vCenter is the control plane administrators use to manage ESXi hosts and virtual machines across an environment. It can coordinate permissions, clusters, networking, storage, templates, snapshots, migrations, and automation. Compromising it can give an attacker a powerful position from which to observe or alter many systems, rather than only one server. ^[8]

What happened: Broadcom disclosed CVE-2026-59310 on 29 July 2026 and updated its advisory on 3 August. The flaw lets an unauthenticated attacker who can reach the vCenter Syslog service traverse paths and execute arbitrary code. Broadcom released fixes and says there is no workaround. ^[1][3]

Why this watch exists: Broadcom initially had no public exploitation evidence, but BleepingComputer later reported QUIRSO telemetry describing exploitation, compromised systems, and reverse_ssh deployment. That delta changes the operational question from “patch a critical flaw” to “patch and determine whether access already occurred.” ^[2][6]

• CVE-2026-59310 is a 9.8 Critical, unauthenticated path-traversal flaw in the vCenter Syslog server that can lead to arbitrary code execution when an attacker has network reachability. ^[1][3][9]
• It can be an internet initial-access path when vCenter is exposed. If vCenter is confined to a trusted management network, the actor first needs a foothold that can reach it. MFA on the normal login does not neutralize a pre-authentication service flaw.
• Later reporting attributes observed exploitation to QUIRSO: activity beginning 3 August, 361 compromised IPs in 47 countries by 7 August, and deployment of reverse_ssh for outbound persistent access. Treat those as credible but source-bounded claims, not Broadcom or CISA confirmation. ^[6]
• CISA had not added the CVE to KEV as of 16 August, and no reliable public source names victim organizations or the operator. ^[5][6]
• Patch to a vendor-fixed build immediately, restrict vCenter to dedicated administration paths, then hunt the vulnerable window. A patch closes the flaw; it does not evict an attacker who already established remote access. ^[1][7]

VMware vCenter is the management hub for virtual infrastructure. It helps administrators control ESXi hosts, virtual machines, permissions, networks, storage, snapshots, migrations, and automation from one place. That concentration is useful operationally, but it also makes vCenter a high-value target: control of the management plane can threaten many workloads and the recovery systems around them. ^[8]

Broadcom disclosed CVE-2026-59310 on 29 July 2026 because the vCenter Syslog server did not properly confine file paths. An attacker who can send traffic to the vulnerable service does not need a vCenter account or user interaction and may execute arbitrary code. This is why “network access” is the key qualifier. Publicly reachable vCenter can be used for initial access; a properly isolated instance is still vulnerable, but the attacker must first reach the management network. ^[1][3][9]

The risk changed after disclosure. Broadcom's initial FAQ said it had no evidence of exploitation, while later BleepingComputer reporting says QUIRSO observed exploitation beginning 3 August, counted 361 compromised IP addresses across 47 countries by 7 August, and saw attackers deploy reverse_ssh to create outbound persistent control. Broadcom has not publicly validated that campaign, CISA has not placed the CVE in KEV, and no named victim organization or attributed actor is public. Those limitations should remain visible, but they do not make the observed compromise telemetry theoretical. ^[2][5][6]

The response is two-part. First, upgrade to the fixed release for the affected branch—9.1.0.0300, 9.0.2.0100, 8.0 U3k or 8.0 U2f, or the vendor's VCF/Telco path—and restrict reachability. Second, investigate the full vulnerable interval for unexpected outbound SSH, unfamiliar binaries or services, new identities or permissions, altered logging, and unexplained vCenter, VM, host, snapshot, datastore, or network changes. If evidence cannot establish integrity, rebuild the appliance and rotate reachable administrative trust. ^[1][6][7]

• vCenter commonly holds broad administrative trust over multiple hypervisor hosts and virtual workloads.
• An outbound reverse channel can cross a firewall policy that blocks unsolicited inbound traffic and can survive after the original exploit path is patched.
• A compromised management plane can affect availability, confidentiality, recovery, and forensic confidence at the same time.
• MSPs and shared infrastructure operators may have a multi-customer blast radius, while smaller organizations may lack the logging needed for a definitive retrospective answer.

Sources: ^[6][8]

Unsupported or unlisted releases should not be assumed safe; obtain vendor guidance and plan migration. ^[1][3][7]

The VMware CNA score is CVSS 3.1 9.8 Critical: network vector, low complexity, no privileges, no user interaction, and high confidentiality, integrity, and availability impact. NVD had not supplied its own enrichment score at the cutoff. ^[3]

Operational priority should combine version with reachability and trust. Externally reachable pre-fix vCenter is an emergency. Internally restricted but vulnerable vCenter remains urgent because a compromised endpoint, VPN account, partner connection, or flat network could supply the required network position.

CWE-22 means software fails to keep a supplied path within an intended directory. In this case, Broadcom says the vCenter Syslog server can be abused to execute arbitrary code. CWE-22 describes the programming weakness; it is not a packet signature, exploit recipe, or proof of compromise. ^[1][3][9]

Sources: ^[2][5][6]

Sources: ^[1][3][6][8]

Sources: ^[6]

• Establish each vCenter's vulnerable interval, then collect network, DNS, proxy, firewall, Syslog, appliance, authentication, task, and configuration records for that period.
• Search for unexpected outbound SSH or tunnel-like connections originating from vCenter, especially destinations not present in the known-good baseline.
• Review new or modified binaries, services, scheduled activity, startup behavior, SSH keys, accounts, roles, and permissions on the appliance.
• Correlate unexplained vCenter operations with host, VM, snapshot, datastore, network, export, backup, and identity events.
• Treat clean results as confidence bounded by retention and sensor coverage. Missing logs are uncertainty, not proof of no compromise.

These are behavior-led hunt hypotheses derived from the confirmed capability and reported post-exploitation method; Broadcom has not published an issue-specific IOC package. ^[1][6]

• Today: identify every vCenter and prove whether it was internet-, VPN-, partner-, MSP-, or internally reachable while vulnerable.
• Today: patch the correct product branch; there is no vendor workaround.
• Today: preserve evidence before cleanup and hunt the full vulnerable interval for reported reverse-access behavior.
• Within 24 hours: verify vCenter accounts, roles, tasks, hosts, VMs, snapshots, datastores, networks, logs, backups, and integrations.
• If compromise cannot be ruled out: isolate, rotate reachable trust, rebuild from known-good media, and assess downstream workload and recovery integrity.

Sources: ^[6]

This is a public-source decision aid, not proof that a particular environment was targeted or compromised. Local investigation, vendor support, legal advice, and contractual obligations control organization-specific actions.