VMware ESXi VMXNET3 Out-of-Bounds Write VM Escape

CVE-2026-47876 is an out-of-bounds write in VMware ESXi's VMXNET3 virtual network adapter emulation code. An attacker who holds local administrative privileges inside a guest VM can craft malicious operations against the paravirtualized VMXNET3 device to corrupt memory in the VMX process running on the ESXi host, achieving arbitrary code execution outside the VM boundary. This is a classic guest-to-host VM escape. Affected versions span ESXi 8.0 (all builds before ESXi80U3k-25595708), ESXi 9.0.x (before 9.0.2.0100-25595025), ESXi 9.1.x (before 9.1.0.0200-25557999), and VMware Cloud Foundation 5.x via async patching. VMXNET3 is the default and recommended virtual NIC adapter for all modern VMware VMs — meaning the vulnerable configuration is near-universal. The bug was discovered by Nguyen Hoang Thach of STARLabs SG and demonstrated as a working exploit at Pwn2Own Berlin 2026 in May 2026, earning $200,000. Broadcom published patches via VMSA-2026-0006 on July 29, 2026.

Broadcom rates CVE-2026-47876 at CVSS 9.3 Critical, and that score is *justified*. The CVSS vector AV:L/AC:L/PR:N/UI:N/S:C correctly captures the scope change — the attack crosses from guest to host — and the full C:H/I:H/A:H impact reflects that a compromised hypervisor means total control over every VM on that host. While the 'Local' attack vector and the requirement for VM admin access might tempt a downgrade, VMXNET3's near-universal deployment, the proven Pwn2Own exploit, and the catastrophic blast radius of hypervisor compromise mean the 9.3 score is appropriate. No vendor workaround exists. This one is as serious as the vendor says.

Why this verdict

• Proven exploitability: A working exploit was demonstrated live at Pwn2Own Berlin 2026 — this is not a theoretical bug. The researcher achieved full cross-tenant code execution, confirming the complete attack chain from VM admin to hypervisor control.
• Near-universal attack surface: VMXNET3 is VMware's default and recommended virtual NIC since vSphere 5.x. Switching to E1000/E1000E is a performance-degrading non-starter for production. >95% of VMware VMs run VMXNET3, so effectively every ESXi host is vulnerable.
• No vendor workaround: Broadcom explicitly states no workaround exists. The only fix is the patch. Interim mitigations (restricting VM admin, network segmentation) reduce likelihood but do not eliminate the vulnerability.
• Role multiplier: ESXi is canonically a hypervisor — the highest-value infrastructure role. VM escape on ESXi yields: (a) host compromise → access to all VMs on the host, (b) credential harvesting via VM memory inspection, (c) lateral movement to vCenter and other cluster hosts via vpxuser, (d) cross-tenant breach in multi-tenant/VDI environments. Blast radius is fleet-scale. Per the high-value-role rule, the affected component IS the hypervisor itself, meaning ≥10% of installs (100%, in fact) occupy the high-value role — verdict floor is CRITICAL.
• Patch-diff window is open: With patches released July 29, 2026 and established patch-to-PoC methodology published for prior VMXNET3 bugs, weaponized exploits could appear within 2-6 weeks. The clock is ticking.

Why not higher?

The score is already at 9.3 Critical — the highest practical rating for a local-vector vulnerability with scope change. A 10.0 would require network-reachable exploitation without any prerequisites, which this bug does not have (it requires VM admin access and local code execution inside a guest).

Why not lower?

Downgrading below CRITICAL would require evidence that the VM-admin prerequisite meaningfully limits exploitation *in the context of a hypervisor*. It does not: in cloud/hosting environments, every tenant IS a VM admin. In enterprise environments, compromised workloads routinely achieve VM-level admin. The blast radius of hypervisor compromise (every VM on the host, potential cluster-wide pivot) is too catastrophic to absorb any friction discount. The hard-rule floor for a hypervisor VM escape is CRITICAL, and no friction factor present here breaks that floor.

1. Restrict VM administrative access immediately — Audit and minimize who holds VM admin/root/SYSTEM credentials across your fleet. Remove standing admin access from VMs that don't require it. Use just-in-time privileged access for VM administration. This reduces the pool of VMs from which the exploit can be launched. Deploy within 3 days per noisgate mitigation SLA for CRITICAL.
2. Enable vSphere VM encryption and vTPM where feasible — Encrypted VMs add a layer of memory protection that complicates (but does not prevent) host-level credential harvesting after a VM escape. This limits post-exploitation value. Deploy within 3 days.
3. Segment ESXi management networks aggressively — Ensure ESXi management interfaces (port 443, SSH, DCUI) are on isolated VLANs unreachable from VM guest networks. This limits an attacker's ability to pivot from a compromised host to vCenter or other ESXi hosts. Deploy within 3 days.
4. Monitor VMX process anomalies on ESXi hosts — Forward ESXi syslog (/var/log/vmkernel.log, /var/log/hostd.log) to your SIEM. Alert on VMX process crashes, unexpected restarts, or core dumps — these may indicate exploitation attempts. Deploy within 3 days.
5. Prioritize patching hosts running multi-tenant or high-value workloads — If you cannot patch all hosts simultaneously, triage by blast radius: VDI clusters, shared hosting, and hosts running domain controllers, PKI, backup infrastructure, or production databases go first. Begin patch rollout within 3 days, complete within 90 days per noisgate remediation SLA.

Run this script on each ESXi host via SSH (or remotely via esxcli through vCenter). Requires root access. Example: ssh root@esxi-host 'sh /tmp/check_cve_2026_47876.sh'

#!/bin/sh
# CVE-2026-47876 — VMware ESXi VMXNET3 OOB Write (VM Escape)
# Checks ESXi build number against patched builds from VMSA-2026-0006.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

PATCHED_80=25595708   # ESXi80U3k
PATCHED_90=25595025   # ESXi 9.0.2.0100
PATCHED_91=25557999   # ESXi 9.1.0.0200

# Retrieve version info
VER_LINE=$(esxcli system version get 2>/dev/null)
if [ -z "$VER_LINE" ]; then
  echo "UNKNOWN — unable to query ESXi version. Is this an ESXi host?"
  exit 2
fi

VERSION=$(echo "$VER_LINE" | grep 'Version:' | awk '{print $2}')
BUILD=$(echo "$VER_LINE" | grep 'Build:' | awk '{print $NF}')
PRODUCT=$(echo "$VER_LINE" | grep 'Product:' | awk '{print $2}')

if [ -z "$BUILD" ]; then
  echo "UNKNOWN — could not parse build number."
  exit 2
fi

echo "Host: $(hostname) | Product: $PRODUCT | Version: $VERSION | Build: $BUILD"

# Check for VMXNET3 adapters on any VM
VMXNET3_VMS=$(grep -rl 'vmxnet3' /vmfs/volumes/*//*.vmx 2>/dev/null | wc -l)
echo "VMs with VMXNET3 adapters: $VMXNET3_VMS"

MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)

case "$MAJOR" in
  8)
    if [ "$BUILD" -ge "$PATCHED_80" ] 2>/dev/null; then
      echo "PATCHED — build $BUILD >= $PATCHED_80 (ESXi80U3k)"
      exit 0
    else
      echo "VULNERABLE — build $BUILD < $PATCHED_80 (need ESXi80U3k)"
      exit 1
    fi
    ;;
  9)
    if [ "$MINOR" = "1" ]; then
      THRESHOLD=$PATCHED_91
      LABEL="ESXi 9.1.0.0200"
    else
      THRESHOLD=$PATCHED_90
      LABEL="ESXi 9.0.2.0100"
    fi
    if [ "$BUILD" -ge "$THRESHOLD" ] 2>/dev/null; then
      echo "PATCHED — build $BUILD >= $THRESHOLD ($LABEL)"
      exit 0
    else
      echo "VULNERABLE — build $BUILD < $THRESHOLD (need $LABEL)"
      exit 1
    fi
    ;;
  *)
    echo "UNKNOWN — ESXi major version $MAJOR is outside known affected range (8.x, 9.x)"
    exit 2
    ;;
esac

Sources

1. Broadcom VMSA-2026-0006 Advisory
2. SecurityWeek — Critical VM Escape Vulnerability Patched in VMware ESXi
3. The Hacker News — Three Critical VMware Flaws
4. VMware Security Blog — Pwn2Own Berlin 2026
5. VMware VCF Security Advisory on GitHub
6. Security Affairs — Broadcom Patches Critical VMware ESXi Vulnerability
7. Zero Day Engineering — VMware ESXi VMXNET3 Patch-to-PoC Methodology
8. Vali Cyber — Pwn2Own Berlin 2026 ESXi VM Escape