2026-07-30 · view entry permalink →
VMSA-2026-0006, VMware vCenter: unauthenticated Directory Service auth bypass and Syslog traversal RCE (both CVSS 9.8), plus a VMXNET3 guest-to-host escape
Broadcom published VMSA-2026-0006 on 2026-07-29, covering five vulnerabilities across VMware ESX, vCenter, Workstation and Fusion, and stating that they "were privately reported to Broadcom" with updates available to remediate them (Broadcom, 2026-07-29). Three national CERTs picked it up immediately: NCSC-CH on 2026-07-29 (NCSC Switzerland, 2026-07-29), NCSC-NL on 2026-07-29 (NCSC-NL, 2026-07-29), and BSI CERT-Bund, whose advisory is dated 2026-07-28 with a 2026-07-29 revision (BSI CERT-Bund, 2026-07-29).
Two of the five sit on vCenter and need no credentials. CVE-2026-59309 (CVSS 9.8) is an authentication bypass in the VMware Directory Service, and Broadcom's own attack-vector text is unambiguous about the prerequisite: "a malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system" (Broadcom, 2026-07-29). CVE-2026-59310, also CVSS 9.8, is a directory-traversal flaw in vCenter's Syslog server that reaches arbitrary code execution through manipulated file and directory paths (Broadcom, 2026-07-29). vCenter is the control plane for an entire virtual estate: an unauthenticated path into it is a path to every workload it manages, which is why an anonymous network-reachable bypass warrants out-of-cycle handling even with no exploitation reported.
The third flaw crosses the isolation boundary in the other direction. CVE-2026-47876 (CVSS 9.3) is an out-of-bounds write in the VMXNET3 virtual network adapter, and Broadcom scopes it precisely: "a malicious actor with local administrative privileges on a virtual machine with VMXNET3 virtual network adapter may exploit this issue to execute code on the host. Non VMXNET3 virtual adapters are not affected by this issue" (Broadcom, 2026-07-29). That precondition is the useful part of the triage: exposure is determined by adapter configuration rather than by ESX version alone, so the inventory question is which guests run VMXNET3 and how much you trust whoever administers them.
Two lower-severity issues complete the advisory. CVE-2026-41703 is an out-of-bounds read that Broadcom scores differently by product, 7.6 on ESX, where it says a denial of service of the host process is the more likely outcome than information disclosure, against 2.7 on Workstation and Fusion, where it restricts the impact to information disclosure (Broadcom, 2026-07-29). CVE-2026-41709 is insufficient logging on ESX that allows an administrator to act without the action being recorded (Broadcom, 2026-07-29), minor as a vulnerability, but worth noting for anyone who treats ESX audit logs as a complete record during an investigation.
Two product families beyond the obvious ones are in scope and are easy to miss on a first read of the advisory: Broadcom lists VMware Telco Cloud Platform and VMware Telco Cloud Infrastructure as impacted, with their own knowledge-base fix path rather than the vCenter and ESXi build numbers below (Broadcom, 2026-07-29). Any telco operator running those stacks needs to follow that path rather than assuming the vSphere builds cover them.
Fixed builds differ per flaw and per track. vCenter takes 9.1.0.0300, 9.0.2.0100 or 8.0 U3k, with Cloud Foundation 5.x served by an async patch to 8.0 U3k; the VMXNET3 escape is fixed in ESXi-9.1.0.0200, ESXi-9.0.2.0100 and ESXi80U3k (Broadcom, 2026-07-29). Broadcom records no workaround for any of the five, which removes the usual option of mitigating while the maintenance window is arranged.
Nothing here is reported exploited. Broadcom states the vulnerabilities "were privately reported to Broadcom" and credits Atredis Partners, Nguyen Hoang Thach of STARLabs SG working with Pwn2Own held by the Zero Day Initiative, an independent researcher, and CrowdStrike (Broadcom, 2026-07-29), and none of the three national CERTs reports in-the-wild activity. What earns this out-of-cycle attention is the reachability profile rather than an exploitation signal: two anonymous network paths into a virtualization control plane, with no interim control available.
Detection on the vCenter side means watching the two named services rather than the appliance generally: authentication events from the Directory Service, where a successful bind that no operator session accounts for is the signal, and Syslog-server request logging, where path-traversal sequences in a requested file or directory path have no legitimate counterpart. For the guest-to-host escape the telemetry is host-side, hypervisor crash and process-fault records on ESX hosts running VMXNET3 guests, since a failed escape attempt is far more likely to surface as an anomalous fault than as a clean compromise. On hardening, NCSC-NL is the source that spells out the architectural control: access to ESX and vCenter should be made available only from a separated management environment and not reachable directly from the internet or external networks (NCSC-NL, 2026-07-29). Broadcom's own advisory offers no hardening section and records "Workarounds: None" against every one of the five.
A malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system.
A malicious actor with local administrative privileges on a virtual machine with VMXNET3 virtual network adapter may exploit this issue to execute code on the host. Non VMXNET3 virtual adapters are not affected by this issue.
Multiple vulnerabilities in VMware ESX, vCenter, Workstation, and Fusion were privately reported to Broadcom. Updates are available to remediate these vulnerabilities in affected Broadcom products.
Compromised systems identified by QUIRSO were found to first establish contact with the attacker's domains on August 3, five days after Broadcom publicly disclosed the flaw.
followed by the deployment of a malicious cron job to establish persistence on the host using reverse_ssh
The presence of reverse_ssh should not, by itself, be treated as proof of malicious activity.
In combination with unauthorized installation, unexpected outbound connections or execution on a vulnerable vCenter appliance, however, it is a high-priority indicator requiring investigation.
Current exploitation status: Actively Exploited
The digital forensics company assessed a suspected advanced persistent threat (APT) actor was responsible, counting 361 victim IP addresses across 47 countries
The deployment [of Babuk-derived ransomware] may not have been the primary objective of the campaign
The entry on Broadcom's VMSA-2026-0006 recorded five vCenter, ESX, Workstation and Fusion flaws, noted that none was reported exploited and that all had been reported privately to Broadcom. One of them has now been confirmed in use against real estates.
QUIRSO, a German security firm, reports that an incident-response engagement gave it visibility into an exploitation campaign against internet-accessible vCenter systems using CVE-2026-59310, the CVSS 9.8 directory traversal in the vCenter Syslog server that reaches arbitrary code execution from network access alone (QUIRSO, 2026-08-10). The timeline is the part that should reset patch priorities: "Compromised systems identified by QUIRSO were found to first establish contact with the attacker's domains on August 3, five days after Broadcom publicly disclosed the flaw" (The Hacker News, 2026-08-12). QUIRSO records 361 unique victim IP addresses across 47 countries, with Germany, the United States, Turkey, Iran and France the most affected and 185 of the 361 addresses in those five countries; it is explicit that an address does not correspond to an organisation, since some belong to hosting providers and shared infrastructure. By 5 August, 343 of the 361 addresses had already appeared, the campaign reached roughly 95 per cent of its observed footprint within three days of starting (QUIRSO, 2026-08-10). QUIRSO assesses that while the attacker might have had prior knowledge of the flaw, the correlation with disclosure suggests the advisory itself was the campaign's starting point.
Switzerland's NCSC updated its own VMSA-2026-0006 advisory on 12 August, setting "Current exploitation status: Actively Exploited" and citing QUIRSO's report (NCSC-CH, 2026-08-12).
What the attacker does after landing. The chain reported is path-traversal activity consistent with the flaw, "followed by the deployment of a malicious cron job to establish persistence on the host using reverse_ssh" (The Hacker News, 2026-08-12), an open-source SSH-based reverse-shell framework whose legitimate penetration-testing features include automatic connect-back, port forwarding and file transfer. The choice is a deliberate one about direction of travel: the control channel is established outbound from the appliance, which sidesteps controls built to stop unsolicited inbound access (QUIRSO, 2026-08-10). QUIRSO says a follow-up publication examining the attacker's tradecraft, infrastructure and post-exploitation activity is planned, and that further detection content is being released in coordination with law-enforcement partners.
A second, separate signal sits alongside it and should not be merged with the first. The Hacker News reports Defused Cyber observing a spike in scanning against vCenter (version probes and walks of the single-sign-on flow) that it associates with CVE-2026-59309, the unauthenticated Directory Service authentication bypass from the same advisory. QUIRSO's co-founder Denis Szadkowski told the outlet there is not enough evidence to correlate that scanning with the intrusion set behind CVE-2026-59310, adding that "the forensic evidence strongly points toward CVE-2026-59310 as the initial access vector" for the compromises QUIRSO investigated (The Hacker News, 2026-08-12). Two flaws in one advisory are drawing attention independently; only one has confirmed compromises behind it.
Detection concepts, telemetry class first. The behaviours worth hunting are all unusual for a management appliance rather than unusual in general. In egress and flow records, an SSH-protocol session initiated from a vCenter appliance to an external destination inverts the normal direction of vCenter traffic, which is inbound administrative access and outbound management of hosts. In configuration and scheduling state on the appliance, cron or scheduled entries that no platform-engineering change record accounts for are the persistence artefact reported here. In process telemetry, execution lineage descending from the Syslog service is the exploitation artefact. QUIRSO's own framing of the tool is the right calibration and applies to any dual-use binary: "The presence of reverse_ssh should not, by itself, be treated as proof of malicious activity.", "In combination with unauthorized installation, unexpected outbound connections or execution on a vulnerable vCenter appliance, however, it is a high-priority indicator requiring investigation." (QUIRSO, 2026-08-10)
Triage: administrators do legitimately place scheduled jobs on appliances and do run SSH from jump hosts, so neither artefact alone resolves. What separates this activity is the appliance being the SSH client toward an external network, a scheduled entry created outside a change window and not present in the platform team's configuration baseline, and either appearing on a vCenter whose build predates the VMSA-2026-0006 fixes. On an appliance patched before 29 July none of the three should be present at all.
CISA added CVE-2026-59310 to its Known Exploited Vulnerabilities catalog on 2026-08-18, a jurisdiction-agnostic confirmation of active exploitation, independent of any US-FCEB remediation deadline, layered on top of NCSC-CH's own actively-exploited determination already recorded above.
QUIRSO's continued work on the campaign this entry has tracked since 13 August now attributes the activity to a suspected China-nexus actor and reports that Babuk-derived ransomware was deployed against ESXi hosts in at least one investigated case: "the digital forensics company assessed a suspected advanced persistent threat (APT) actor was responsible, counting 361 victim IP addresses across 47 countries" (Infosecurity Magazine, citing QUIRSO GmbH, 2026-08-14). The ransomware deployment (.babyk extension) is assessed by QUIRSO as plausibly a smokescreen rather than the operation's goal: "the deployment [of Babuk-derived ransomware] may not have been the primary objective of the campaign" (The Hacker News, paraphrasing QUIRSO's assessment, 2026-08-17), plausibly intended to encrypt ESXi log files and hinder forensics rather than for extortion.
Both findings warrant the same caveat this entry already applies to the CVE-2026-59309 scanning correlation: every outlet surveyed (The Hacker News, Infosecurity Magazine, and further security-press pickup) cites QUIRSO's own Medium write-ups as the sole source for the China-nexus attribution (built on a UTC+08:00 activity pattern, Chinese-language code artefacts, and reuse of a Chinese security publication) at QUIRSO's own stated moderate confidence, and for the ransomware finding. Two outlets reporting one firm's conclusion is wide distribution of a single assessor's work, not independent corroboration of it; the attribution and the ransomware-deployment finding should be read as QUIRSO's own assessment, not as cross-verified intelligence, and are recorded here on that basis rather than folded into this entry's overall A/1 rating, which reflects the multi-CERT-corroborated vulnerability and initial-exploitation facts.
Nothing in this update changes the remediation guidance already given above: patch every internet-reachable vCenter to the fixed builds, and treat any instance that was internet-reachable and unpatched between 29 July and 3 August as a compromise-assessment candidate rather than a patch-and-close item, that assessment should now explicitly include a check for Babuk-derived (.babyk) file extensions on any ESXi hosts the appliance manages, alongside the reverse_ssh persistence and cron-entry artefacts already described.