vCenter CVE-2026-59310 Active Exploitation

vCenter is not simply another server. Administrators use it to coordinate virtualization hosts, workloads, permissions, networks, storage, snapshots, migrations, and automation. A compromise can place many business systems and parts of the recovery plane within one investigation boundary.⁸

Broadcom disclosed the flaw on July 29 and updated the advisory on August 3. The vCenter Syslog server permits path traversal leading to arbitrary code execution for an attacker with network access. The CNA vector requires no privileges or user interaction, and Broadcom lists no workaround.^{1, 3, 9}

The material delta is later exploitation reporting. BleepingComputer says QUIRSO observed activity from August 3, counted 361 compromised IPs across 47 countries by August 7, and identified reverse_ssh deployment. Those claims are operationally important but are not yet public Broadcom or CISA confirmation.^{2, 5, 6}

VMware vCenter is the central control system for a virtualized environment. Administrators use it to manage ESXi hosts, virtual machines, permissions, networks, storage, snapshots, migrations, and automation from one place. That makes it unusually valuable to an attacker: compromising vCenter can expose far more than one server and can place production workloads, privileged administration, and parts of the recovery process inside the same investigation boundary.⁸

Broadcom published VMSA-2026-0006 on July 29, 2026 after Phil Brass and Matt South of Atredis Partners privately reported a directory-traversal flaw in the vCenter Syslog server. The advisory was a vulnerability disclosure with patches, not an announcement that Broadcom had discovered a customer breach. Broadcom assigned CVE-2026-59310 a 9.8 Critical score because an attacker who can reach the affected service needs no account and no user interaction to execute arbitrary code. Broadcom lists no workaround.^{1, 2, 3}

The phrase remote and unauthenticated does not mean every vCenter is automatically reachable from the public internet. It means the attacker needs a network path to the vulnerable vCenter service but does not need valid vCenter credentials. A publicly reachable system can therefore be an initial-access target. A vCenter restricted to a management network generally requires the attacker to first reach that network through a VPN, partner path, compromised workstation, jump host, monitoring platform, or another internal foothold. MFA on the normal vCenter login does not neutralize a pre-authentication service flaw.^{1, 3}

The story became more urgent after disclosure. QUIRSO reported that compromised systems began connecting to attacker-controlled infrastructure on August 3, five days after the advisory. It counted 151 new victim IP addresses on August 4, 343 by August 5, and 361 across 47 countries by August 7. QUIRSO said the operator deployed the open-source NHAS reverse_ssh framework after access. That is reported evidence of real exploitation and post-exploitation access—not merely a theoretical vulnerability—but the victim unit is an IP address, not a verified organization count.^{6, 11}

Important facts remain unavailable. QUIRSO withheld the campaign IP addresses, domains, and other specific infrastructure while coordinating with law enforcement. No reliable public source retained here identifies a victim organization, publishes a campaign-specific malware hash or filename, or proves data theft, encryption, outage, or a particular business impact. Broadcom had not publicly confirmed QUIRSO's campaign, CISA had not added CVE-2026-59310 to the Known Exploited Vulnerabilities catalog by the August 16 cutoff, and the public record did not support attribution to a named actor.^{5, 6, 11}

The reported reverse_ssh deployment matters because the client initiates an outbound SSH-based control channel. That can give an operator continuing remote access even when inbound administration is tightly restricted. The NHAS project is legitimate dual-use software, so its presence is not automatically malicious. QUIRSO's generic YARA rule detects standard NHAS reverse_ssh client builds by combining Go build metadata, stable source-package paths, and client-configuration strings; a match must be correlated with path, owner, execution time, parent process, network destination, and change authorization.^{11, 12, 13}

Every owner should identify all vCenter instances and exact builds, map every route that could reach them, and move supported systems to the current fixed release: 9.1.0.0300, 9.0.2.0100, 8.0 U3k, 8.0 U2f, or the product-specific VCF or Telco remediation path. Remove direct internet exposure, restrict management access to known administration paths, review outbound connectivity from the appliance, and preserve evidence before making changes that could rotate logs or destroy artifacts. A patch closes the known vulnerable path; it does not prove that earlier exploitation did not occur.^{1, 7, 14}

For systems that were vulnerable and reachable, treat remediation and compromise assessment as separate workstreams. Use the QUIRSO YARA rule as one lead, then review vCenter appliance files and services, outbound connections, vpxd and related logs, tasks and events, identities, roles, SSH keys, logging changes, and unexplained actions involving hosts, virtual machines, snapshots, clones, datastores, networks, or backups. Closure should document the vulnerable interval, reachability, retained telemetry, findings, fixed build, credential or key rotation, recovery decision, and unresolved evidence gaps. If appliance integrity cannot be established, rebuild through a supported recovery path rather than declaring the system clean from patch status alone.^{12, 14, 15, 16}