CVE-2026-59346: VMware Workstation VMXNET3 TSO Integer Overflow — Guest-to-Host Privilege Escalation Defense Guide

Excerpt: VMware Workstation VMXNET3 TSO flaw CVE-2026-59346 can let a high-privileged guest process escalate on the host. Patch, inventory adapters, and hunt vmware-vmx anomalies now.

Introduction

Zero Day Initiative advisory ZDI-26-647 discloses CVE-2026-59346, a local privilege-escalation vulnerability in VMware Workstation tied to the VMXNET3 virtual network adapter TSO segmentation path. ZDI rates it CVSS 7.5, which is High, and the important precondition is equally important: the attacker must already be able to execute high-privileged code inside the guest before this bug becomes useful.

That precondition should not make defenders comfortable. In real intrusions, guest compromise is often the starting point, not the end state. A developer workstation, malware-analysis VM, jump box, VDI template, build runner, or lab host running Workstation can turn a contained guest intrusion into a host compromise if the virtual device boundary fails. The defensive question is not only 'is the host patched' but 'where do we still expose VMXNET3, which guests are privileged, and would we notice vmware-vmx behaving like an exploitation staging process.'

Treat this as a virtualization boundary issue with host impact. Patch quickly, reduce VMXNET3 exposure where operationally acceptable, harden guest offload settings, and instrument host telemetry around the Workstation VM runtime.

Technical Analysis

Affected component: VMware Workstation virtual networking implementation, specifically the VMXNET3 paravirtual NIC path handling TCP Segmentation Offload, often abbreviated TSO.

CVE / advisory: CVE-2026-59346, ZDI-26-647. ZDI lists a CVSS rating of 7.5. The summary provided does not include a CVSS vector, affected build ranges, or fixed build numbers, so defenders should pull those exact values from the ZDI advisory and Broadcom/VMware release notes before change approval: http://www.zerodayinitiative.com/advisories/ZDI-26-647/

Platforms and versions: The news item identifies affected installations of VMware Workstation but does not enumerate versions or host operating systems. Operationally, assume relevance wherever Workstation hosts run guests configured with ethernetX.virtualDev = 'vmxnet3', including Windows and Linux hosts, until the vendor advisory proves otherwise. Do not extrapolate fixed versions from this summary; verify against Broadcom/VMware download and release-note pages for the exact Workstation branch you run.

How the bug works, defensive view: VMXNET3 is a high-performance paravirtual NIC. TSO lets the guest hand large TCP segments to the virtualization layer or NIC stack so segmentation work is offloaded from the guest CPU. The vulnerability is described as an integer overflow in TSO segmentation. From a defender's perspective, that class of defect is dangerous because packet-size, segment-count, length, or offset arithmetic can be made to wrap or truncate, causing incorrect bounds calculations in a code path that parses guest-supplied network metadata.

The exploitation prerequisite is high-privileged guest code execution. That means the likely chain is: attacker gains root/Administrator or kernel-adjacent capability in a guest, interacts with the virtual NIC/offload path, triggers the overflow during segmentation handling, and attempts to corrupt memory in a Workstation host-side component such as the VM runtime process. On Windows hosts this is commonly vmware-vmx.exe; on Linux hosts the analogous VM monitor process is the high-value target. A successful outcome is unauthorized privilege gain on affected Workstation installations, which in practical terms can mean escape from guest containment assumptions or execution in a more privileged host context.

Exploitation status: The provided item does not state public PoC, confirmed in-the-wild exploitation, or CISA KEV inclusion. As of this writing, defenders should check three sources before lowering urgency: the ZDI advisory page, Broadcom/VMware security release notes, and CISA KEV. Absence of confirmed exploitation is not a control; it is only a timing variable.

Why this matters in enterprise defense: Workstation is frequently present outside formal server virtualization governance: incident-response labs, detonation environments, contractor laptops, OT engineering stations, training ranges, and software build/test machines. These hosts often hold credentials, EDR consoles, VPN profiles, source code, snapshots, and management-plane access. A guest-to-host privilege gain can collapse the separation that made the VM useful in the first place.

Detection & Response

The highest-fidelity host signal is not a magic packet pattern; it is abnormal behavior around the Workstation VM runtime and unexpected adapter/offload state changes. Focus on process lineage under vmware-vmx, suspicious configuration edits to .vmx files, and guest NIC offload manipulation consistent with preparing or testing the vulnerable path.

SIGMA rules

---
title: VMware Workstation VM Runtime Spawning Unexpected Child Process
id: 9c2b7f1a-5d41-4c82-a9f1-7b0c2d4e6a11
status: experimental
description: Detects Windows host processes such as cmd, PowerShell, rundll32, reg, sc, net, wmic, or taskkill launched by vmware-vmx.exe, which can indicate post-exploitation after a guest-boundary compromise such as CVE-2026-59346.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-647/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.privilege_escalation
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\vmware-vmx.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\reg.exe'
      - '\sc.exe'
      - '\net.exe'
      - '\net1.exe'
      - '\wmic.exe'
      - '\taskkill.exe'
      - '\schtasks.exe'
      - '\bitsadmin.exe'
  condition: selection_parent and selection_child
falsepositives:
  - VMware tools or scripted VM lifecycle automation in tightly controlled labs
level: high
---
title: VMware VMX Configuration Changed Toward VMXNET3 Exposure
id: 3f7a8c90-1b65-4fd4-b3f8-2a6d9c0e7b22
status: experimental
description: Detects creation or modification of VMware .vmx files where a virtual Ethernet adapter is configured as vmxnet3, useful for exposure management and for spotting suspicious reconfiguration on Workstation hosts.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-647/
  - https://attack.mitre.org/techniques/T1562/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.defense_evasion
  - attack.discovery
logsource:
  category: file_event
  product: windows
detection:
  selection_file:
    TargetFilename|endswith: '.vmx'
  selection_content:
    TargetFilename|contains:
      - '\Virtual Machines\'
      - '\vmware\'
      - '\Documents\'
  condition: selection_file and selection_content
falsepositives:
  - Normal VM creation, cloning, snapshot restore, and template deployment
level: low

Microsoft Sentinel / Defender KQL

// Host-side hunt: suspicious child processes spawned by VMware Workstation VM runtime
let lookback = 14d;
DeviceProcessEvents
| where TimeGenerated >= ago(lookback)
| where InitiatingProcessFileName =~ 'vmware-vmx.exe'
| where FileName in~ ('cmd.exe','powershell.exe','pwsh.exe','rundll32.exe','regsvr32.exe','reg.exe','sc.exe','net.exe','net1.exe','wmic.exe','taskkill.exe','schtasks.exe','bitsadmin.exe','mshta.exe','curl.exe','wget.exe')
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, ProcessId, InitiatingProcessId, ReportId
| extend HostRuntime = InitiatingProcessFileName, ChildTool = FileName
| order by TimeGenerated desc;

// Syslog/CEF variant for Linux Workstation hosts ingested into Sentinel
let lookback = 14d;
Syslog
| where TimeGenerated >= ago(lookback)
| where ProcessName has_any ('vmware-vmx','vmware')
| where SyslogMessage has_any ('vmxnet3','tso','segmentation','ethernet0.virtualDev','/usr/bin/sh','/bin/bash','sudo')
| project TimeGenerated, Computer, HostName, ProcessName, SyslogMessage, SeverityLevel
| order by TimeGenerated desc;

Velociraptor VQL

-- Hunt for unexpected child processes whose parent is the VMware Workstation VM runtime.
-- This is host-side post-exploitation telemetry, not exploit confirmation.
LET procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()

SELECT child.Pid AS ChildPid,
       child.Name AS ChildName,
       child.Exe AS ChildExe,
       child.CommandLine AS ChildCommandLine,
       child.Username AS ChildUser,
       parent.Pid AS ParentPid,
       parent.Name AS ParentName,
       parent.Exe AS ParentExe,
       parent.CommandLine AS ParentCommandLine
FROM procs AS child
JOIN procs AS parent
ON child.Ppid = parent.Pid
WHERE parent.Name =~ '(?i)vmware-vmx|vmware'
  AND child.Name =~ '(?i)cmd|powershell|pwsh|rundll32|regsvr32|reg\.exe|sc\.exe|net\.exe|wmic|schtasks|bitsadmin|bash|sh|sudo|curl|wget'

Remediation and verification script

Use the first script on Windows Workstation hosts to inventory VMXNET3 exposure and check installed VMware components. Use the second Bash example for Linux Workstation hosts to inventory .vmx files and disable guest TSO/GSO where Linux guests use ethtool. Test adapter changes in a maintenance window; switching from VMXNET3 to E1000/E1000E can alter guest driver behavior, MAC persistence, naming, throughput, and snapshot expectations.

# Windows host: inventory VMware Workstation installs and VMXNET3 adapter exposure
$ErrorActionPreference = 'Continue'
$programFiles = [Environment]::GetFolderPath('ProgramFiles')
$programFilesX86 = [Environment]::GetFolderPath('ProgramFilesX86')
$searchRoots = @($programFiles, $programFilesX86) | Where-Object { $_ -and (Test-Path $_) }

Write-Host '[*] Installed VMware-ish executables and file versions'
foreach ($root in $searchRoots) {
  Get-ChildItem -Path $root -Recurse -Filter vmware*.exe -ErrorAction SilentlyContinue |
    Select-Object FullName, @{Name='Version';Expression={$_.VersionInfo.ProductVersion}}, @{Name='FileVersion';Expression={$_.VersionInfo.FileVersion}}
}

$vmRoots = @(
  (Join-Path $env:USERPROFILE 'Documents'),
  (Join-Path $env:USERPROFILE 'OneDrive'),
  'D:\', 'E:\'
) | Where-Object { $_ -and (Test-Path $_) }

Write-Host '[*] VMX files using vmxnet3'
foreach ($vmRoot in $vmRoots) {
  Get-ChildItem -Path $vmRoot -Recurse -Filter *.vmx -ErrorAction SilentlyContinue |
    ForEach-Object {
      $vmx = $_.FullName
      $hits = Select-String -Path $vmx -Pattern 'ethernet[0-9]+\.virtualDev[ ]*=[ ]*vmxnet3' -AllMatches -ErrorAction SilentlyContinue
      if ($hits) {
        [PSCustomObject]@{
          VmxFile = $vmx
          Matches = ($hits | ForEach-Object { $_.Line.Trim() }) -join '; '
          LastWrite = (Get-Item $vmx).LastWriteTime
        }
      }
    }
}

Write-Host '[*] Optional hardening example: backup VMX and switch ethernet0 to e1000e - review before enabling'
# $target = 'C:\Path\To\VM\guest.vmx'
# Copy-Item $target ($target + '.bak-cve-2026-59346')
# (Get-Content $target) -replace 'ethernet0\.virtualDev[ ]*=[ ]*vmxnet3','ethernet0.virtualDev = e1000e' | Set-Content $target

Write-Host '[*] Verify latest fixed Workstation build against ZDI-26-647 and Broadcom/VMware release notes before and after patching.'

# Linux host: inventory VMXNET3 usage in local .vmx files
set -euo pipefail
printf '%s
' '[*] Searching likely VM directories for vmxnet3 adapters'
find "$HOME" /var/lib/vmware /opt/vmware -type f -name '*.vmx' -print 2>/dev/null | while read -r vmx; do
  if grep -Ei 'ethernet[0-9]+\.virtualDev[[:space:]]*=[[:space:]]*"?vmxnet3"?' "$vmx" >/dev/null 2>&1; then
    printf 'VMX=%s\n' "$vmx"
    grep -Ei 'ethernet[0-9]+\.(present|virtualDev|connectionType)' "$vmx" || true
  fi
done

printf '%s
' '[*] If a Linux guest uses vmxnet3 and cannot be patched immediately, consider disabling TSO/GSO inside that guest until fixed'
printf '%s
' 'sudo ethtool -K ens192 tso off gso off gro off 2>/dev/null || true'
printf '%s
' 'sudo ethtool -k ens192 | egrep -i "tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload" || true'

printf '%s
' '[*] Optional host package/version context'
printf '%s
' 'vmware -v 2>/dev/null || true'
printf '%s
' 'rpm -qa | egrep -i vmware 2>/dev/null || dpkg -l | egrep -i vmware 2>/dev/null || true'

Remediation

1. Patch first, then prove it. Apply the fixed VMware Workstation release referenced by ZDI-26-647 and Broadcom/VMware for your exact branch. Because the provided summary does not list fixed builds, require change tickets to cite the vendor build number, installer hash, and post-patch version evidence. Capture vmware.exe or vmware version output plus a successful VM power-on test.

2. Inventory VMXNET3 exposure. Search all Workstation hosts for .vmx lines matching ethernetX.virtualDev = 'vmxnet3'. Prioritize hosts that run untrusted guests, malware-analysis images, internet-connected lab VMs, build agents, shared training VMs, or snapshots restored from unknown provenance.

3. Reduce attack surface where performance allows. For high-risk guests, consider temporarily moving virtual adapters from VMXNET3 to E1000E or another supported adapter after validating guest drivers and application dependencies. Another compensating option is disabling TSO/GSO/GRO inside the guest with OS-supported methods such as Windows NIC advanced properties or Linux ethtool -K. This is not a substitute for patching.

4. Constrain who can become high-privileged in guests. Since exploitation requires high-privileged guest code execution, enforce least privilege inside VMs: no shared local admin, separate lab credentials, no domain admin logon to Workstation guests, application control where feasible, and EDR coverage inside frequently used guest templates.

5. Protect the host runtime. Ensure Workstation hosts are not treated as unmanaged endpoints. Deploy EDR to the host, enable process lineage and script-block telemetry, block unsigned child processes from VM runtime where policy allows, and alert on vmware-vmx spawning shells, registry tools, service control, BITS, or network downloaders.

6. Harden lab and malware-analysis workflows. Run detonation and unknown-sample VMs on isolated hosts without cached credentials, with host firewall rules limiting management-plane access, snapshots stored on access-controlled shares, and automatic reversion after analysis. Avoid bridging hostile guests directly into production networks.

7. Monitor advisory status daily until closure. Track ZDI-26-647, Broadcom/VMware release notes, CISA KEV, and your EDR vendor coverage. If exploitation becomes confirmed, shift from vulnerability-management cadence to incident-response posture: isolate affected hosts, collect volatile data, preserve .vmx, vmware.log, guest vmxnet3 driver state, host EDR timeline, and memory where justified.

8. Validate after remediation. Re-run the inventory script, confirm no unauthorized adapter changes occurred, verify offload settings where used as a workaround, test VM networking, and close the ticket only when version, exposure, and telemetry checks are all green.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub