VM Escape via VMXNET3: Critical VMware Workstation/Fusion Flaw Patched

Broadcom's September 2026 security advisory for VMware Workstation and Fusion (VMSA-2026-0007) patches two vulnerabilities that both break the isolation boundary desktop virtualization is supposed to guarantee. The headline issue, CVE-2026-59346, is a critical integer-overflow flaw in the VMXNET3 virtual network adapter with a CVSS score of 9.3 — a local attacker with administrative privileges inside a VM can use it to execute arbitrary code on the host.

What Broadcom disclosed

The advisory covers two distinct bugs. CVE-2026-59346 is the integer overflow in the VMXNET3 adapter; Broadcom's own advisory language is blunt about the impact: "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." A second, less severe issue, CVE-2026-59347 (CVSS 8.1), is a stack-based buffer overflow in HGFS (the shared-folder mechanism), reported separately by Tencent's Xuanwu Lab, which allows code execution as the host-side VMX process. Both affect Workstation and Fusion versions 25H2 and 26H1, and both are fixed in Workstation 26H1u1 and Fusion 26H1u1. Broadcom states there is no workaround for either issue.

Why this is a VM-escape bug, not just a VM bug

Most vulnerabilities in a hypervisor's guest-facing code compromise the guest. This one is different in kind: exploitation crosses from inside the VM to the physical machine hosting it. For a company running ESXi in a data center, that would be a five-alarm event. Workstation and Fusion sit on individual developer laptops and analyst workstations instead — machines that are frequently used to open VMs from untrusted sources: vendor-supplied appliances, downloaded CTF images, malware samples inside an "isolated" analysis VM, or a contractor's development environment. Any of those scenarios already grants local admin inside the guest, which is exactly the prerequisite this bug needs.

Who's exposed, and what to do about it

The exploitation bar — local admin inside a VMXNET3-configured guest — means this is not a remote, unauthenticated bug, and no public exploit has been documented yet. But desktop virtualization installs are usually far less centrally managed than a data-center hypervisor fleet, so patch coverage tends to lag.

• Inventory every machine running VMware Workstation or Fusion — these are commonly unmanaged installs on individual developer and security-analyst laptops, not tracked alongside server-side ESXi/vSphere assets.
• Update to Workstation 26H1u1 or Fusion 26H1u1; Broadcom has confirmed there is no mitigating workaround for either CVE.
• Prioritize hosts used to run VMs from external or untrusted sources — malware sandboxes, vendor appliances, CTF/training images, contractor environments — since these already satisfy the local-admin-in-guest precondition.
• Treat this as a reminder that desktop hypervisors are part of your attack surface, not just server-side virtualization; asset inventories that stop at ESXi/vSphere will miss it.

The bottom line

Neither CVE is wormable or remotely triggerable, so this isn't a drop-everything internet-facing emergency. But a 9.3 that turns "I have admin inside this one VM" into "I have code execution on the physical machine" deserves the same urgency as any host-compromise finding in a penetration test — because that's functionally what it is.