Compromising a virtual machine gives an attacker one workload. Compromising vCenter can give them the interface that creates, snapshots, reconfigures, and powers many workloads. That is why two 9.8-rated vCenter vulnerabilities deserve priority even though Broadcom’s advisory does not claim active exploitation.

CVE-2026-59309 bypasses authentication in VMware Directory Service. CVE-2026-59310 is a directory-traversal flaw in the syslog server that can lead to arbitrary code execution. Broadcom provides patches and says there are no workarounds.

TL;DR

  • Patch vCenter according to VMSA-2026-0006.1; there is no vendor workaround.
  • Keep vCenter off the public internet and reachable only through a controlled management path.
  • Review SSO, directory, role, task, event, and syslog activity before assuming a patched appliance was never compromised.
  • If compromise is suspected, investigate ESXi hosts and managed workloads too—the control plane’s reach defines the incident boundary.

Two Flaws, Two Security Boundaries

Broadcom’s advisory describes both vulnerabilities as network exploitable and rates each CVSS 9.8.

CVE-2026-59309 — VMware Directory Service authentication bypass. An attacker with network access to vCenter can bypass authentication and gain unauthorized access. The defect attacks the identity boundary: the component expected to decide who may enter can be made to accept someone who did not prove their identity.

CVE-2026-59310 — syslog server directory traversal. An attacker with network access can exploit path handling in the syslog service and execute arbitrary code. The defect attacks the filesystem boundary: data intended for one location can reach somewhere the service treats as executable or security-sensitive.

Either route matters because vCenter is not an ordinary application server. It holds inventory, administrative identities, host relationships, certificates, and the authority to orchestrate virtual infrastructure.

🔴 RED TEAM — Why the Control Plane Multiplies Access

Attacker reaches vCenter services
        ↓
Authentication is bypassed or syslog path handling is abused
        ↓
Unauthorized access or code execution lands on the appliance
        ↓
Attacker targets roles, sessions, host trust, and administrative workflows
        ↓
One control-plane compromise can affect multiple hosts and workloads

The final step depends on configured privileges and connectivity; the CVEs do not magically compromise every guest. But vCenter exists specifically to administer the environment, so incident scope must include what the appliance could control, not only files stored on vCenter itself.

🔵 BLUE TEAM — Patch Without Losing the Investigation

1. Apply the Current Fixed Release

VMSA-2026-0006.1 lists these remediation targets:

Product lineFixed release listed by Broadcom
vCenter Server 9.1.x9.1.0.0300
vCenter Server 9.0.x9.0.2.0100
vCenter Server 8.08.0 U3k or 8.0 U2f
VMware Cloud Foundation 5.xAsync patch to vCenter 8.0 U3k

Use the matrix and linked product documentation for your exact deployment, including Telco Cloud products. Take supported backups and follow Broadcom’s update procedure. Do not rely on a snapshot as the only recovery method for a management appliance.

Verify the running build after the update and confirm that all linked or redundant appliances reached the intended version. Broadcom says no workaround is available, so network isolation is a temporary risk reduction, not closure.

2. Put vCenter Behind a Management Boundary

Permit access only from administration workstations or a hardened jump host over a dedicated management network. Require MFA for administrative identities where supported, separate daily user accounts from privileged accounts, and remove direct internet exposure.

Restrict service-to-service access as well. A firewall rule that blocks laptops but permits every server subnet still gives a compromised workload a path to the control plane.

3. Look for Control-Plane Changes

Before closing the incident, review:

  • unexpected SSO or VMware Directory Service authentications and sessions;
  • new users, group memberships, role assignments, or permission changes;
  • unusual tasks and events involving hosts, VMs, snapshots, templates, or networking;
  • syslog service errors, unexpected files, child processes, or outbound connections;
  • certificate, trust, identity-source, alarm, and forwarding configuration changes;
  • gaps or tampering in logs that should normally be forwarded off the appliance.

Baseline legitimate automation accounts first. Backup, monitoring, and orchestration systems can be noisy, but their usual source, schedule, and action pattern should be predictable.

4. Expand Response to What vCenter Could Reach

If evidence indicates compromise, preserve appliance and external logs and follow Broadcom support guidance for recovery. Rotate privileged SSO and integration credentials, revoke suspicious sessions, and validate host trust. Examine ESXi hosts and high-value VMs for unauthorized configuration changes, mounted media, snapshots, account changes, or unexpected power and console events.

Rebuilding vCenter alone is insufficient if stolen credentials remain valid or if attacker-created changes persist on managed hosts.

Prevent the Next Control-Plane Crisis

Treat virtualization management as a separate security tier. Centralize its logs outside the infrastructure it controls, use a dedicated identity path for administrators, test appliance recovery, and maintain an inventory that maps each vCenter to its hosts, credentials, backup, and network exposure.

Patch urgency should combine vulnerability severity with system authority. A 9.8 flaw in the component that manages the estate belongs near the front of the queue—even before exploitation is publicly confirmed.

Sources