VMware Workstation VM Escape Bugs Also Hit Fusion

Broadcom has patched two critical bugs in VMware Workstation and Fusion that enable a VMware Workstation VM escape: an attacker who already controls a virtual machine can break out and run code on the host underneath it. When the guest-host boundary fails, so does the assumption that a compromised VM is contained.

Inside the VMware Workstation VM escape

CVE-2026-59346 is an integer-overflow flaw rated CVSS 9.3. CVE-2026-59347 is a stack-based buffer overflow in HGFS, the host-guest file-sharing component, rated 8.1. Both require local administrative access inside a VM, and both let the attacker execute code as the host’s VMX process.

That prerequisite matters, so let us be precise: this is not remote, unauthenticated RCE. An attacker first needs admin inside a guest. But in the real world that is a low bar. Malware routinely gets admin on a machine; the interesting question is what it can do next. These bugs answer: escape the VM and own the host, which is the one thing virtualization is supposed to prevent.

Why a guest-to-host escape is the bug that matters

Isolation is the whole value proposition of virtualization. We put untrusted things in VMs precisely so that a compromise stays inside the box. A working escape collapses that model in several everyday scenarios:

• Malware analysis and research: analysts detonate samples in a VM assuming the host is safe. An escape turns your analysis lab into the victim.
• Shared and multi-tenant hosts: one tenant breaking out reaches the host and, potentially, other tenants’ VMs.
• Developer and CI machines: a compromised build VM that can reach the host reaches everything the host can, including credentials and other projects.

That is the whole premise of hypervisor security, and hypervisor security vulnerabilities like these are dangerous exactly because that boundary is often the last line of defence. Validating whether those boundaries actually hold is the point of our internal network penetration testing and cloud penetration testing.

Our take

It is tempting to downgrade these because they need local admin first. Do not. Defence in depth means every layer counts, and the guest-host boundary is frequently the layer people quietly rely on without testing it. Ransomware crews and red teams both think in chains: phish a user, escalate to admin in the VM, then escape to the host to reach backups and domain infrastructure. A VM escape is the link that makes that chain lethal.

The type-2 hypervisors here (Workstation and Fusion) run on endpoints and lab machines rather than production clusters, which changes the risk profile but does not remove it. The same class of bug in a type-1 hypervisor would be a top-of-inbox emergency, and treating type-2 escapes as trivial is how a research laptop becomes the initial foothold.

What to do right now

• Patch VMware Workstation and Fusion to the fixed versions Broadcom shipped. This is the whole fix; apply it.
• Treat any VM where an attacker could gain admin as a potential path to the host, and segment host machines away from sensitive assets accordingly.
• Harden analysis and CI hosts specifically: they run the most untrusted code and are the likeliest escape targets.
• Fold your virtualization and hypervisor hosts into a vulnerability management cycle so the next boundary bug is caught quickly.
• Validate the real-world blast radius of a foothold with a red team assessment that assumes a compromised endpoint and works outward.

The bigger picture

Every abstraction we trust for isolation, VMs, containers, sandboxes, is one exploitable bug away from being just another process on the host. That is not a reason to abandon them; it is a reason to stop treating the boundary as magic. Patch it, monitor what runs inside it, and test whether it actually holds before an attacker does the testing for you.

We track offensive-security research closely, and for readers who want to go deeper on technique we recommend the penetration testing section at SecurityLab alongside our own write-ups.

Test your internal network