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.
5 steps from start to impact.
Obtain guest admin privileges
- Administrative/root access inside the guest OS
- Guest VM running on affected Workstation/Fusion version (25H2 or 26H1)
- 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
Confirm VMXNET3 adapter is present
lspci | grep vmxnet3, on Windows via Device Manager or Get-NetAdapter. If the VM uses E1000/E1000e instead, this attack path is dead.- VM must be configured with VMXNET3 virtual network adapter (default in modern configs)
- Some legacy or manually configured VMs still use E1000/E1000e
- Air-gapped VMs with no network adapter configured are not reachable
Load exploit kernel module with crafted TSO descriptors
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.- Ability to load kernel modules or interact with VMXNET3 descriptor rings at ring 0
- Knowledge of VMXNET3 MMIO layout (public via PoC)
- 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
init_module/finit_module syscalls on Linux guests; the PoC module name and hash are now signatured by multiple AV enginesTrigger integer overflow in host-side vmware-vmx
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.- Crafted descriptors must reach the TSO processing path in vmware-vmx
- Host running affected Workstation/Fusion build
- 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
vmware-vmx is logged in VMware diagnostic logs and system event logs; repeated crashes are a strong indicator of exploitation attemptsEscalate from heap corruption to host code execution
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.- Heap layout manipulation to convert OOB write into controlled execution
- Host OS and VMware build-specific exploit development
- 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
%APPDATA%\VMware or /tmp/vmware-* contain forensic evidence of exploitation attempts.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.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.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.- 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 offon 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.
The supporting signals.
| In-the-wild exploitation | None 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-concept | Public 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). |
| EPSS | 0.00258 (0.258%, 30-day window). Low predicted probability of exploitation, consistent with local attack vector, crash-only PoC, and no observed campaigns. |
| KEV status | Not listed in CISA Known Exploited Vulnerabilities catalog as of 2026-10-09. |
| CVSS vector | CVSS: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 versions | VMware 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 versions | VMware 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 / exposure | Not 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 vulnerabilities | CVE-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 researcher | Stan S (@0xCyberstan), independent researcher. Coordinated disclosure through Zero Day Initiative (ZDI-26-647). |
Sources.
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.
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
#!/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