← Back to Feed CACHED · 2026-10-09 07:55:28 · CACHE_KEY CVE-2026-59346
CVE-2026-59346 · CWE-190 · Disclosed 2026-10-07

VMware Workstation/Fusion VMXNET3 TSO Integer Overflow Guest-to-Host Escape

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Someone left a calculator bug in the virtual network card, and now a rogue guest can punch through the walls of its sandbox

CVE-2026-59346 is an integer overflow in the VMXNET3 paravirtualized NIC's TCP Segmentation Offload (TSO) processing path inside the host-side vmware-vmx process. When a guest admin crafts a transmit descriptor ring with segment counts and sizes whose product exceeds 2³², the 32-bit multiplication wraps around: VMware allocates a tiny buffer while the copy loop writes guest-controlled data far past its boundary. The result is an out-of-bounds heap write in the host process — a textbook guest-to-host escape primitive. VMware Workstation 25H2 and 26H1 and Fusion 25H2 and 26H1 are affected; the fix shipped in 26H1u1 on 2026-09-03 under VMSA-2026-0007. This is the *second* Critical VMXNET3 bug in five weeks (after CVE-2026-59310 in VMSA-2026-0006), suggesting deep audit debt in this code path. Notably, CVE-2025-41236 patched the same TSO path in 2025 but missed the multiplication that actually decides allocation size — an incomplete fix that the researcher (Stan S / 0xCyberstan) specifically called out.

Broadcom rates this 9.3 CRITICAL. That score is defensible *if you model the theoretical maximum*: Scope:Changed, full CIA impact on the host. But the CVSS vector encodes PR:N (no privileges on the *host*), which obscures the real prerequisite — administrative access inside the guest VM. ZDI independently scored this 7.5 (ZDI-26-647), and their reasoning better matches operational reality. The public PoC reliably crashes vmware-vmx but does not achieve code execution; ZDI confirmed the primitive supports RCE, so the weaponization gap is narrow but real. Critically, this affects VMware Workstation and Fusion — desktop Type 2 hypervisors — *not ESXi*. The blast radius is one developer laptop, not a vSphere cluster. Broadcom's 9.3 reads as if this were a datacenter hypervisor escape. It isn't. HIGH is the correct operational severity for a desktop hypervisor escape with a crash-only public PoC and zero in-the-wild exploitation.

"Desktop VM escape is serious but this isn't ESXi — your dev laptop, not your datacenter, is the target."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Obtain guest admin privileges

The attacker must first gain administrative or root-level access inside a VMware Workstation or Fusion guest VM. The exploit writes directly to VMXNET3 descriptor rings via MMIO, which requires kernel-level access (loading a module or using raw I/O from ring 0). In practice, the guest OS is already *fully compromised* before the VM escape chain begins — this is a post-compromise escalation, not an initial access vector.
Conditions required:
  • Administrative/root access inside the guest OS
  • Guest VM running on affected Workstation/Fusion version (25H2 or 26H1)
Where this breaks in practice:
  • Attacker must already hold a full guest foothold — this eliminates opportunistic or unauthenticated attack scenarios
  • Many enterprise Workstation deployments run hardened guest images with restricted admin and Secure Boot
Detection/coverage: Guest-side EDR detects privilege escalation and suspicious process behavior; standard endpoint agents are the only option since NSX Guest Introspection is not available on Workstation/Fusion
STEP 02

Confirm VMXNET3 adapter is present

The exploit targets the VMXNET3 paravirtualized NIC specifically. In modern Workstation/Fusion (25H2+), VMXNET3 is the default adapter for VMs created with current hardware compatibility levels. The attacker enumerates the NIC type from inside the guest — on Linux via lspci | grep vmxnet3, on Windows via Device Manager or Get-NetAdapter. If the VM uses E1000/E1000e instead, this attack path is dead.
Conditions required:
  • VM must be configured with VMXNET3 virtual network adapter (default in modern configs)
Where this breaks in practice:
  • Some legacy or manually configured VMs still use E1000/E1000e
  • Air-gapped VMs with no network adapter configured are not reachable
Detection/coverage: No detection signal — adapter enumeration is normal guest activity
STEP 03

Load exploit kernel module with crafted TSO descriptors

The attacker loads a kernel module (Linux) or crafted driver (Windows) that writes directly to the VMXNET3 transmit descriptor ring, bypassing normal guest driver validation. The 0xCyberstan PoC (CVE-2026-59346-POC on GitHub) is a Linux kernel module that inserts descriptors with segment_count × segment_size values engineered to overflow a 32-bit integer. The module then triggers host-side processing by writing to the VMXNET3 MMIO doorbell register.
Conditions required:
  • Ability to load kernel modules or interact with VMXNET3 descriptor rings at ring 0
  • Knowledge of VMXNET3 MMIO layout (public via PoC)
Where this breaks in practice:
  • Secure Boot + driver signature enforcement on Windows guests blocks unsigned drivers
  • Linux guests with CONFIG_MODULE_SIG_FORCE=y block unsigned module loading
  • Guest EDR agents flag unsigned kernel module insertion
Detection/coverage: Sysmon Event ID 6 (driver load) on Windows guests; auditd rules on init_module/finit_module syscalls on Linux guests; the PoC module name and hash are now signatured by multiple AV engines
STEP 04

Trigger integer overflow in host-side vmware-vmx

When the host-side vmware-vmx process processes the crafted transmit ring entries through the TSO segmentation code path, it performs a 32-bit multiplication of (segment_count × segment_size) to calculate heap allocation size. The attacker-chosen values wrap the result, causing VMware to allocate a buffer far smaller than the data the copy loop will write. Guest-controlled packet data overwrites adjacent heap objects in the host process's address space.
Conditions required:
  • Crafted descriptors must reach the TSO processing path in vmware-vmx
  • Host running affected Workstation/Fusion build
Where this breaks in practice:
  • No host-side input validation intercepts this — the VMXNET3 emulation trusts the descriptor ring contents from the guest
  • Host OS ASLR and heap hardening (Windows LFH, Linux ASLR) complicate reliable exploitation beyond a crash
Detection/coverage: Host-side crash of vmware-vmx is logged in VMware diagnostic logs and system event logs; repeated crashes are a strong indicator of exploitation attempts
STEP 05

Escalate from heap corruption to host code execution

With a controlled out-of-bounds heap write in vmware-vmx, a skilled attacker corrupts adjacent heap metadata or objects to redirect execution flow. ZDI confirmed (ZDI-26-647) the primitive supports arbitrary code execution in the context of the vmware-vmx process, which runs as the logged-in desktop user on the host. The public PoC stops at crash (DoS); weaponization to reliable RCE requires heap grooming specific to the host OS, VMware build, and allocator layout. Code execution inherits the privileges of the user who launched Workstation/Fusion.
Conditions required:
  • Heap layout manipulation to convert OOB write into controlled execution
  • Host OS and VMware build-specific exploit development
Where this breaks in practice:
  • No public weaponized RCE exploit exists as of October 2026
  • Host-side ASLR, CFG (Control Flow Guard on Windows), and DEP/NX significantly raise the exploitation bar
  • The vmware-vmx process may restart after crash, but repeated crashes visually alert the user and generate logs
Detection/coverage: Host EDR detects anomalous code execution or shellcode from vmware-vmx; Windows Defender Exploit Guard flags CFG violations; crash dumps in %APPDATA%\VMware or /tmp/vmware-* contain forensic evidence of exploitation attempts
03 · Compensating Control

1
HIGH 7.8→IGNORE 0.0
SEVERITY REDUCED
Switch affected VMs from VMXNET3 to E1000e adapter — Reconfigure the virtual NIC from VMXNET3 to E1000e in VM settings (edit .vmx: ethernet0.virtualDev = "e1000e"). This completely eliminates the attack surface — the vulnerable TSO code path in VMXNET3 is never invoked. Network throughput will degrade and CPU overhead will increase, but this is acceptable as a temporary control. Deploy within 30 days per the noisgate mitigation SLA for HIGH-severity findings. Test network-intensive workloads before mass rollout. Prioritize VMs used for malware analysis or on IT admin workstations first.
2
HIGH 7.8→MEDIUM 5.5
SEVERITY REDUCED
Restrict kernel module loading inside guest VMs — On Linux guests, set kernel.modules_disabled=1 via sysctl after boot or enforce CONFIG_MODULE_SIG_FORCE=y. On Windows guests, enable Hypervisor-Protected Code Integrity (HVCI) and enforce driver signature verification. This breaks step 3 of the attack chain — the attacker cannot load the exploit kernel module needed to craft malicious VMXNET3 descriptors. Note: this does NOT prevent exploitation by an attacker who already has ring-0 access through other means (e.g., a kernel exploit), so residual risk remains. Deploy within 30 days per noisgate mitigation SLA.
3
HIGH 7.8→HIGH 7.0
Deploy EDR with kernel module and driver load monitoring on guests — Ensure endpoint agents inside guest VMs alert on unsigned kernel module loads: Linux auditd rules on init_module/finit_module syscalls; Windows Sysmon Event ID 6 for driver loads. The current public PoC's kernel module is now signatured by multiple AV/EDR engines. This is a *detective* control — it alerts on exploitation attempts but does not prevent them. Combine with module-loading restrictions for defense in depth. Deploy within 30 days.
4
HIGH 7.8→IGNORE 0.0
SEVERITY REDUCED
Patch to Workstation/Fusion 26H1u1 — Apply the vendor patch (VMSA-2026-0007, version 26H1u1) which fixes the integer overflow by adding proper bounds checking on the segment_count × segment_size multiplication. This is the definitive remediation. No backport to 25H2 exists — upgrade required. Deploy within 180 days per the noisgate remediation SLA for HIGH-severity findings. Prioritize machines used for malware analysis or security research, then IT admin workstations, then general developer endpoints.
What doesn't work
  • Host-based firewall rules — This is not a network attack against the host. The exploit transits the virtual NIC's descriptor ring via MMIO, not real network packets. Blocking host network traffic does nothing to prevent guest-to-host escape through the VMXNET3 emulation layer.
  • Disabling TSO on the guest NIC — Guest-side TSO offload settings (e.g., ethtool -K eth0 tso off on Linux) control the guest driver's behavior, but the exploit bypasses the guest driver entirely by writing raw descriptors to the VMXNET3 transmit ring. The host-side TSO processing path is still reachable via direct MMIO writes.
  • VMware guest isolation settings — Settings like isolation.tools.copy.disable, drag-and-drop restrictions, and shared folder disabling control clipboard and file-sharing channels, not the VMXNET3 NIC emulation layer. They provide zero protection against this vulnerability.
  • Network segmentation of the host machine — The exploit path is guest → host via virtual NIC emulation internals, not via real network traffic traversing switches or firewalls. Isolating the host on a restricted VLAN does not block descriptor-ring-based VM escape.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone confirmed. Not listed in CISA KEV. No GreyNoise or Shadowserver activity tags. CISA records exploitation status as "none" as of October 2026. No known campaigns leveraging this vulnerability.
Proof-of-conceptPublic crash PoC available. Researcher Stan S (0xCyberstan) published a Linux kernel module PoC at github.com/0xCyberstan/CVE-2026-59346-POC with a technical writeup at cyberstan.co.uk/vmxnet3-tso-overflow/. Indexed on Sploitus. The PoC reliably crashes vmware-vmx via segfault but does not achieve code execution. ZDI confirmed the primitive supports RCE (ZDI-26-647).
EPSS0.00258 (0.258%, 30-day window). Low predicted probability of exploitation, consistent with local attack vector, crash-only PoC, and no observed campaigns.
KEV statusNot listed in CISA Known Exploited Vulnerabilities catalog as of 2026-10-09.
CVSS vectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — Broadcom 9.3 CRITICAL. The PR:N is technically correct (no *host* privileges needed) but misleading — guest admin is required. ZDI scored 7.5 (ZDI-26-647), better reflecting the guest-admin prerequisite and exploitation complexity.
Affected versionsVMware Workstation 25H2 and 26H1 (Windows/Linux); VMware Fusion 25H2 and 26H1 (macOS). ESXi, vSphere, and Cloud Foundation are NOT affected — this is desktop-only.
Fixed versionsVMware Workstation 26H1u1 and VMware Fusion 26H1u1, released 2026-09-03 under VMSA-2026-0007. No backport to 25H2 — full upgrade to 26H1u1 is required.
Scanning / exposureNot remotely exploitable — no Shodan/Censys/FOFA/GreyNoise internet-facing surface. This is a local guest-to-host attack vector. Exposure is measured by unpatched Workstation/Fusion install count, not internet footprint. Asset inventory tools (SCCM, Intune, osquery) can enumerate VMware desktop installations.
Related vulnerabilitiesCVE-2025-41236 (2025) — same VMXNET3 TSO code path, incomplete fix that missed the critical multiplication. CVE-2026-59310 (VMSA-2026-0006, August 2026) — another VMXNET3 OOB write rated 9.3. Two Critical VMXNET3 bugs in five weeks signals systemic code-path debt.
Reporting researcherStan S (@0xCyberstan), independent researcher. Coordinated disclosure through Zero Day Initiative (ZDI-26-647).

Sources.

  1. Broadcom VMSA-2026-0007 Advisory
  2. CyberSecurityNews — PoC Analysis
  3. GBHackers — PoC Exploit Released
  4. SecurityOnline — VMXNET3 Vulnerability Detail
  5. 0xCyberstan PoC Repository (Sploitus)
  6. Shattered.io — VM-Escape Analysis
  7. TheHackerWire — Technical Breakdown
  8. AZTCO Firewall — Patch Guidance
05 · The Call

Final Verdict
↓ DOWNGRADED to HIGH (7.8/10)

Why this verdict

  • Guest admin is a full prior compromise stage. The attacker must already own the guest OS with administrative privileges before this chain begins. CVSS encodes PR:N (no host privileges), but operationally the guest must be fully compromised first. This is post-exploitation escalation, not initial access. ZDI's 7.5 reflects this reality better than Broadcom's 9.3. Adjustment: −1.0 from vendor baseline.
  • Desktop hypervisor, not ESXi — blast radius is one workstation. VMware Workstation and Fusion are Type 2 (hosted) hypervisors running on developer desktops and laptops. A successful escape gives you one laptop, not a vSphere cluster or datacenter. Broadcom's 9.3 reads like an ESXi escape rating; the actual impact scope is fundamentally narrower. Adjustment: −0.8 from vendor baseline.
  • Public PoC is crash-only — no weaponized RCE. The 0xCyberstan PoC reliably crashes vmware-vmx (DoS) but stops short of code execution. ZDI confirmed the primitive supports RCE, and the gap will close, but as of October 2026 no weaponized exploit is public. Host-side ASLR, CFG, and heap hardening further complicate weaponization. Adjustment: −0.5 from vendor baseline.
  • No in-the-wild exploitation, low EPSS. Not on CISA KEV, no GreyNoise activity, EPSS 0.258%. The threat is PoC-stage and theoretical, not actively exploited. No adjustment on its own, but it confirms the overall downgrade direction.
  • VMXNET3 is default in modern configs — limited adapter friction. Modern Workstation/Fusion versions default to VMXNET3 for new VMs, so most guests are reachable. This prevents further downgrade. Adjustment: +0.0 (friction point removed, not a severity increase).
  • Role multiplier: (a) *Low-value role (majority ~70%)*: developer laptops, QA test environments, training labs — escape yields one workstation, zero fleet impact. Chain succeeds, blast radius = host-level. (b) *Typical role (~20%)*: demo environments, pre-sales, general IT — similar single-host scope. (c) *High-value role (~10%)*: malware analysis sandboxes where VM escape is the explicit threat model; IT admin workstations where the host may cache domain credentials, VPN split-tunnel tokens, or admin SSH keys. In the malware-analysis role, escape is the nightmare scenario but affects one analyst machine (host-level blast radius), not a fleet. In the IT-admin role, a compromised admin laptop could enable lateral movement toward domain controllers, but that requires a multi-step chain *beyond this CVE*. Workstation/Fusion is NOT canonically a high-value-role component (it is not ESXi, KVM, or Hyper-V running production VMs). <10% of installs occupy security-critical roles, so the CRITICAL floor does not apply. The HIGH floor IS triggered because guest-to-host escape in the malware-analysis and IT-admin roles represents a plausible ≥1% of the installed base with host-level impact.

Why not higher?

CRITICAL would require either active in-the-wild exploitation, a weaponized RCE exploit, or a production datacenter hypervisor (ESXi/KVM/Hyper-V) blast radius — none of which are present. The PoC is crash-only, EPSS is 0.258%, there is no KEV listing, and the affected products are desktop Type 2 hypervisors with single-host blast radius. Even in the worst-case malware-analysis scenario, the outcome is one compromised analyst workstation, not fleet-scale or domain-scale impact. Broadcom's 9.3 CRITICAL does not discount for the desktop-only deployment model or the guest-admin prerequisite.

Why not lower?

VM escape is an inherently high-severity class — it breaks the fundamental security boundary that virtualization promises. ZDI confirmed code execution is achievable from this heap primitive, and a public crash PoC significantly lowers the bar for weaponization by skilled attackers. Two VMXNET3 Critical bugs in five weeks (CVE-2026-59310 and CVE-2026-59346) indicate active researcher focus on this code path, making weaponization a matter of *when*, not *if*. MEDIUM would undercount the real risk to the ~5-10% of Workstation/Fusion installs used for security-sensitive workloads like malware analysis, where this is the exact threat model.

06 · Verification

Crowdsourced verification payload.

Run on the host machine where VMware Workstation or Fusion is installed (not inside a guest VM). No elevated privileges required — reads the VMware version string and scans .vmx files for VMXNET3 adapters. Invoke: bash check_cve_2026_59346.sh

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-59346 Verification Script
# Checks VMware Workstation/Fusion for VMXNET3 integer overflow vulnerability
# Run on the HOST machine, not inside a guest VM
# Exit codes: 0=PATCHED  1=VULNERABLE  2=UNKNOWN
set -uo pipefail

RED='\033[0;31m'; GREEN='\033[0;32m'; YELLOW='\033[1;33m'; NC='\033[0m'
VULN_STATUS="UNKNOWN"

echo "=== CVE-2026-59346 Check: VMware VMXNET3 TSO Integer Overflow ==="
echo ""

# --- Detect VMware installation ---
VERSION_OUTPUT=""
if command -v vmware &>/dev/null; then
    VERSION_OUTPUT=$(vmware --version 2>/dev/null || true)
elif command -v vmrun &>/dev/null; then
    VERSION_OUTPUT=$(vmrun --version 2>/dev/null | head -1 || true)
elif [ -d "/Applications/VMware Fusion.app" ]; then
    PLIST="/Applications/VMware Fusion.app/Contents/Info.plist"
    if [ -f "$PLIST" ]; then
        VERSION_OUTPUT="VMware Fusion $(/usr/libexec/PlistBuddy -c 'Print :CFBundleShortVersionString' "$PLIST" 2>/dev/null || echo 'unknown')"
    fi
fi

if [ -z "$VERSION_OUTPUT" ]; then
    echo -e "${YELLOW}[*] VMware Workstation/Fusion not detected on this host.${NC}"
    echo "UNKNOWN"
    exit 2
fi

echo "[*] Detected: $VERSION_OUTPUT"
echo ""

# --- Version check ---
# Patched: 26H1u1 or any later release (26H2, 27H1, etc.)
# Affected: 25H2, 26H1 (without u1 suffix)
if echo "$VERSION_OUTPUT" | grep -qiE '26H1u[1-9]|26H[2-9]|2[7-9]H[12]'; then
    VULN_STATUS="PATCHED"
    echo -e "${GREEN}[+] Version is 26H1u1 or later. CVE-2026-59346 is PATCHED.${NC}"
elif echo "$VERSION_OUTPUT" | grep -qiE '25H2|26H1([^u]|$)'; then
    echo -e "${RED}[!] Version matches affected range (25H2 or 26H1).${NC}"
    VULN_STATUS="VULNERABLE"
    # --- Scan for VMXNET3 adapters in VM configs ---
    echo ""
    echo "[*] Scanning for VMs with VMXNET3 adapters..."
    VMX_COUNT=0
    VMXNET3_COUNT=0
    SEARCH_DIRS=("$HOME")
    [ -d "/var/lib/vmware" ] && SEARCH_DIRS+=("/var/lib/vmware")
    [ -d "$HOME/Virtual Machines" ] && SEARCH_DIRS+=("$HOME/Virtual Machines")
    [ -d "$HOME/Documents/Virtual Machines" ] && SEARCH_DIRS+=("$HOME/Documents/Virtual Machines")
    while IFS= read -r vmx; do
        VMX_COUNT=$((VMX_COUNT + 1))
        if grep -qi 'virtualDev.*=.*"vmxnet3"' "$vmx" 2>/dev/null; then
            VMXNET3_COUNT=$((VMXNET3_COUNT + 1))
            VM_NAME=$(grep -i 'displayName' "$vmx" 2>/dev/null | head -1 | sed 's/.*= *"//;s/".*//' || basename "$vmx")
            echo -e "    ${RED}[!] VMXNET3: $VM_NAME${NC} ($vmx)"
        fi
    done < <(find "${SEARCH_DIRS[@]}" -maxdepth 5 -name '*.vmx' -type f 2>/dev/null | sort -u)
    echo ""
    if [ $VMX_COUNT -eq 0 ]; then
        echo "    [*] No .vmx files found in common locations."
    elif [ $VMXNET3_COUNT -eq 0 ]; then
        echo -e "    ${GREEN}[+] 0 of $VMX_COUNT VM(s) use VMXNET3 — attack surface eliminated.${NC}"
        echo "    [*] Note: version is still vulnerable; patching recommended."
    else
        echo -e "    ${RED}[!] $VMXNET3_COUNT of $VMX_COUNT VM(s) use VMXNET3 — actively exposed.${NC}"
    fi
else
    echo -e "${YELLOW}[*] Version not recognized. Manually verify against VMSA-2026-0007.${NC}"
    VULN_STATUS="UNKNOWN"
fi

echo ""
echo "=== Result: $VULN_STATUS ==="

case $VULN_STATUS in
    PATCHED)    exit 0 ;;
    VULNERABLE) exit 1 ;;
    *)          exit 2 ;;
esac