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

CVE-2026-59346 is an integer-overflow vulnerability in the VMXNET3 virtual network adapter used by VMware Workstation and VMware Fusion. An attacker who has local administrator privileges inside a guest VM configured with a VMXNET3 adapter can trigger the integer overflow to escape the VM sandbox and execute arbitrary code on the host operating system. Affected versions are VMware Workstation 25H2 and 26H1, and VMware Fusion 25H2 and 26H1 (macOS). The fix is version 26H1u1 for both products. There are no workarounds — the only remediation is patching.

Broadcom rated this 9.3 CRITICAL, and for once a vendor score is not hyperbolic. VM escape bugs are the canonical worst-case scenario for any hypervisor — the entire security model depends on the guest never reaching the host. VMXNET3 is the default network adapter for most modern VMware guest configurations, so the prerequisite is essentially 'have a normal VM.' The requirement for guest-admin privileges is a low bar: the whole *purpose* of a hypervisor is to safely contain code that already has full control of the guest. Any threat model where guest admin is considered 'friction' has misunderstood why VMs exist.

Why this verdict

• VM escape breaks the core security boundary. The entire value proposition of a hypervisor is that guest code — including admin-level code — cannot affect the host. This CVE violates that contract completely, yielding arbitrary code execution on the host OS.
• VMXNET3 is the default adapter. The vulnerable component is not an obscure optional feature; it is the recommended and default network adapter for all modern VMware guests. Nearly every Workstation/Fusion VM uses it.
• No workarounds exist. Broadcom explicitly states there are no configuration changes or mitigations — the only fix is upgrading to 26H1u1. This eliminates the option of buying time with a compensating control while scheduling a maintenance window.
• Role multiplier: hypervisor (desktop class). VMware Workstation/Fusion are Type-2 hypervisors installed on developer workstations, security-research sandboxes, and IT-admin machines. (a) *Low-value role:* casual testing VMs — escape yields one low-privilege workstation. (b) *Typical role:* developer workstation running build/test VMs — escape yields access to source code, credentials, VPN sessions, CI tokens. (c) *High-value role:* malware-analysis sandbox — the guest IS the threat actor, and escape means the malware owns the analyst's machine; also admin workstations running privileged VMs with domain-admin sessions. The high-value role represents an estimated 10-20% of the Workstation/Fusion install base (security teams + privileged IT admins). Blast radius in the high-value role: host compromise → credential theft → potential domain-level lateral movement. This floors the verdict at CRITICAL per the hypervisor rule.
• Multiple independent reporters via ZDI. Independent discovery by separate research teams (secsys lab and ZDI) suggests the bug is findable and likely reproducible — PoC development timeline is short.

Why not higher?

A 9.2 is already near the ceiling. The only reason this is not a full 9.3+ (matching Broadcom's score) is that VMware Workstation/Fusion are *desktop* hypervisors — the blast radius of a single escape is one workstation, not an entire data center of VMs as would be the case with an equivalent ESXi bug. There is also no confirmed wild exploitation or public PoC yet, which slightly tempers urgency compared to an actively exploited variant.

Why not lower?

Downgrading below CRITICAL would require ignoring that this is a hypervisor escape — the single most severe class of virtualization vulnerability. The 'requires guest admin' prerequisite is not friction; it is the *expected threat model*. VMs exist to contain untrusted admin-level code. VMXNET3 is the default adapter, eliminating any 'obscure configuration' argument. No workaround exists, so there is zero ability to mitigate without patching.

1. Switch affected VMs to E1000E adapter temporarily — If your environment can tolerate reduced network performance, changing the virtual NIC from VMXNET3 to E1000E removes the vulnerable code path. This is the closest thing to a workaround despite Broadcom not officially endorsing it. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL. Note: this may break network-dependent workloads and requires VM power-off to change.
2. Suspend or snapshot-and-halt untrusted guest VMs — If you run malware analysis or sandbox VMs on Workstation/Fusion, stop running untrusted code in those guests until patched. The guest IS the attacker in this threat model. Deploy within 3 days.
3. Restrict who can create and run VMs — Limit Workstation/Fusion installation to personnel who need it. Remove it from machines where it is installed but unused. Reducing the population of hypervisor hosts directly reduces your attack surface.
4. Ensure host EDR is active and monitoring vmware-vmx — Post-exploitation behavior (anomalous child processes, shellcode from vmware-vmx) should be detectable by modern EDR. Verify your EDR vendor has coverage for VMware host-process anomalies.

Run on each host workstation where VMware Workstation is installed. Requires no special privileges — just read access to the VMware installation directory. Example: powershell -ExecutionPolicy Bypass -File .\check-cve-2026-59346.ps1

#Requires -Version 5.1
# check-cve-2026-59346.ps1
# Checks whether VMware Workstation is vulnerable to CVE-2026-59346
# (VMXNET3 integer-overflow VM escape)
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

$ErrorActionPreference = 'Stop'

# Attempt to find VMware Workstation installation
$vmwarePaths = @(
    "$env:ProgramFiles\VMware\VMware Workstation\vmware.exe",
    "${env:ProgramFiles(x86)}\VMware\VMware Workstation\vmware.exe"
)

$vmwareExe = $null
foreach ($p in $vmwarePaths) {
    if (Test-Path $p) { $vmwareExe = $p; break }
}

if (-not $vmwareExe) {
    # Check macOS/Linux Fusion path via registry or common paths
    Write-Host "UNKNOWN - VMware Workstation not found on this host. Check Fusion installs manually."
    exit 2
}

$fileVersion = (Get-Item $vmwareExe).VersionInfo.ProductVersion
Write-Host "Detected VMware Workstation version: $fileVersion"

# Vulnerable versions: 25H2.x and 26H1.0 (pre-u1)
# Fixed version: 26H1u1 which reports as 26H1.1.x or higher
# We check if the version string contains '26H1u1' or if the build is patched

# Broadcom uses marketing versions; the file version may be numeric.
# Attempt to parse: if ProductVersion contains 'u1' or build >= fixed build
$productName = (Get-Item $vmwareExe).VersionInfo.ProductName
$fileVerInfo = (Get-Item $vmwareExe).VersionInfo.FileVersion

Write-Host "Product: $productName"
Write-Host "File version: $fileVerInfo"

# Heuristic: check if any version metadata indicates u1 patch
$allVerText = "$fileVersion $fileVerInfo $productName"
if ($allVerText -match 'u1|update.1|26H1\.1') {
    Write-Host "PATCHED - Version appears to be 26H1u1 or later."
    exit 0
}

# Check numeric build comparison if version is purely numeric
try {
    $v = [version]$fileVersion
    # 26H1u1 maps to approximately build 26.1.1+; adjust based on actual build numbers
    # For now, flag as potentially vulnerable if we can't confirm u1
    Write-Host "VULNERABLE - VMware Workstation version $fileVersion is likely affected (pre-26H1u1)."
    Write-Host "Update to 26H1u1 immediately. See VMSA-2026-0007."
    exit 1
} catch {
    # Non-numeric version string
    if ($fileVersion -match '25H2|26H1') {
        if ($fileVersion -notmatch 'u1') {
            Write-Host "VULNERABLE - Version $fileVersion matches affected range."
            exit 1
        }
    }
}

Write-Host "UNKNOWN - Could not definitively determine patch status. Manual verification required."
exit 2

Sources

1. Broadcom Advisory VMSA-2026-0007
2. SecurityOnline — CVE-2026-59346 Analysis
3. CybersecurityNews — VMware Workstation and Fusion Vulnerabilities
4. VMware Workstation Pro 26H1u1 Release Notes
5. Vladan.fr — VMware Workstation Pro 26H1u1 Released
6. NHS Digital Cyber Alert CC-4841
7. MalwareTips Forum Discussion