Researcher Stan S, publishing as 0xCyberstan, has published public exploit code for CVE-2026-59346, a VMXNET3 integer-overflow vulnerability that Broadcom patched on 3rd September 2026. Broadcom rates the issue 9.3 on CVSSv3 and fixed it in VMware Workstation and Fusion 26H1u1. The published proof of concept crashes the host’s vmware-vmx process from inside a guest but does not run code on the host.
How the VMXNET3 TSO bug works
The flaw resides in the TCP Segmentation Offload (TSO) processing path for VMXNET3, VMware’s paravirtualized network adapter. To size a buffer the host code multiplies the segment count by the per-segment space using 32-bit arithmetic. A large product can wrap around to a much smaller value, causing the host to allocate a heap buffer that is too small. The copy loop still iterates the original segment count, so guest-controlled data can overflow past the allocation and corrupt host memory.
What the public PoC does and requires
The published proof of concept is a Linux kernel module that requires administrative privileges inside the guest VM. It writes transmit descriptors directly into the VMXNET3 ring, bypassing the guest driver’s normal TSO checks, and rings the adapter’s memory-mapped I/O doorbell so the host processes them. The resulting out-of-bounds write hits unmapped memory, vmware-vmx crashes with a segmentation fault, and the VM powers off. The repository states explicitly that it makes no attempt at host code execution and warns that running the module can wipe unsaved guest state. The documented lab environment used VMware Workstation Pro 25.0.1 on an Ubuntu host with an Alpine Linux guest. The code is hosted in a public GitHub repository.
Advisories, ratings and prior fixes
Trend Micro’s Zero Day Initiative lists the issue as ZDI-26-647. The bug was reported to Broadcom on 28th August and ZDI issued its advisory on 9th September 2026. ZDI’s advisory verifies that the flaw can allow arbitrary code execution in the hypervisor context but notes that achieving that requires high-privilege code execution inside the guest. ZDI rated the issue 7.5, lower than Broadcom’s 9.3. Broadcom’s VMSA-2026-0007 advisory describes the problem as an integer-overflow vulnerability and lists Workstation and Fusion versions 25H2 and 26H1 as affected. Broadcom’s advisory lists no workaround.
The same TSO code path was patched previously for CVE-2025-41236: that fix bounded individual packet fields and their sum at 9,216 but did not validate the final multiplication product. According to the PoC repository, carefully chosen inputs that satisfy those earlier bounds can still trigger the new overflow.
Who is most exposed and recommended actions
Hosts running untrusted or semi-trusted guests on desktop virtualization products carry the most exposure because the exploit requires administrative access inside a VM. Broadcom frames the end state as code execution on the host—a full guest escape—while the published PoC currently produces a host process crash rather than a working host takeover. Teams that grant administrative rights inside guest VMs should treat the update as urgent. Broadcom names the host update to Workstation or Fusion 26H1u1 as the remedy.
Steps to reduce risk as stated in the advisory and repository:
– Upgrade Workstation or Fusion on the host to 26H1u1 or a later supported release.
– Check the host product version directly; guest OS updates do not change the vulnerable host code.
– Restrict administrative access inside guests, which the attack requires.
– Review whether sensitive desktop VMs need the VMXNET3 adapter.
Anyone reproducing the crash should do so only in an authorized, isolated lab because the module is built to kill the VM process.
