PoC Released for Critical VMware VMXNET3 Integer Overflow Flaw Enabling Guest-to-Host Code Execution (CVE-2026-59346)

Public proof-of-concept code demonstrates memory corruption in VMware’s virtual network adapter, a hypervisor escape vector rated 9.3 on the CVSSv3 scale. No workaround exists (other than patching).

A researcher using the handle 0xCyberstan has published a public proof-of-concept exploit for CVE-2026-59346, an integer overflow in VMware’s VMXNET3 virtual network adapter. Broadcom rates the flaw 9.3 on CVSSv3. An attacker with administrative privileges inside a guest virtual machine could use it to execute arbitrary code on the host. The bug sits in the TCP Segmentation Offload (TSO) processing path of the host-side VMware-VMX process. The released PoC reliably crashes the host process and stops there. It is not a working code-execution chain, though the Zero Day Initiative has confirmed the weakness is enough to support arbitrary code execution in the hypervisor context.

The timing matters for anyone running virtualization in production. VMware Workstation and Fusion are standard tools in development environments, security research labs, and enterprise desktop virtualization, and VMXNET3 is present in nearly every VM configured on them. A guest-to-host primitive in that component is exactly what threat actors hunt for. Broadcom fixed the bug in 26H1u1 on September 3, 2026, but public exploit code now shortens the remediation window for organizations still running the affected 25H2 and 26H1 builds, especially in shared environments.

How CVE-2026-59346 works: a 32-bit multiplication that breaks the hypervisor boundary

VMXNET3 is VMware’s paravirtualized network interface. It gives guest operating systems near-native networking performance by skipping most of the emulation overhead of legacy virtual NICs. The guest driver fills shared memory rings and descriptor structures, and the host-side VMware-VMX process reads them.

When a guest sends a large TCP segment during a bulk transfer, a stream, or ordinary web traffic, it can use TCP Segmentation Offload. Instead of cutting a 64-kilobyte payload into MTU-sized packets in the guest kernel, the guest hands the host one large buffer and the host does the segmentation. In VMware’s architecture that work happens inside VMware-VMX on the host. So the guest is asking the host to allocate memory and copy data based on parameters the guest controls.

The vulnerable code works out how much memory to allocate for the segmented output by multiplying the number of segments by the size of each segment, using a 32-bit integer operation. Normally the product fits. But a crafted set of transmit descriptors can supply values that each pass validation and still multiply to more than 2^32 minus one. The result wraps around to a much smaller number than the real memory requirement.

The host then asks the allocator for that truncated size and gets back a buffer far smaller than the copy loop expects. The loop still runs over the original, guest-derived segment count. Guest-controlled packet data is written sequentially into the undersized buffer and keeps going past its end, into adjacent heap memory or, in the PoC, into unmapped address space, which triggers a segmentation fault.

That is a textbook heap overflow caused by an integer overflow in a size calculation. It is especially bad here because VMware-VMX runs with elevated privileges on the host and manages the VM’s hardware emulation state. Corruption in that process can in principle be shaped into control-flow hijacking by overwriting function pointers, vtable entries, or return addresses, which would give code execution outside the guest’s isolation boundary.

Relationship to CVE-2025-41236: an incomplete patch revisited

0xCyberstan’s write-up ties CVE-2026-59346 to the same TSO path Broadcom patched for CVE-2025-41236. That earlier fix added bounds checks capping individual packet descriptor fields, and their cumulative sum, at 9,216 bytes. The goal was to prevent oversized allocations and shrink the input space available to a malicious guest.

The fix checked the individual inputs and their sum, but never checked the product. An attacker can pick segment counts and per-segment sizes that are each under 9,216 bytes, with a sum that is also in bounds, and still overflow the 32-bit integer when the two are multiplied. The earlier patch handled addition-based overflows and missed multiplication-based ones. Vendors often patch the exact crash they observed without auditing the surrounding arithmetic for every overflow class, and this looks like another instance.

For defenders, the consequence is that organizations that applied the CVE-2025-41236 patch and treated the VMXNET3 TSO path as hardened were still exposed. The 26H1u1 fix presumably validates the multiplication result before it reaches the allocator, but Broadcom has not published code-level details beyond the advisory, so that part is inference.

The proof-of-concept: how 0xCyberstan crashes the host process

The PoC is hosted on GitHub under the 0xCyberstan account and is written as a Linux kernel module that runs inside a guest VM with a VMXNET3 adapter. The implementation choice is worth understanding. Pushing malicious traffic through the guest’s normal TCP/IP stack would subject it to the guest kernel’s own segmentation logic and driver-level sanity checks. The module avoids that by writing transmit descriptors straight into the VMXNET3 shared memory rings.

That bypasses the guest driver’s TSO handling entirely, so the crafted values reach VMware-VMX without being normalized, split, or rejected along the way. The descriptors specify segment counts and sizes that each satisfy the CVE-2025-41236 bounds checks but overflow the 32-bit multiplication. Once they are committed to the transmit ring, the module triggers the host to process them, and the vulnerable segmentation routine runs.

The repository documents the outcome: a segmentation fault in vmware-vmx. The out-of-bounds write reaches unmapped memory, the operating system delivers SIGSEGV, the process dies, and the VM powers off immediately. The researcher’s test environment was VMware Workstation Pro 25.0.1 on an Ubuntu host with an Alpine Linux guest, and the repository warns that running the PoC destroys unsaved guest state.

What the PoC does not do matters just as much. It does not achieve controlled code execution on the host. The out-of-bounds write is not aimed at any specific target; it runs on until it hits unmapped pages. Turning the crash into reliable code execution would take heap grooming to place attacker-controlled data at predictable offsets, a suitable overwrite target such as a function pointer on the VMware-VMX heap, and a way past host-side mitigations like ASLR, stack canaries, and Control Flow Integrity. The Zero Day Initiative’s advisory, published September 9, 2026, confirms the vulnerability class supports that kind of exploitation in principle. The public artifact stops at denial of service.

CVSS scoring: Broadcom’s 9.3 versus ZDI’s 7.5

Broadcom scores the flaw 9.3 and ZDI scores it 7.5. Both describe the same bug and weigh different things.

Broadcom’s number assumes the worst case, where exploitation yields arbitrary code execution on the host and fully breaks guest isolation. The vector probably assumes low attack complexity, on the theory that a determined attacker with guest admin access can build the heap layout code execution requires, even though the public PoC has not shown it. The scope metric reflects the guest-to-host boundary crossing, which raises the impact rating.

ZDI’s 7.5 appears to reflect what has actually been demonstrated: a host process crash. It may also give weight to the guest admin prerequisite and to the extra work of getting from a linear overflow to controlled execution. I would not call either score wrong. For prioritizing patches, I would work from the 9.3, because the distance between a crash PoC and a code-execution exploit is exploit engineering effort, not an architectural barrier.

Affected products, patch availability, and no workaround

Broadcom’s advisory, released with the 26H1u1 update on September 3, 2026, lists these affected products:

• VMware Workstation Pro and Player, versions 25H2 and 26H1
• VMware Fusion, versions 25H2 and 26H1

The fix ships only in 26H1u1 or later supported releases. The advisory states that no workaround exists: no configuration change, registry edit, or adapter swap removes the vulnerable code path while keeping VMXNET3. Replacing VMXNET3 with an emulated adapter such as the Intel E1000 or the legacy vlance adapter would remove this particular attack surface, but it changes how the VM behaves and costs performance. Broadcom does not endorse it as a mitigation.

The patch is a host-side update. Updating the guest OS, upgrading VMware Tools, or applying security patches inside the VM does nothing for this vulnerability, because the flawed code runs in the host’s VMware-VMX process. Broadcom’s response matrix lists host product updates as the remedy. If you manage a fleet of VMs through central tooling, make sure the Workstation or Fusion installation on every host is updated, not only the guest images deployed on top of them.

Exploitation prerequisites and realistic threat scenarios

Exploitation requires administrative access inside the guest. An attacker cannot trigger the flaw by sending packets to a VM from outside. They need control of the guest kernel, or root or administrator rights sufficient to load a kernel module or manipulate transmit descriptors at the driver level.

That limits who can use it, but it does not make the bug theoretical. In multi-tenant virtual desktop infrastructure, a compromised or malicious tenant with admin rights in their VM could break out to the host and possibly pivot to other tenants’ VMs. In malware analysis sandboxes that run untrusted code in VMs with VMXNET3 adapters, a sophisticated sample could use the flaw to escape. On shared development hosts running VMware Workstation, a compromised dev VM could become a foothold for moving to the host and then to other VMs and network resources.

Guest compromise is the starting condition for a large class of real attacks, and a guest-to-host escalation turns a contained breach into an infrastructure-level one. Nation-state and APT groups have long invested in hypervisor escape primitives for exactly that reason.

Why VMXNET3 matters in VMware’s architecture

VMXNET3 is hardly an obscure option. It is the default recommended virtual network interface for modern guests across VMware’s product line, and it runs on Windows, Linux, FreeBSD, and other platforms. It supports multi-queue transmit and receive, jumbo frames, hardware checksum offload, and TCP Segmentation Offload, the feature at the center of this bug.

Because it is paravirtualized, the guest driver and the host backend share memory structures for speed. That removes the overhead of emulating a physical NIC and creates a trust boundary: the host has to parse and act on structures the guest populates. Every field in them, including descriptor counts, segment sizes, buffer addresses, and flags, is guest-controlled input that the host must validate before use. CVE-2025-41236 and now CVE-2026-59346 show how hard it is to validate every arithmetic operation on every guest-supplied field across a complex offload pipeline.

VMware-VMX is the per-VM monitor process on the host. Each running VM has its own vmware-vmx process handling CPU virtualization, memory management, device emulation, and I/O. Compromising it gives an attacker the privileges of the account running Workstation or Fusion, typically a local user with broad filesystem access and, in some configurations, root or SYSTEM.

What the PoC repository offers defenders

The repository is useful to both sides. For offensive researchers it is a concrete reproduction case that confirms the flaw is real and triggerable. For defenders it is a testable artifact: in an isolated lab, a security team can confirm that patched installations no longer crash, and check whether their endpoint monitoring, process crash alerting, and hypervisor integrity checks would catch an attempt.

The repository warns that running the PoC crashes the target VM and destroys unsaved guest state, and it documents the Workstation Pro 25.0.1, Ubuntu, and Alpine setup as a reproducible baseline. The researcher has not published a weaponized exploit, and the repository presents the release as a demonstration of the vulnerability class.

The PoC’s mechanism points to a few detection opportunities. A Linux kernel module writing raw VMXNET3 transmit descriptors outside the normal driver path is anomalous, and host-based intrusion detection could flag it. Unexpected segmentation faults in vmware-vmx, especially alongside guest power-off events, are a post-exploitation signal. These are heuristics. An attacker who adapts the PoC to avoid the crash would not trigger them.

VMware’s vulnerability history

CVE-2026-59346 is the latest in a long run of vulnerabilities in VMware’s virtualization stack. VMXNET3 has been a recurring source of memory safety bugs, and the wider ecosystem of ESXi, vCenter Server, Workstation, and Fusion has seen serious flaws exploited in the wild. The 2023 ESXiArgs ransomware campaign, which used an OpenSLP heap overflow to encrypt thousands of ESXi hosts worldwide, is the best-known example.

A guest-to-host escape in any hypervisor component, whether KVM’s virtio-net, Hyper-V’s synthetic network adapter, or VMware’s VMXNET3, defeats the isolation guarantee virtualization exists to provide. Every VM on an affected host is potentially exposed, every credential on the host filesystem is at risk, and lateral movement across the virtualized environment becomes feasible.

Broadcom completed its acquisition of VMware in November 2023, and the transition drew scrutiny from the security community over patch cadence and advisory transparency. In this case the patch landed September 3 and the PoC appeared October 8, about five weeks later. That is in line with industry norms for coordinated disclosure, and it is a reminder to patch promptly, particularly for a component as widely deployed as VMXNET3.

Remediation guidance

Treat this as a priority patch. Update VMware Workstation or Fusion on every host to 26H1u1 or the latest supported release. Check the installed version in the About dialog or, on Linux, through the package version. Do not count guest-side updates or VMware Tools upgrades as a substitute, since the vulnerable code is in the host-side VMware-VMX binary.

Where patching is constrained, for example on air-gapped systems or under tight change-management windows, limit administrative access inside guest VMs to trusted users and audited processes. Exploitation needs guest admin privileges, so fewer people holding them means fewer potential attackers. The vulnerability remains.

Teams with detection engineering capacity should monitor for abnormal vmware-vmx terminations, guest power-off events that line up with process crashes, and unsigned or unusual kernel modules loading inside guest VMs. In high-security environments, running VMs with a network adapter other than VMXNET3 is an option where performance allows. It is a last-resort measure, and Broadcom does not recommend it.

Researchers and penetration testers who want to validate the fix should do so only in isolated, authorized labs. The PoC deliberately crashes vmware-vmx and powers off the target VM, so running it against production VMs or shared development hosts risks collateral disruption.

The gap between crash and code execution

The key caveat in this disclosure is the distance between what the PoC shows and what the bug might allow. The PoC proves that guest-controlled input can corrupt host process memory, that the integer overflow is reachable, that the resulting out-of-bounds write is not caught before it crosses the buffer boundary, and that vmware-vmx crashes as a result.

It does not prove an attacker can control the content and destination of that write precisely enough to hijack execution. That would require getting past the host’s memory layout randomization, finding usable overwrite targets in the VMware-VMX heap, and probably chaining the overflow with an information leak to defeat ASLR. These are hard exploit engineering problems, but they are problems of degree. Heap exploitation history shows determined researchers and threat actors solve them routinely.

I would take ZDI’s confirmation that the flaw supports arbitrary code execution in the hypervisor context at face value. ZDI’s analysts do not hand out exploitability assessments lightly, and their 7.5 reflects a judgment that code execution is achievable with moderate effort. The public PoC narrows that gap for anyone willing to put in the work.

Final assessment

CVE-2026-59346 is a high-impact flaw in a widely deployed virtualization component. The vendor has patched it, but public exploit code now lowers the barrier to building a full exploit. The root cause is incomplete input validation after an earlier patch: the VMXNET3 TSO path checked sums and never checked the product. No workaround exists, the fix has to be applied on the host, and the bug crosses the guest-to-host boundary. If you run Workstation or Fusion 25H2 or 26H1, update to 26H1u1 or later.