CONCEPT Cited by 2 sources
VM Escape¶
A VM escape is when code running inside a guest virtual machine breaks through the hypervisor boundary and obtains execution or data access on the host system (or, in some variants, on a sibling guest VM sharing the same host).
(Source: sources/2026-04-21-figma-server-side-sandboxing-virtual-machines)
Why the hypervisor is a fat target¶
The hypervisor mediates many OS + hardware operations on behalf of guest VMs — memory management, device emulation, interrupt routing, paravirt drivers, sometimes even I/O passthrough — which makes its attack surface large and complex. Each of those mediation paths is code that runs with host privilege in response to guest-controlled input. Vulnerabilities occasionally surface and are weaponised into escapes that either take over the host or leak information about co-located guests.
Specialised hypervisors (Firecracker, cloud-hypervisor, Hyper-V's minimalist surface for Azure, etc.) explicitly reduce this surface by emulating fewer devices — the Firecracker VMM is a canonical example of "as small a hypervisor as we can get away with."
Why it matters for IaaS tenants¶
Most cloud users depend on the hypervisor boundary whether they think about it or not:
If your system runs in this type of cloud provider and you don't limit yourself to bare-metal instances, then your security model has to rely on the hypervisor security boundary to some extent anyway. (Figma, 2026)
Only bare-metal instances avoid this reliance — at the cost of losing the density that makes VMs economically attractive in the first place.
Defence-in-depth: don't rely on escape resistance alone¶
Even if the hypervisor boundary holds, a compromised workload inside a VM can still:
- make outbound network calls (exfiltration);
- reach other services using the VM's attached credentials;
- persist state for the VM's lifetime.
Therefore, hypervisor integrity is necessary but not sufficient. The corresponding VM-permissions control is patterns/minimize-vm-permissions — restrict network egress, scope IAM credentials minimally, bound VM lifetime and credential lifetime.
Sibling concept: container escape¶
A container escape is the same shape one isolation layer in — the boundary crossed is a kernel one (namespaces / cgroups / seccomp / LSM) rather than a hypervisor one. See concepts/container-escape. Figma's framing compares the two explicitly: "the attack surface of a hypervisor is usually smaller than for an OS kernel", which is why VM escapes are rarer in absolute number than container escapes for the same attack-opportunity window.
Seen in¶
- sources/2026-04-21-figma-server-side-sandboxing-virtual-machines — positions VM escape as one of the two questions any VM-sandboxing decision must answer (the other: what can a non-escaping compromise actually do with the VM's own permissions).