CVE-2023-20867

What it actually does

CVE-2023-20867 is an authentication-bypass flaw in VMware Tools/open-vm-tools affecting host-to-guest operations. If an attacker has already fully compromised an ESXi host, they can interfere with VMware Tools authentication for operations performed from the hypervisor into a guest virtual machine. This can allow unauthorized access to or modification of data inside guest VMs through VMware Tools guest-operation mechanisms, weakening the intended boundary between the hypervisor management plane and guest operating systems. The issue requires high privileges and local control of the ESXi host, but it has been observed in active exploitation and is listed in CISA KEV.

Why it matters to the business

Organizations running affected VMware Tools versions should treat this as a post-hypervisor-compromise risk: once an ESXi host is taken over, the attacker may more easily pivot into guest workloads, access sensitive data, or modify systems hosted on that hypervisor. This is especially important for virtualized server farms, managed hosting, regulated workloads, and environments where hypervisor administrators and guest administrators are intentionally separated. Because it is in CISA KEV with a remediation due date of 2023-07-14 and exploitation is reported in the wild, remediation is overdue for any still-exposed systems.

How an attack unfolds

An attacker first obtains full administrative or root-level control of an ESXi host. From that position, they target guest VMs that have vulnerable VMware Tools or open-vm-tools installed. The attacker abuses the host-to-guest VMware Tools communication path used for guest operations such as file access, process interaction, or management functions. By forcing VMware Tools to fail or bypass expected authentication checks, the attacker can perform unauthorized operations against the guest VM, potentially reading sensitive files, altering guest content, staging tooling, or manipulating workloads. Exploitation is most relevant after ESXi compromise, and detection should therefore include both hypervisor compromise evidence and suspicious VMware Tools guest-operation activity.

How to fix it

Upgrade VMware Tools/open-vm-tools in all affected guest operating systems to a vendor-fixed release. For VMware-managed tools, deploy the patched VMware Tools version supplied by VMware for the June 2023 advisory or later. For Linux distributions such as Debian and Fedora that package open-vm-tools, apply the relevant security updates from the distribution repositories. Prioritize VMs on Internet-exposed, high-value, multi-tenant, regulated, or shared ESXi hosts. Because exploitation requires a compromised ESXi host, also harden and patch ESXi hosts, restrict vCenter/ESXi administrative access, enforce MFA for management access, review privileged accounts, segment management networks, and monitor for unauthorized hypervisor administration. If immediate upgrade is not possible, reduce risk by limiting access to ESXi/vCenter management interfaces, disabling unnecessary guest operations where operationally feasible, and closely monitoring VMware Tools guest-operation activity.

How to confirm the fix worked

Confirm exposure by inventorying VMware Tools/open-vm-tools versions across all guest VMs using vCenter tools status, guest package managers, or direct commands such as `vmtoolsd -v`, `rpm -q open-vm-tools`, or `dpkg -l open-vm-tools`. Validate that each guest is running a vendor-fixed version released after the June 2023 advisory or a distribution package containing the CVE fix. Confirm ESXi and vCenter hosts are fully patched and that management-plane access is restricted. Review vCenter/ESXi event logs to ensure there are no unexpected guest-operation events after remediation. Where possible, perform a controlled test to verify authenticated guest operations still require valid guest credentials and that unauthenticated host-to-guest operations are rejected.

Typical attack path

1. Gain privileged access to an ESXi host through stolen credentials, an exposed management interface, another vulnerability, or administrative compromise.
2. Enumerate virtual machines on the compromised host and identify guests running affected VMware Tools or open-vm-tools versions.
3. Use the ESXi host management context or guest-operations interfaces to communicate with VMware Tools inside a target guest VM.
4. Trigger the authentication-bypass condition so VMware Tools does not properly authenticate host-to-guest operations.
5. Read or modify guest VM data, stage files, or perform unauthorized guest-management actions.
6. Use access to guest workloads for data theft, persistence, lateral movement, or further compromise.

How to detect it

To determine whether this was already exploited, investigate from both the hypervisor side and the guest side. On the VMware management plane, review vCenter, ESXi hostd, vpxa, and vpxd logs for unexpected guest-operation tasks, especially file transfers, process starts, credential-related failures, or activity performed by unusual administrative accounts. On ESXi hosts, review `/var/log/hostd.log`, `/var/log/vpxa.log`, `/var/log/vmkernel.log`, and VM-specific `vmware.log` files for guest-operation, VIX, or VMware Tools communication anomalies. In guest operating systems, review VMware Tools logs such as Linux `/var/log/vmware-vmsvc.log`, `/var/log/vmware-vmtoolsd-root.log`, and Windows `C:\ProgramData\VMware\VMware Tools\vmtoolsd.log`; correlate with OS authentication logs, process creation telemetry, file creation events, and command execution events. Look for guest processes or file changes whose parentage, timestamp, or initiating account does not match normal administrative activity. Because exploitation requires a compromised ESXi host, also hunt for preceding hypervisor compromise indicators: unexpected root or administrator logins, SSH enablement, new local users, unusual vCenter tasks, datastore browsing, VM snapshot/export activity, and management access from unfamiliar source IPs.

• StartProgramInGuest
• InitiateFileTransferToGuest
• InitiateFileTransferFromGuest
• ListProcessesInGuest
• GuestOperations
• guestOperations
• VixTools
• vmtoolsd
• vmware-vmsvc
• /var/log/hostd.log
• /var/log/vpxa.log
• /var/log/vmkernel.log
• vmware.log
• /var/log/vmware-vmsvc.log
• /var/log/vmware-vmtoolsd-root.log
• C:\ProgramData\VMware\VMware Tools\vmtoolsd.log
• open-vm-tools
• vmtoolsd -v

What your security team should do

• Immediately inventory VMware Tools/open-vm-tools versions across all virtual machines and identify outdated installations.
• Prioritize remediation for guests running on high-value or externally managed ESXi clusters, especially where the CISA KEV deadline was missed.
• Upgrade VMware Tools/open-vm-tools to fixed vendor or Linux distribution packages.
• Review ESXi and vCenter administrative access for suspicious logins, new accounts, privilege changes, and unusual task execution.
• Harden the virtualization management plane with MFA, restricted management-network access, least-privilege roles, and centralized logging.
• Hunt for suspicious VMware guest operations such as unexpected guest process starts, file transfers, or VMware Tools activity initiated from hypervisor management contexts.
• If ESXi compromise is suspected, treat guest VMs on that host as potentially exposed and perform guest-level forensic review.
• Add SIEM detections for VMware guest-operation events, VMware Tools log anomalies, and unexpected use of vmtoolsd/VIX-related activity.