Active Internet Scanning Targets Critical Authentication Bypass and Remote Code Execution Vulnerabilities in VMware vCenter and ESX
Security Advisory Brief
Broadcom released security advisory VMSA-2026-0006 on July 29, 2026, addressing a set of critical vulnerabilities across the VMware virtualization portfolio, including VMware vCenter, ESX, VMware Cloud Foundation, VMware vSphere Foundation, and VMware Telco Cloud. Two of the disclosed issues, CVE-2026-59309 and CVE-2026-59310, each carry a CVSS v3.1 base score of 9.8 and allow an unauthenticated attacker with network access to vCenter to bypass authentication or execute arbitrary code. A third issue, CVE-2026-47876, carries a CVSS v3.1 base score of 9.3 and permits a virtual machine guest to break out of its isolation boundary and execute code on the underlying ESX host. Broadcom has confirmed that no workarounds exist for the two vCenter vulnerabilities, making the vendor updates the only available remediation.
Within days of disclosure, security researchers operating internet-facing honeypot infrastructure observed a measurable increase in reconnaissance directed at exposed vCenter deployments. The observed activity consists of unauthenticated requests to the vCenter web services endpoint at /sdk/ using the RetrieveServiceContent method, which returns version and build information without requiring credentials, alongside probing of the /websso single sign-on paths associated with the VMware Directory Service component named in CVE-2026-59309. This traffic pattern is characteristic of mass fingerprinting: attackers are enumerating which internet-exposed vCenter instances are running unpatched builds so that target lists are ready when working exploit code becomes available.
As of this writing, no public proof-of-concept exploit code has been released and no confirmed in-the-wild exploitation of these vulnerabilities has been reported. That distinction should not be read as reassurance. vCenter is the administrative control plane for the entire virtual estate, and historically the window between disclosure of a critical vCenter flaw and the appearance of weaponized exploit code has been measured in weeks rather than months. Organizations that treat the current reconnaissance activity as an early warning, and complete patching before exploit code circulates, will materially reduce their exposure. Organizations that wait will be patching under incident conditions.
Threats and Vulnerabilities
CVE-2026-59309, with a CVSS v3.1 base score of 9.8, is an authentication bypass vulnerability in the VMware Directory Service, the vmdir component that underpins vCenter Single Sign-On and holds the identity store for the virtual environment. The flaw is classified as CWE-303, an incorrect implementation of an authentication algorithm, and is reachable by any actor with network access to the vCenter management interface with no credentials, no user interaction, and low attack complexity. Successful exploitation grants unauthorized access to the vCenter system itself, which in practice means administrative visibility and control over every ESX host, virtual machine, datastore, and virtual network that vCenter manages. The vulnerability affects vCenter 8.0 prior to update U3k, vCenter 9.0.x prior to 9.0.2.0100, and vCenter 9.1.x prior to 9.1.0.0300, along with the corresponding VMware Cloud Foundation 5.x, 9.0.x, and 9.1.x releases, VMware vSphere Foundation 9.0.x and 9.1.x, VMware Telco Cloud Infrastructure 3.0, and VMware Telco Cloud Platform 3.0, 4.x, 5.0.x, and 5.1.x. Broadcom has stated that no workaround is available.
CVE-2026-59310, also carrying a CVSS v3.1 base score of 9.8, is a directory traversal vulnerability in the vCenter Syslog server, classified as CWE-22, improper limitation of a pathname to a restricted directory. An actor with network access to vCenter may exploit the flaw to write outside the intended log directory and achieve arbitrary code execution on the appliance. Because the syslog collector accepts data from managed hosts and network devices by design, the attack surface is exposed on any deployment where vCenter is performing log aggregation, and exploitation requires neither authentication nor user interaction. The affected and fixed version ranges mirror those of CVE-2026-59309, and as with that vulnerability, Broadcom has published no workaround. Where an attacker chains this issue with the authentication bypass, the result is unauthenticated remote code execution on the platform that governs the entire virtual estate.
CVE-2026-47876, with a CVSS v3.1 base score of 9.3, is an out-of-bounds write vulnerability, classified as CWE-787, in the VMXNET3 paravirtualized network adapter used by VMware ESX. A malicious actor holding local administrative privileges inside a guest virtual machine configured with a VMXNET3 adapter may exploit the flaw to execute code on the underlying hypervisor host. This is a virtual machine escape: it breaks the isolation boundary that separates tenant workloads from one another and from the host, and the CVSS vector reflects that scope change. The vulnerability affects VMware ESX 8.0, 9.0.x, and 9.1.x, along with VMware Cloud Foundation 5.x, 9.0.x, and 9.1.x, VMware vSphere Foundation 9.0.x and 9.1.x, and VMware Telco Cloud Platform 5.0.x and 5.1.x. For environments that host workloads of differing trust levels on shared hardware, including multi-tenant hosting, development systems co-resident with production, or converged information technology and operational technology estates, this vulnerability collapses a control that many segmentation designs depend upon.
The reconnaissance activity observed against these vulnerabilities warrants attention in its own right. Requests to the /sdk/ endpoint invoking RetrieveServiceContent return the vCenter product line, version, and build number to an unauthenticated caller, providing an accurate patch-level determination without any intrusive action. Probing of /websso paths indicates specific interest in the Single Sign-On and VMware Directory Service components implicated in CVE-2026-59309. Neither request pattern is inherently malicious in isolation, and both appear in legitimate administrative and monitoring traffic, which is precisely why they make effective pre-exploitation reconnaissance. The meaningful signal is the source: these requests originating from external addresses against an internet-reachable vCenter instance indicate that the deployment is already on a target list.
Client Impact
The operational impact of these vulnerabilities is difficult to overstate because vCenter is not merely another application server. Compromise of vCenter yields administrative authority over the hypervisor layer, and from that position an attacker can clone or snapshot virtual machines to extract data without touching guest operating system logging, deploy code directly to ESX hosts, disable or blind virtual security appliances, alter virtual networking to defeat segmentation, and encrypt or delete datastores in a single action. Ransomware operators have made hypervisor-level encryption a standard element of their playbooks for exactly this reason: a single successful action at the ESX layer takes down hundreds of guest systems simultaneously and renders guest-level backup agents useless. For organizations running industrial, energy, or utility environments, virtualized human-machine interfaces, historians, engineering workstations, and jump hosts commonly share the same cluster, and a hypervisor compromise reaches all of them at once regardless of the network zoning applied to the guests.
The compliance consequences follow directly from that operational reality. Organizations subject to NERC CIP requirements must account for virtualized cyber assets within their electronic security perimeter, and an unpatched vCenter reachable from a lower-trust network raises questions under CIP-005 electronic access controls and CIP-007 patch management, which requires evaluation of applicable security patches within thirty-five calendar days of availability. Environments aligned to IEC 62443 face a direct challenge to their zone and conduit model, since a virtual machine escape of the kind described in CVE-2026-47876 invalidates the assumption that guests on shared hardware are meaningfully separated. Organizations operating under NIS2, SEC cyber disclosure obligations, or sector-specific incident reporting rules should note that a hypervisor compromise affecting systems that process regulated or personal data will very likely meet the reporting threshold, and that demonstrating the scope of access after the fact is considerably harder when the attacker held administrative control of the platform generating the evidence.
Mitigations
1898 & Co. recommends the following actions, prioritized by the reduction in exposure each delivers:
- Apply the Broadcom VMSA-2026-0006 updates without waiting for a routine maintenance window. Upgrade vCenter Server to 8.0 U3k, or VMware Cloud Foundation and VMware vSphere Foundation to 9.0.2.0100 or 9.1.0.0300 as applicable to the deployed release line. Because Broadcom has published no workaround for either vCenter vulnerability, patching is the only remediation, and the vCenter appliance should be updated before the ESX hosts it manages.
- Remove vCenter, ESX, and all associated management interfaces from direct internet exposure immediately, before or in parallel with patching. Management plane access should be reachable only from a dedicated administrative network segment, and remote administrative access should traverse a controlled jump host with multifactor authentication enforced at the point of entry rather than relying on vCenter Single Sign-On alone.
- Review vCenter and reverse proxy logs for unauthenticated requests to the /sdk/ endpoint invoking RetrieveServiceContent and for requests to /websso paths originating from sources outside the approved administrative range. Correlate any such activity against the timeline of your patching effort, and treat external-origin requests to these paths against an unpatched instance as evidence that the deployment has been fingerprinted.
- Audit vCenter Single Sign-On and VMware Directory Service accounts for unexpected principals, recently created service accounts, unexplained privilege grants, and modifications to identity source configuration. Because CVE-2026-59309 bypasses authentication rather than defeating a credential, a successful intrusion may leave no failed logon record, so account inventory changes and session anomalies are the more reliable indicators.
- Inventory virtual machines using the VMXNET3 adapter and identify clusters that host workloads of differing trust levels on shared hardware. Until the ESX hosts are patched for CVE-2026-47876, treat guest administrative access on those clusters as equivalent to host access when performing risk assessments, and prioritize patching for any host running workloads with untrusted or externally accessible guests alongside sensitive systems.
Organizations should also verify that hypervisor-level backups are stored on infrastructure that is not reachable using vCenter credentials, since backup repositories accessible from a compromised management plane offer no recovery capability.
1898 & Co. Response
1898 & Co. has supported virtualization and management plane security programs across utility, energy, manufacturing, and critical infrastructure clients, with particular attention to environments where information technology and operational technology workloads share hypervisor infrastructure. Our security consultants help organizations determine which vCenter and ESX deployments are exposed, sequence remediation across converged estates where patching windows are constrained by operational schedules, and validate that the segmentation assumed in architecture documentation actually holds at the hypervisor layer.
Our managed threat detection service monitors virtualization management planes for the reconnaissance and post-exploitation behaviors associated with these vulnerabilities, including unauthenticated service content enumeration, anomalous single sign-on activity, unexpected changes to directory service principals, and administrative actions issued against ESX hosts outside of approved change windows. When indicators surface, our analysts work alongside client teams to establish scope and determine whether observed activity reflects opportunistic scanning or a foothold that requires an incident response.
1898 & Co. has conducted architecture reviews, in-depth security assessments, and incident response engagements for asset owners operating some of North America's most critical energy and industrial systems. Where clients need help evaluating exposure from VMSA-2026-0006, building a remediation sequence that respects operational constraints, or hunting for evidence of pre-exploitation reconnaissance in their environment, our team is available to assist.