Glossary of Terms

The software layer that creates, manages, and enforces isolation between virtual machines running on a physical host. The hypervisor sits between the physical hardware (CPU, RAM, storage, network) and the guest VMs, allocating resources and maintaining boundaries. It is the enforcement engine for VM isolation — if the hypervisor has a bug that weakens isolation, it affects every VM it manages. Also called a Virtual Machine Monitor (VMM). Two types: Type 1 (bare-metal, runs directly on hardware — VMware ESXi, Microsoft Hyper-V) and Type 2 (hosted, runs on a host OS — VMware Workstation, VirtualBox).

A software-based emulation of a physical computer, running a complete operating system and applications inside an isolated container managed by a hypervisor. Each VM believes it has its own dedicated CPU, memory, storage, and network — but these are virtual resources mapped to physical hardware by the hypervisor. VMs share the same security risks as physical machines (OS vulnerabilities, application vulnerabilities, misconfiguration) plus additional virtualization-specific risks (VM escape, resource reuse).

A critical attack where an attacker breaks out of the isolated VM environment and gains access to the hypervisor host OS or other guest VMs on the same physical machine. VM escape defeats the core isolation promise of virtualization. A successful VM escape typically gives the attacker control over the host system and, from there, access to every VM the host manages. VM escape exploits are usually chained vulnerabilities — combining a guest OS bug with a hypervisor hardware simulation bug. The 2017 Pwn2Own demonstration is the canonical real-world example.

A virtualization vulnerability where physical resources (most critically memory/RAM) are reclaimed from one VM and reassigned to another without being properly cleared. If memory pages are not zeroed before reassignment, residual data from the first VM (credentials, encryption keys, application data) may be readable by the second VM. Resource reuse is an information disclosure vulnerability. Modern hypervisors include memory scrubbing/zeroing logic, but bugs in this logic can leave windows where data leaks between VMs.

The accumulation of an unmanaged, untracked number of virtual machines that grows beyond what security and operations teams can effectively govern. Because VMs can be provisioned in minutes, users and developers create them for testing, experiments, or short-term projects and often fail to decommission them when the work is done. Orphaned VMs (no active owner, not tracked in inventory) accumulate with unpatched operating systems, unchanged network access, and no monitoring. VM sprawl significantly expands the attack surface of a virtualized environment.

The fundamental security property of a hypervisor that prevents one VM from accessing the memory, storage, processes, or network traffic of another VM on the same physical host. Isolation is enforced by the hypervisor — VMs are logically self-contained. Isolation can be broken by hypervisor bugs (VM escape), memory management flaws (resource reuse), or misconfigured network settings that allow VMs to communicate when they should not.

The hypervisor process of overwriting physical memory pages with zeros before reassigning them from one VM to another. Memory scrubbing prevents resource reuse data leakage — a VM that receives a zeroed memory page cannot read anything from the previous VM that used that memory. Proper memory scrubbing is a critical security control in multi-tenant virtualized environments (cloud hosting, shared infrastructure) where VMs from different customers or different trust levels run on the same physical host.

A vulnerability where an attacker with limited privileges inside a VM gains higher privileges — either higher privileges within the guest OS, or (in the worst case) elevated access beyond the VM boundary toward the hypervisor. Local privilege escalation is a common step in VM escape attack chains: an attacker first achieves limited code execution, then escalates privileges to gain kernel-level control of the guest, and then attempts to exploit a hypervisor bug to escape the VM entirely.

A vulnerability in the hypervisor's emulation of hardware devices for guest VMs. Hypervisors simulate virtual hardware components (network cards, storage controllers, display adapters, USB controllers) that guests believe are real physical hardware. Bugs in this simulation layer — particularly in how it handles unusual or malformed inputs from the guest — can allow a guest to manipulate the hypervisor directly. Hardware simulation bugs were the critical final step in the Pwn2Own 2017 VMware escape: the attackers used a VMware hardware simulation bug to move from guest OS compromise to host system access.

A real-world VM escape demonstration at the March 2017 Pwn2Own hacking competition. Researchers chained three vulnerabilities: (1) A JavaScript engine bug in Microsoft Edge achieved code execution inside the Edge sandbox. (2) A Windows 10 kernel bug escalated this to full guest OS compromise. (3) A VMware hardware simulation bug escaped the VM and reached the host. All three vendors patched their respective vulnerabilities after the competition. This is the primary real-world VM escape example referenced in CompTIA Security+ materials.