VMware Workstation and Fusion CVE-2026-59346 Can Reach the Host

CVE-2026-59346 is a critical VMware Workstation and Fusion vulnerability that can allow a privileged user inside a virtual machine to execute code on the host. The reported CVSS score is 9.3, and the attack path involves a VM configured with the VMXNET3 virtual network adapter. If you use Workstation or Fusion for untrusted workloads, this is a patch now issue.

I checked the security reporting against the details attributed to Broadcom before writing this. The scope needs care. The reports do not describe it as an unauthenticated remote attack against any VMware VM on the internet, and the attacker needs local administrative privileges inside the virtual machine, but the consequence can cross the isolation boundary into the host.

What is CVE-2026-59346?

CVE-2026-59346 is an integer overflow vulnerability in VMware Workstation and VMware Fusion that can lead to arbitrary code execution on the host under specific conditions. Broadcom's quoted advisory language says a malicious actor with local administrative privileges in a virtual machine using the VMXNET3 adapter may exploit the issue to execute code on the host.

That is serious, because the security boundary between guest and host is the whole point of desktop virtualization. A VM is useful for testing software, opening suspicious files, running development environments, or separating incompatible workloads because the user expects the guest to be contained.

A vulnerability that crosses that boundary changes the risk model. A compromised guest can no longer be treated as a disposable problem if the exploit can reach the system that owns the VM files, credentials, source code, SSH keys, browser sessions, and other local data.

Who is actually at risk from this VMware flaw?

Users of affected VMware Workstation and Fusion versions are at risk if an attacker can gain administrative control inside a VM that uses VMXNET3. The exact fixed versions should be taken from Broadcom's advisory for your product and platform before patching.

The most obvious risk is a workstation that intentionally runs untrusted or semi trusted guests. Security researchers, developers, malware analysts, IT administrators, and people testing downloaded appliances often use desktop hypervisors precisely because they want a boundary between the guest and their primary operating system.

A corporate laptop can also be exposed through a less dramatic path. Imagine a development VM with a large software stack, credentials, browser tools, and third party packages. If that VM is compromised through an unrelated application flaw, CVE-2026-59346 can become the next step in the chain.

For that reason, the first prerequisite alone is a poor guide to severity. "The attacker needs admin inside the VM" sounds reassuring until you remember that many VMs are designed to run code you do not fully trust.

Is CVE-2026-59346 a VM escape?

It is reasonable to describe the impact as a guest to host escape path because successful exploitation can move code execution from the VM to the host. The precise exploit mechanics should still be described using the vendor's wording instead of assuming it behaves like every previous VM escape.

This has consequences for incident response. If you discover that a vulnerable guest was compromised, the investigation should not automatically stop at that guest. The host may need to be treated as potentially affected until you can establish that the relevant exploit path was not used.

That can widen the response substantially. A developer laptop may have access to Git repositories, cloud consoles, VPN credentials, password managers, SSH keys, or internal documentation. The blast radius of host compromise is therefore often much larger than the VM itself.

For infrastructure teams used to server hypervisors, the same principle applies: isolation is a security control, and no security control is guaranteed to survive every vulnerability.

Why does VMXNET3 matter?

VMXNET3 matters because Broadcom's exploit condition specifically references a virtual machine using the VMXNET3 virtual network adapter. VMXNET3 is a paravirtualized VMware network device designed for performance and efficiency compared with emulated hardware.

A virtual device is code shared across a trust boundary. The guest interacts with the virtual hardware interface, while the hypervisor implements that device on the host side. Bugs in that implementation can therefore become a path from guest controlled input into privileged host code.

High performance paravirtualized devices like VMXNET3 are standard virtualization technology, and this bug is no reason to avoid them. It is a reason to treat hypervisor and virtual device updates as security maintenance instead of optional desktop software upgrades.

If your organization maintains standard VM templates, include virtual hardware and adapter configuration in the inventory. That makes it easier to determine exposure quickly when a vulnerability names a specific device model.

What should VMware Workstation and Fusion users do?

Update to the fixed VMware Workstation or Fusion release identified by Broadcom for your platform. Relying on a guest being "only a VM" is not a safety plan.

After patching, review which systems run high risk guests and whether those hosts contain valuable credentials or data. A lab VM on an isolated test computer carries a different risk from a security testing VM running on the same laptop used for production cloud administration.

If you suspect compromise before the patch was applied, preserve evidence before deleting the VM. Check host logs, endpoint detection alerts, unusual processes, persistence changes, new accounts, unexpected network connections, and credential use. The exact forensic process depends on the host operating system and your security tooling.

For long term hygiene, separate high risk testing from daily work. A dedicated machine or more strongly isolated environment reduces the value of a successful escape. Virtualization remains useful, but security improves when one layer of isolation is not carrying the entire risk.

The broader Mr.PlanB virtualization comparisons can help if this incident is prompting a platform review, but changing hypervisors will not replace patch discipline, since every major virtualization stack eventually receives security fixes.

Does this affect VMware vSphere or ESXi?

The published reports discussed here identify VMware Workstation and VMware Fusion, and they do not describe a blanket vulnerability across every VMware product. Check Broadcom's official advisory before expanding the affected product list.

Keeping that product boundary straight helps because VMware has several virtualization platforms with different code paths, deployment models, and security advisories. A CVE affecting a desktop product may share components with other products, but that does not automatically make them vulnerable.

For administrators dealing with a wider VMware estate, keep product inventory precise. During vulnerability response, "We run VMware" tells you very little. You need product, version, build, operating system, and relevant virtual hardware details.

If the vulnerability is part of a larger reassessment of your VMware environment, the article on translating vMotion expectations during a Proxmox move is a useful reminder that platform changes have operational consequences beyond security patches.

Should this change how you use virtual machines?

It should change how much trust you place in a single isolation boundary. Virtual machines remain one of the most useful ways to separate workloads, but no VM is an impenetrable sandbox.

For routine development, the practical response is simple: patch quickly, keep the host protected, and avoid mixing the highest risk guest workloads with the most sensitive host activity when you can separate them.

For malware analysis or hostile code, I would go further. Use dedicated hardware or an environment designed for adversarial workloads, restrict network access, minimize credentials on the host, and assume that a sufficiently valuable target may eventually encounter an escape vulnerability.

Abandoning virtualization because one escape exists would be an overreaction. What CVE-2026-59346 shows is that isolation controls need maintenance and layers, so patch the hypervisor, reduce what the host is worth to an attacker, and design the lab so one failure does not become total compromise.