VMware ESXi contains an authentication bypass vulnerability. A malicious actor with sufficient Active Directory (AD) permissions can gain full access to an ESXi host that was previously configured to use AD for user management https://blogs.vmware.com/vsphere/2012/09/joining-vsphere-hosts-to-active-directory.html by re-creating the configured AD group ('ESXi Admins' by default) after it was deleted from AD.

Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.

VMware ESXi, Workstation, and Fusion contain a heap out-of-bounds write vulnerability in the USB 2.0 controller (EHCI). A malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine's VMX process running on the host. On ESXi, the exploitation is contained within the VMX sandbox whereas, on Workstation and Fusion, this may lead to code execution on the machine where Workstation or Fusion is installed.

In the add_match function in libbb/lineedit.c in BusyBox through 1.27.2, the tab autocomplete feature of the shell, used to get a list of filenames in a directory, does not sanitize filenames and results in executing any escape sequence in the terminal. This could potentially result in code execution, arbitrary file writes, or other attacks.

The Virtual Machine Communication Interface (VMCI) implementation in vmci.sys in VMware Workstation 8.x before 8.0.5 and 9.x before 9.0.1 on Windows, VMware Fusion 4.1 before 4.1.4 and 5.0 before 5.0.2, VMware View 4.x before 4.6.2 and 5.x before 5.1.2 on Windows, VMware ESXi 4.0 through 5.1, and VMware ESX 4.0 and 4.1 does not properly restrict memory allocation by control code, which allows local users to gain privileges via unspecified vectors.

VMware Workstation 8.x before 8.0.4, VMware Player 4.x before 4.0.4, VMware ESXi 3.5 through 5.0, and VMware ESX 3.5 through 4.1 allow remote attackers to cause a denial of service (guest OS crash) via crafted traffic from a remote virtual device.

VMware Workstation 7.x before 7.1.6 and 8.x before 8.0.4, VMware Player 3.x before 3.1.6 and 4.x before 4.0.4, VMware Fusion 4.x before 4.1.3, VMware ESXi 3.5 through 5.0, and VMware ESX 3.5 through 4.1 allow user-assisted remote attackers to execute arbitrary code on the host OS or cause a denial of service (memory corruption) on the host OS via a crafted Checkpoint file.

VMware Workstation 8.x before 8.0.3, VMware Player 4.x before 4.0.3, VMware Fusion 4.x through 4.1.2, VMware ESXi 3.5 through 5.0, and VMware ESX 3.5 through 4.1 do not properly configure the virtual floppy device, which allows guest OS users to cause a denial of service (out-of-bounds write operation and VMX process crash) or possibly execute arbitrary code on the host OS by leveraging administrative privileges on the guest OS.

VMware Workstation 8.x before 8.0.3, VMware Player 4.x before 4.0.3, VMware Fusion 4.x before 4.1.2, VMware ESXi 3.5 through 5.0, and VMware ESX 3.5 through 4.1 do not properly register SCSI devices, which allows guest OS users to cause a denial of service (invalid write operation and VMX process crash) or possibly execute arbitrary code on the host OS by leveraging administrative privileges on the guest OS.

VMware Workstation 8.x before 8.0.2, VMware Player 4.x before 4.0.2, VMware Fusion 4.x before 4.1.2, VMware ESXi 3.5 through 5.0, and VMware ESX 3.5 through 4.1 use an incorrect ACL for the VMware Tools folder, which allows guest OS users to gain guest OS privileges via unspecified vectors.