A fully compromised ESXi host can force VMware Tools to fail to authenticate host-to-guest operations

CVE-2023-20867 is an authentication bypass in the vgauth module of VMware Tools (versions 10.3.0 through 12.2.4) and open-vm-tools. When an attacker has root-level access to an ESXi hypervisor, they can invoke Guest Operations — StartProgramInGuest, InitiateFileTransferToGuest, InitiateFileTransferFromGuest — against any guest VM running VMware Tools without authenticating to the guest OS. Critically, these operations generate no logging events by default on the guest, meaning EDR and SIEM see nothing. The fix is VMware Tools 12.2.5+ or equivalent distro backports (RHEL via RHSA-2023:3944, Debian 11 via 2:11.2.5-2+deb11u2, Ubuntu via 12.2.5-1+).

VMware rated this LOW (3.9) because the CVSS vector requires the attacker to already have full root on the ESXi host — a legitimately steep prerequisite. But that framing ignores the operational reality: ESXi hosts *are* being compromised at scale (CVE-2023-34048, CVE-2021-21974, ESXiArgs ransomware), and once one falls, CVE-2023-20867 is the mechanism that converts a single-host hypervisor compromise into silent, unlogged access to every guest VM on that host. UNC3886, a Chinese state-sponsored espionage group tracked by Mandiant, weaponized this as a zero-day since at least late 2021 — over 18 months before disclosure. The vendor severity dramatically underweights the blast radius and real-world exploitation context.

Why this verdict

• Active nation-state exploitation: UNC3886 weaponized this as a zero-day since late 2021, 18 months before disclosure. CISA KEV-listed. This is not a theoretical risk — it is a proven espionage tool targeting US defense and telecom.
• Role multiplier: VMware Tools is installed on >95% of enterprise VMs. The affected component sits at the hypervisor-to-guest trust boundary. Successful exploitation from a compromised ESXi host grants command execution on *every* guest VM — including domain controllers, production databases, backup servers, and CI/CD infrastructure. Blast radius is fleet-scale (host → all guests → potentially domain-scale). This floors the verdict at HIGH.
• Stealth multiplier: No default logging on guest VMs. EDR does not track file read operations from vmtoolsd. Network monitoring sees nothing (VMware backplane / VMCI sockets). This dramatically extends attacker dwell time — UNC3886 operated undetected for 18+ months.
• Prerequisite friction (partial downward pressure): Requires full root on ESXi, which is a significant gate. But ESXi compromises are happening — CVE-2023-34048, CVE-2021-21974, ESXiArgs ransomware campaigns demonstrate this prerequisite is routinely met by both nation-states and ransomware operators.
• CVSS undercount: The vector rates C:L/I:L, but executing arbitrary commands as SYSTEM/root on every guest VM with no logging is operationally high-impact, not low-impact. The CVSS model fails to capture the multiplicative effect across all guests on a host.

Why not higher?

Not CRITICAL because the vulnerability itself does not provide initial access — it requires a separate, fully successful exploit chain to first compromise the ESXi host at root level. The CVE is a post-compromise amplifier, not a standalone entry point. If ESXi root access were easier or if the VMware Tools bug itself were remotely exploitable, this would be CRITICAL.

Why not lower?

Not MEDIUM or LOW because of three hard factors: (1) KEV-listed with confirmed active exploitation by a nation-state APT since 2021, (2) the role multiplier floors the verdict at HIGH — VMware Tools is canonically a hypervisor-context component where >10% of installs sit on hosts running high-value workloads, and (3) the stealth characteristics (no default logging, EDR blind spots, VMCI invisibility) mean this vulnerability dramatically amplifies the impact of any ESXi compromise that does occur.

1. Enable debug-level vmsvc logging on all guest VMs immediately — Set vmsvc.level = debug and vmsvc.handler = file in VMware Tools configuration on every guest (Windows: C:\ProgramData\VMware\VMware Tools\tools.conf, Linux: /etc/vmware-tools/tools.conf). This is the only way to get visibility into Guest Operations exploitation. Deploy within the noisgate mitigation SLA of 30 days, but prioritize domain controllers and production databases within 7 days.
2. Forward ESXi hostd and VM logs to SIEM — Configure vmx.log.destination = syslog-and-disk on all VMs and forward ESXi /var/log/hostd.log to your SIEM. Set log.keepOld = 20 minimum. Alert on vpxuser logins with non-standard user agents (anything other than VMware-client/X.X.X). Deploy within 30 days per noisgate mitigation SLA.
3. Patch VMware Tools to 12.2.5+ on all guest VMs — This is the definitive fix. Prioritize VMs on ESXi hosts that are internet-adjacent or in less-trusted network zones. Use vCenter Update Manager for bulk deployment. Target completion within 180 days per noisgate remediation SLA for HIGH, but push critical infrastructure guests (DCs, backup servers) to 30 days.
4. Isolate ESXi management interfaces on dedicated VLAN with strict ACLs — ESXi management (port 443, SSH) should only be reachable from a hardened jump host on a dedicated management VLAN. This reduces the attack surface for the prerequisite ESXi compromise. If not already in place, deploy within 30 days.
5. Hunt for VMCI backdoors on existing guests — Run lsof -A on all Linux guests and review for SOCKET_VMCI type entries from non-VMware processes. On Windows, audit child processes of vmtoolsd.exe. Any unexpected VMCI listener is a high-confidence indicator of compromise. Execute hunt sweep within 7 days.
6. Monitor for anomalous vmtoolsd child processes via EDR — Create EDR detection rules alerting on unusual child process trees from vmtoolsd.exe (Windows) or vmtoolsd (Linux). Common legitimate children are limited; any shell, PowerShell, or unknown binary is suspicious. Deploy detection rule within 30 days.

Run this script on each Linux guest VM (not on the ESXi host) as root or with sudo. It checks the installed open-vm-tools / VMware Tools version against the patched version. Example: sudo bash check_cve_2023_20867.sh

#!/bin/bash
# CVE-2023-20867 VMware Tools Authentication Bypass Check
# Run on: Linux guest VMs (not ESXi hosts)
# Requires: root or sudo
# Outputs: VULNERABLE / PATCHED / UNKNOWN

set -euo pipefail

PATCHED_VERSION="12.2.5"
RESULT="UNKNOWN"

# Function to compare versions
version_gte() {
  printf '%s\n%s' "$1" "$2" | sort -V | head -n1 | grep -qx "$2"
}

# Check if VMware Tools / open-vm-tools is installed
if command -v vmware-toolbox-cmd &>/dev/null; then
  TOOLS_VERSION=$(vmware-toolbox-cmd -v 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  if [ -z "$TOOLS_VERSION" ]; then
    # Fallback: try vmtoolsd
    TOOLS_VERSION=$(vmtoolsd --version 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  fi
elif command -v vmtoolsd &>/dev/null; then
  TOOLS_VERSION=$(vmtoolsd --version 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
else
  echo "[*] VMware Tools / open-vm-tools not found on this host."
  echo "[*] If this is not a VMware guest VM, this CVE does not apply."
  echo "UNKNOWN"
  exit 2
fi

if [ -z "$TOOLS_VERSION" ]; then
  echo "[!] Could not determine VMware Tools version."
  echo "UNKNOWN"
  exit 2
fi

echo "[*] Detected VMware Tools version: $TOOLS_VERSION"
echo "[*] Patched version: >= $PATCHED_VERSION"

if version_gte "$TOOLS_VERSION" "$PATCHED_VERSION"; then
  echo "[+] VMware Tools $TOOLS_VERSION >= $PATCHED_VERSION"
  RESULT="PATCHED"
else
  echo "[-] VMware Tools $TOOLS_VERSION < $PATCHED_VERSION"
  RESULT="VULNERABLE"
fi

# Also check for distro-specific backport patches via package manager
if command -v dpkg &>/dev/null; then
  PKG_VER=$(dpkg -l open-vm-tools 2>/dev/null | awk '/^ii/{print $3}' || true)
  if [ -n "$PKG_VER" ]; then
    echo "[*] Distro package version: $PKG_VER"
    # Check for known patched Debian/Ubuntu versions
    if echo "$PKG_VER" | grep -qP '(deb11u[2-9]|deb12u[1-9]|12\.[2-9]\.[5-9]|12\.[3-9])'; then
      echo "[+] Distro backport patch detected."
      RESULT="PATCHED"
    fi
  fi
elif command -v rpm &>/dev/null; then
  PKG_VER=$(rpm -q open-vm-tools 2>/dev/null || true)
  if [ -n "$PKG_VER" ] && [ "$PKG_VER" != "package open-vm-tools is not installed" ]; then
    echo "[*] RPM package: $PKG_VER"
    # RHSA-2023:3944 and later contain the fix
    echo "[*] Verify against RHSA-2023:3944 errata for your RHEL version."
  fi
fi

# Check vmsvc logging status
TOOLS_CONF="/etc/vmware-tools/tools.conf"
if [ -f "$TOOLS_CONF" ]; then
  if grep -qi 'vmsvc.level.*=.*debug' "$TOOLS_CONF" 2>/dev/null; then
    echo "[+] vmsvc debug logging is ENABLED (good for detection)."
  else
    echo "[!] vmsvc debug logging is NOT enabled. Guest Operations exploitation will be invisible."
  fi
else
  echo "[!] $TOOLS_CONF not found. vmsvc logging is likely at defaults (disabled)."
fi

# Check for VMCI backdoor indicators
if command -v lsof &>/dev/null; then
  VMCI_SOCKETS=$(lsof -A 2>/dev/null | grep -i 'SOCKET_VMCI' | grep -v 'vmtoolsd' || true)
  if [ -n "$VMCI_SOCKETS" ]; then
    echo "[!!!] SUSPICIOUS: Non-VMware processes listening on VMCI sockets:"
    echo "$VMCI_SOCKETS"
    echo "[!!!] Investigate immediately — potential VIRTUALPITA/VIRTUALPIE backdoor."
  fi
fi

echo ""
echo "$RESULT"
exit $([ "$RESULT" = "PATCHED" ] && echo 0 || echo 1)

Sources

1. Mandiant — VMware ESXi Detection, Containment & Hardening
2. Mandiant — Chinese VMware Exploitation Since 2021
3. The Hacker News — UNC3886 Exploits Fortinet, VMware 0-Days
4. Qualys ThreatPROTECT — CVE-2023-20867 Advisory
5. Red Hat Security Advisory RHSA-2023:3944
6. Forescout — VMware ESXi: A Major Attack Vector for Ransomware
7. CISA Known Exploited Vulnerabilities Catalog
8. GitHub Advisory GHSA-qm59-f7vh-3m2p