Broadcom has patched two vulnerabilities in VMware Workstation and VMware Fusion, both of which allow code execution on the host from inside a guest virtual machine.

CVE-2026-59346 — CVSS 9.3, an integer overflow reached through the VMXNET3 virtual network adapter. In VMware's words, "a malicious actor with local administrative privileges on a virtual machine with VMXNET3 virtual network adapter may exploit this issue to execute code on the host."

CVE-2026-59347 — CVSS 8.1, a stack-based buffer overflow in HGFS, the Host Guest File System component that implements shared folders.

Affected: Workstation and Fusion 25H2 and 26H1. Fixed in 26H1u1 for both products. There are no workarounds.

What a guest-to-host escape actually breaks

The point of a virtual machine is the boundary. Whatever happens inside the guest is supposed to stay inside the guest, and that assumption is what makes it safe to open a suspicious file in a VM, run untrusted code in a sandbox, or give a contractor a disposable environment.

An escape does not weaken that boundary. It removes it. Code that was contained is now running on the machine that was doing the containing, with access to everything the host user has — including, very often, the other virtual machines.

The precondition, and why it is weaker than it sounds

Both flaws require local administrative privileges inside the guest.

That sounds like a serious constraint and in many contexts it is. It also happens to be the normal state of affairs in exactly the situations where people rely on VM isolation most:

  • Malware analysis. The sample is administrator inside the VM by design, because that is what you are trying to observe.
  • Developer sandboxes. People run their own VM as administrator without thinking about it.
  • CI and build runners. Ephemeral VMs where the job has full rights over its own environment.
  • Disposable browsing or testing environments, where the whole point is to do risky things with elevated rights somewhere that does not matter.

In every one of those, "attacker has admin in the guest" is not a barrier the attacker has to overcome. It is the starting position the workflow hands them.

Anyone reading the precondition as reassurance should check which of those four they are actually doing.

The two components are both old surface area

VMXNET3 and HGFS are the paravirtualised network adapter and the shared folders implementation. Both exist to make the guest faster and more convenient by giving it a more direct path to host resources than strict emulation would.

That convenience is the attack surface. Every VM escape of the past decade has come out of the same place — the parts deliberately built to be less isolated. The vCenter flaw we covered earlier sat in different code with the same underlying trade.

What to do

  • Update to Workstation 26H1u1 or Fusion 26H1u1. There is no workaround, so this is the only option.
  • If you cannot patch immediately, remove the reachable surface. Disabling shared folders takes HGFS out of play. Changing the network adapter type away from VMXNET3 takes the other out. Both cost functionality and both are better than nothing.
  • Prioritise malware analysis hosts first. If you detonate samples in Workstation, the sample already has the precondition.
  • Then prioritise anything multi-tenant. A build runner escaping to its host reaches every other job on that host.
  • Stop treating a VM as a security boundary you can be careless with. It is a good boundary. It is not a guarantee, and this is the second reminder this month.

What is not established

  • Whether either flaw has been exploited. No evidence of in-the-wild exploitation has been published.
  • Whether public proof-of-concept code exists.
  • Exploitation complexity. Neither advisory describes how hard the overflows are to drive reliably.
  • Whether ESXi or other VMware products share the affected code. Only Workstation and Fusion are named.