Broadcom patches two VMware Workstation and Fusion guest escape flaws rated 9.3 and 8.1

What Broadcom fixed

Broadcom has patched two vulnerabilities in VMware Workstation and Fusion that can turn administrative access inside a virtual machine into code execution on the host machine itself. According to a dev.to analysis of the advisory, Broadcom published the notice on 7 October 2026, lists Workstation and Fusion 25H2 and 26H1 as affected, and resolves both defects in build 26H1u1.

The more severe of the two, CVE-2026-59346, is an integer overflow carrying a CVSS score of 9.3. Exploiting it requires a malicious actor who already holds local administrative privileges on a virtual machine configured with the VMXNET3 virtual network adapter. The second, CVE-2026-59347, is a stack-based buffer overflow in HGFS rated 8.1, with the same prerequisite of local administrative privileges inside the guest, and it results in code execution as the VMX process running on the host.

Both attack vectors are local, so the attacker must begin inside the guest. The dev.to post argues that this prerequisite is exactly why a bug in a desktop hypervisor belongs in corporate patch management rather than a personal-device policy.

The precondition is routine in build environments

The write-up points out that these products are not confined to individual laptops. Workstation, it notes, also runs on build servers and test hosts where several virtual machines operate under a single account, while Fusion on Apple hardware is used by platform teams to mirror production components locally, often with credentials that reach real systems.

In both settings, the advisory's precondition — administrator rights inside the guest — is satisfied by design. Build agents normally run as administrator, and a developer's test virtual machine typically carries the credentials that developer actually uses. So the question these vulnerabilities raise is not whether a guest has been compromised, but whether the isolation boundary between guest and host actually holds.

How the escapes work

According to the analysis, both flaws follow the familiar pattern of a hypervisor escape: a device emulation layer on the host parses input that a privileged guest controls, and a memory-safety defect in that parser crosses the boundary.

In the HGFS case, the shared-folders mechanism is the channel through which host and guest exchange files; guest-side code that reaches it reaches host-side parsing code, and a stack overflow in that parser amounts to a host compromise. In the VMXNET3 case, that adapter is the paravirtualised network adapter Windows guests use by default, and a guest administrator controls the guest's own network driver — the position from which the integer overflow can be triggered. The VMX process is a host-side component, so code execution there is code execution on the host.

Configurations and patch checks

The dev.to post suggests concrete questions for assessing exposure: whether HGFS shared folders are enabled but unused, which network adapter each guest uses, who holds administrative access inside each guest, and whether the host is domain-joined or holds credentials for production systems. A host running five virtual machines for different teams is a host several people can influence, and a developer machine holding an SSH key to production cannot be treated as a contained, single-device asset.

Verifying the fix is a version check rather than a test: the About dialog in both products reports the build, and the advisory names the fixed build per product. For managed fleets, an inventory query on the installed version yields the relevant list — though the post cautions that desktop applications often fall outside server-focused patch reporting, and laptop hypervisors are the textbook case. Hosts where Workstation was installed from a vendor download and updated only when a notification appeared cannot have their patch status asserted at all.

The piece also raises an incident-response concern. The VMX process's log, vmware.log, records device activity for each virtual machine and sits alongside the VM's files on the compromised host. On a shared workstation, those logs are usually not collected anywhere the guest's operator cannot reach, so a host compromise may surface as unexplained host behaviour with no usable record.

Why it matters

These are not remote exploits, and that is precisely the point. In enterprise build and development environments, the administrative access an attacker needs inside the guest is the normal state rather than the exception, which converts a workstation-grade bug into a guest-to-host escape route on shared infrastructure. Any organisation running Workstation or Fusion on build servers, test hosts or developer machines with production credentials should inventory where these products are installed, move affected hosts to 26H1u1, and check whether the logs that would reveal an escape are stored somewhere a guest cannot touch.