Researcher Stan S, publishing as 0xCyberstan, has released public exploit code for CVE-2026-59346, a VMware VMXNET3 flaw Broadcom patched on 3rd september, 2026. The proof of concept crashes the host’s vmware-vmx process from inside a guest but does not run code on the host.
The Brief
- Broadcom rates CVE-2026-59346 at 9.3 on CVSSv3 and fixed it in VMware Workstation and Fusion 26H1u1.
- The exploit code runs as a Linux kernel module and needs administrative privileges inside the guest VM.
- The PoC crashes vmware-vmx with a segmentation fault, which powers off the guest without running attacker code.
- Workstation and Fusion versions 25H2 and 26H1 are affected. Broadcom lists no workaround.
A second hole in the same TSO path
VMXNET3 is VMware’s paravirtualized network adapter, the virtual NIC most modern guests use. Broadcom’s VMSA-2026-0007 advisory states the problem plainly: “VMware Workstation and Fusion contain an integer-overflow vulnerability.“
The bug sits in TCP Segmentation Offload (TSO), which splits a large guest packet into smaller segments. That work happens inside vmware-vmx on the host, not in the guest.
To size the buffer, the code multiplies the segment count by the space each segment needs. The multiplication runs in 32 bits. A big enough product wraps around to a small number, and the host allocates a buffer far too small. The copy loop still walks the original segment count, so guest-controlled data spills past the end of the heap allocation.
‼️ PoC Released for Critical VMware VMXNET3 Flaw Enabling Guest-to-Host Code Execution Details: https://t.co/qcZYrlOPks A public proof of concept is now available for CVE-2026-59346, a critical integer overflow flaw in VMware’s VMXNET3 virtual network adapter. The flaw can allow an attacker with administrative access inside a guest virtual machine to execute code on the host. However, the published PoC shows a host process crash, not a working code-execution exploit. Its advisory lists Workstation and Fusion versions 25H2 and 26H1 as affected. The vendor security advisory states that no workaround is available. The flaw sits in the TCP Segmentation Offload, or TSO, processing path within the host’s VMware-VMX process. TSO splits a large network packet into smaller segments. #cybersecuritynews
— Cyber Security News (@The_Cyber_News) October 8, 2026
This code path has been patched before, for CVE-2025-41236. According to the PoC repository, that fix capped individual packet fields and their sum at 9,216. It never checked the final product. Inputs that clear every limit can still overflow.
The public code stops at a crash
The kernel module writes transmit descriptors straight into the VMXNET3 ring and skips the guest driver’s normal TSO checks. It then rings the adapter’s memory-mapped I/O doorbell so the host picks them up. The out-of-bounds write hits unmapped memory, vmware-vmx dies, and the VM goes down with it.
The repository says outright that it makes no attempt at code execution. It warns that testing can wipe unsaved guest state. Its documented lab used VMware Workstation Pro 25.0.1 on an Ubuntu host with an Alpine Linux guest.
The code lives in a public GitHub repository. That gives defenders a concrete reproduction case for checking patch status, and it gives attackers a tested starting point for the harder step.
Trend Micro’s Zero Day Initiative has it as ZDI-26-647. Bug was reported to Broadcom on 28th Aug. ZDI advisory was issued on 9th Sep 2026. It does verify that it does allow arbitrary code execution in the hypervisor context. But first you need to have high priv code execution in the guest.
ZDI rated it at 7.5. Which is significantly lower than what Broadcom did. In the end both the rating don’t change the fact that it is a memory corruption and crash. No host takeover.
The question is. Has anyone in private already converted this write to a guest to host escape? How many hosts are there which are still on 25H2 or 26H1. Because people have only patched the guest and not the hypervisor.
Who should move first?
Hosts running untrusted or semi-trusted guests on desktop virtualization carry the most exposure, since the attack starts with admin rights inside a VM. Broadcom’s advisory frames the end state as code execution on the host, a full escape from the guest sandbox. Teams that hand users administrative access inside guest VMs should treat the update as urgent. These steps help reduce risk:
- Upgrade Workstation or Fusion on the host to 26H1u1 or a later supported release.
- Check the host product version directly. Guest operating system updates don’t touch the vulnerable code.
- Restrict administrative access inside guests, which the attack requires.
- Review whether sensitive desktop VMs need the VMXNET3 adapter at all.
The earlier patch bounded each input but not the result of multiplying them. That gap is the whole story here. Broadcom’s response matrix names one remedy, the host update to 26H1u1. Anyone reproducing the crash should do it only in an authorized, isolated lab, because the module is built to kill the VM process.
