Known escape exploits

ESXi guest-to-host escapes cluster around a few device models that have produced repeated vulnerabilities: the SVGA 3D graphics path, the USB controllers (notably UHCI and XHCI), the vmxnet3 and e1000 NICs, and the GuestRPC and VMCI control channels. Knowing which component carried a given cluster of bugs guides matching a target build to a usable escape.

2 ನಿಮಿಷದ ಓದುಅಕ್ಟೋ 7,2026 ರಂದು ನವೀಕರಿಸಲಾಗಿದೆflorianamette1 ಕೊಡುಗೆದಾರ
ನಿಮ್ಮ ಸಹಾಯಕವನ್ನು ಕೇಳಿ (MCP)GitHub ನಲ್ಲಿ ಸಂಪಾದಿಸಿ

The ESXi guest-to-host escapes that have been published cluster tightly around the same device models, because those are where guest-controlled data is parsed in the vmx process. Knowing the pattern lets an attacker match a target ESXi build to the component most likely to carry a usable bug. The recurring clusters:

  • USB controllers: the UHCI and later the XHCI models have repeatedly yielded out-of-bounds and use-after-free bugs in descriptor and ring handling; USB has been a frequent Pwn2Own escape vector.
  • SVGA 3D graphics: surface, shader, and command-stream handling in the 3D path has produced out-of-bounds writes and type confusions, a staple of VMware escape research.
  • vmxnet3 and e1000 NICs: ring and descriptor handling, and the vmxnet3 configuration interface, have carried out-of-bounds access bugs.
  • GuestRPC and VMCI: the shared-folders (HGFS) and drag-and-drop/copy-paste RPC handlers, and VMCI datagram processing, have produced memory-corruption escapes shared with the desktop products.

Using the pattern#

bash
# fingerprint the exact ESXi build to match against advisories
vmware -v 2>/dev/null; esxcli system version get 2>/dev/null
# from a guest, confirm which vulnerable device models are present/enabled
lspci -nn; lsusb                           # XHCI present? vmxnet3 vs e1000?
# 3D acceleration enabled (SVGA 3D surface reachable)?
grep -i mks /vmfs/volumes/*/*/*.vmx 2>/dev/null   # mks.enable3d = TRUE

A practical approach is to enumerate which of these models the target VM exposes and which are enabled (3D acceleration, the specific USB controller version, the NIC type), then match the ESXi build against the advisory for that component. Escapes are build-specific and generally require an ASLR-defeating leak paired with the memory-corruption primitive.

Exploitation notes#

  • Device configuration matters: 3D acceleration and the USB controller version are set per-VM, so the reachable surface depends on the .vmx settings, not just the ESXi version.
  • The desktop products (Workstation, Fusion) share the SVGA, USB, and GuestRPC code, so an escape in one often indicates the same bug class in the others; see Known escape exploits there.
  • Treat these as a mapping aid, not a copy-paste exploit source; the mechanisms are on the per-device pages under Guest-to-host escape.

References#

ಹಿಂದಿನದುBackdoor and VMCIಮುಂದಿನದು Workstation and Fusion