Your Virtual Machine Can Escape: VMware Just Patched Two Host-Takeover Flaws

The more serious flaw sits in the VMXNET3 virtual network adapter and carries a maximum CVSS score of 9.3. The second affects VMware’s shared-folder implementation, HGFS, and scores 8.1. Both affect Workstation and Fusion 25H2 and 26H1. Broadcom says customers should move to 26H1u1, and it lists no workaround.

This is not an internet-facing, no-click takeover. The attacker needs local administrative control inside a virtual machine. That prerequisite matters, but it does not make the problem academic. Malware analysts, developers, security researchers and organisations running untrusted workloads often rely on the guest-to-host boundary precisely because they expect the guest to be disposable and contained.

The critical flaw crosses through the virtual network adapter

The first vulnerability is an integer overflow in VMXNET3, VMware’s paravirtualised network adapter. According to Broadcom, a malicious actor with local administrative privileges in a virtual machine configured with VMXNET3 may exploit the flaw to execute code on the host.

That is the significant boundary crossing. Control of a guest normally gives the attacker authority over the guest operating system, its applications and its virtual disk. It should not confer authority over the hypervisor process or the machine hosting other workloads. A successful escape can put host files, credentials, developer tooling and neighbouring virtual machines within reach.

Broadcom rates the issue critical. Its CVSS vector reflects local access from the guest, low attack complexity, no additional privileges beyond the assumed guest-administrator position, no user interaction and a changed security scope. In plain terms, the attacker begins in one security boundary and can affect another.

The shared-folder flaw reaches the VMX process

The second vulnerability is a stack-based buffer overflow in HGFS. Shared folders deliberately connect the guest and host file systems, making them a sensitive part of the virtualisation boundary.

Broadcom says an administrator inside the guest may exploit this issue to execute code as the virtual machine’s VMX process on the host. The company rates it important rather than critical because the attack complexity is high, but the potential confidentiality, integrity and availability impact remains high.

The advisory does not publish an exploit, reproduction steps or a temporary mitigation. It also does not report known malicious exploitation. The two vulnerabilities were privately reported by independent researchers, including secsys lab, TrendAI Zero Day Initiative and Tencent Xuanwu Lab contributors.

Who is actually exposed?

Desktop hypervisors are common on developer laptops and security workstations, where virtual machines may handle downloaded software, malware samples, test images and third-party appliances. Those systems can also contain source code, SSH keys, cloud credentials, browser sessions and access to corporate networks.

The risk is therefore shaped by what the guest is allowed to run and what the host can reach. A workstation used only for trusted internal development does not have the same exposure as a malware-analysis laptop that routinely opens hostile samples. A shared jump host running virtual machines for several users presents a different risk again.

Guest administrator is a prerequisite, not a safety guarantee

It is tempting to dismiss a guest-to-host vulnerability when exploitation begins with administrator privileges inside the guest. That misses why virtual machines are used. Many workflows assume the guest can become fully compromised without endangering the host.

An attacker might reach that starting position through a malicious installer, a vulnerable service inside the VM, stolen credentials or a deliberately hostile sample opened for analysis. Once administrator access is obtained, the VMware vulnerabilities can become a second stage that changes a contained incident into a host compromise.

This distinction is especially important for sandboxing. A sandbox is useful because the code inside it is not trusted. Requiring control of that untrusted environment is not a meaningful reduction when control of the environment is the scenario the sandbox was created to survive.

Patch before relying on configuration changes

Broadcom lists no workaround for either flaw. Administrators should inventory Workstation and Fusion installations, identify systems still running 25H2 or the original 26H1 release and upgrade them to 26H1u1.

Where immediate patching is impossible, reducing exposure is still useful even though it is not a vendor-supported fix. Avoid running untrusted guests, isolate high-risk analysis systems from sensitive networks and credentials, and reassess whether shared folders are necessary. These steps reduce opportunities and consequences, but they do not replace the update.

Security teams should also treat unusual activity from VMware VMX processes as a host-level signal. A process associated with a virtual machine spawning unexpected tools, touching unrelated user data or making abnormal network connections deserves investigation. An escape can make the host appear to be the origin of actions that actually began in a compromised guest.

The containment boundary is the asset

The important question is not whether an attacker already controlled a virtual machine. It is what that control was supposed to mean. In a properly isolated design, the answer should be that the attacker controls one disposable guest and nothing more.

These VMware flaws show how a virtual device and a convenience feature can become routes across that boundary. Updating to 26H1u1 protects more than a desktop application. It restores the containment guarantee on which the entire workflow depends.

Sources and further reading

• Broadcom VMSA-2026-0007 security advisory, issued 3 September 2026. Broadcom provided no publication time.
• VMware Workstation Pro 26H1u1 release notes.
• VMware Fusion 26H1u1 release notes.