CVE-2026-59346 lets a VM admin run code on the VMware Workstation or Fusion host
Broadcom patched two flaws in VMware Workstation and Fusion: CVE-2026-59346 (CVSS 9.3) and CVE-2026-59347 both let a virtual machine administrator execute code on the host machine. Update to 26H1u1 now — no workaround exists.
September 5, 2026. Broadcom patches two flaws in VMware Workstation and VMware Fusion. CVE-2026-59346 tops out at CVSS 9.3; CVE-2026-59347 at CVSS 8.1. Both start from the same premise: an attacker who already holds administrative privileges inside a virtual machine can break out and run code on the host machine. Why it matters: that guest-to-host boundary is the very thing a desktop hypervisor is supposed to guarantee.
Two flaws, one broken contract
CVE-2026-59346 is an integer overflow. An attacker with local administrative privileges on a virtual machine fitted with a VMXNET3 virtual network adapter can exploit it to execute code on the host. The overflow sits in the data-plane networking path — VMXNET3 is the default virtual adapter on modern VMware VMs. Researchers @h4urek, @cameudis, and Stan S are credited with the discovery.
CVE-2026-59347 is a stack-based buffer overflow in HGFS, the Host-Guest File System — the component behind shared folders and drag-and-drop between host and guest. Exploited, it runs code as the VM’s VMX process, meaning with the privileges of the process that orchestrates the VM on the host side. Yeonghyeon Choi and Tianchu Chen of Tencent Xuanwu Lab are credited.
Both flaws affect VMware Workstation and VMware Fusion versions 25H2 and 26H1. Broadcom is categorical: there is no workaround. The fix ships in Workstation 26H1u1 and Fusion 26H1u1.
The precondition that changes how you read the CVSS
A CVSS 9.3 that requires local, elevated-privilege access deserves a careful read. The attacker does not win the VM through this flaw — they already own it. What CVE-2026-59346 and CVE-2026-59347 provide is the way out: escalation from the virtual machine to the host, then from the host to the rest of the machine, the other VMs, and the corporate network.
That is exactly the scenario feared across developer fleets. A development workstation runs VMs with local admin rights by default, HGFS shared folders switched on for productivity, and often source-code keys mounted inside. The initial compromise — via phishing, a weak configuration, or another bug — stops being a wall and becomes a mere prerequisite. Broadcom says as much: those privileges are obtained “through a separate compromise, via phishing or exploiting weak user configurations.”
VMXNET3 and HGFS, the two exit doors
There is nothing accidental about these two surfaces. VMXNET3 is the paravirtualized network adapter VMware recommends for its VMs: it exchanges packets directly between guest and host, bypassing part of the emulation layers. It is a fast code path, but also a deep one — an overflow there reaches host structures that the guest network should never touch.
HGFS, for its part, is the shared folders component: it lets a guest read and write host directories. It is a boundary that, by nature, crosses the line between the two worlds. A buffer overflow in that component does not strike an isolated device — it strikes the very mechanism that lets the guest reach toward the host.
The result is the same in both cases: code execution on the host side, directly or through the VMX process — the process that orchestrates the VM and carries its privileges. Running code as VMX is most of the way to full machine compromise.
In practice, an escape is not just about “breaking” the host machine. It serves mainly as a pivot: once on the host, the attacker reaches the other VMs running there, the credentials stored in developer tools, and from there the internal network. On a development workstation, the host is often joined to the corporate domain and holds VPN or SSH access into production. The escape turns a localized incident into lateral compromise — exactly what CVE-2026-59346 and CVE-2026-59347 enable.
Why VMware products remain attack magnets
VMware stays a prime target. Last month, attackers actively exploited two vCenter flaws, CVE-2026-59309 and CVE-2026-59310, the latter suspected of being weaponized by a China-nexus APT. Check Point counted 361 victim IP addresses across 47 countries, with activity starting five days after public disclosure.
The difference here is scope. Workstation and Fusion are type-2 hypervisors — desktop software, not the data-center pillars that vCenter and ESXi are. But the trust model is identical, and it applies to a far larger fleet: every development machine becomes a potential attack surface the moment it hosts privileged VMs.
How to read a type-2 hypervisor advisory
Two practical points follow from this advisory that are easy to miss.
First, the versioning. Broadcom ships the fix in 26H1u1, which means 25H2 users get no dedicated patch — they must migrate to 26H1u1, turning this into a version migration to plan with VM backups and a maintenance window, rather than a silent patch.
Second, the target profile. Workstation and Fusion are often treated as throwaway tools, patched last because they are “just” developer software. That is precisely backwards: they sit on the machines that hold the most credentials and the broadest production access. Treat the host as a first-class security asset, and treat shared folders and VMXNET3 as the escape surfaces they are.
Finally, monitor what you cannot simply disable. Log shared-folder mounts and watch the VMX process for writes outside its folders — a guest reaching past its shared folders is the tell of an escape attempt, and it is far cheaper to catch it there than to clean up after a full host compromise. None of this is theoretical: CVE-2026-59346 and CVE-2026-59347 are the latest in a line that has made VMware products the most-targeted virtualization software on the planet.
What to do
- Update immediately. Apply Workstation 26H1u1 or Fusion 26H1u1. No workaround exists, so there is nothing to configure to “mitigate” in the meantime.
- Treat the host as a target. It carries the residual risk once the VM is compromised: harden it, segment the VM network, and limit the admin rights granted to virtual machines.
- Audit shared folders. HGFS is at the heart of CVE-2026-59347: disable shared folders and drag-and-drop wherever they are not essential.
Those three moves do not just protect against these two CVEs — they shrink the surface of the whole VM-escape class.
The paradox is this: we harden servers and patch vCenter, but we often forget that the developer’s machine — with its stack of local VMs — is itself an infrastructure link. CVE-2026-59346 and CVE-2026-59347 are a reminder, at a moment when those machines are more connected to production than ever.
Verdict
If you run VMs under VMware Workstation or Fusion, update to 26H1u1 now — neither flaw has a workaround, and the exploitation precondition (an admin inside the VM) is trivial on a development machine.
If you maintain a fleet of development workstations, harden the host and disable unnecessary HGFS shared folders: that is where the residual risk lives once the VM is compromised.
If your VMs are ephemeral, prefer sandboxes or a type-1 hypervisor on a dedicated host over a desktop hypervisor shared across multiple uses.