Hyper-V's VMSwitch use-after-free: a guest VM that walks out onto the host (CVE-2026-57092)

Most privilege-escalation bugs let an attacker climb from user to admin on one machine. This one is different: it crosses the wall between a guest virtual machine and the Hyper-V host that runs it. Microsoft's July 2026 update fixes a use-after-free in VMSwitch (vmswitch.sys), the virtual network switch that lives in the host kernel — and a guest that can send traffic on its own virtual NIC can reach it. Take the host, and you take every VM on it.

What the flaw actually is

vmswitch.sys is the Hyper-V virtual switch. It runs in the host kernel (the root partition) as the networking Virtual Service Provider, and every guest's synthetic network adapter talks to it over VMBus, the channel between partitions. To move packets and configure the virtual NIC, a guest sends RNDIS messages and OID requests into that host-side code. In other words, ordinary guest network activity drives complex parsing inside the host kernel — no host credentials required.

The bug is a use-after-free (CWE-416): while VMSwitch handles a crafted sequence of those guest-supplied requests, it frees an object and then keeps using a stale pointer to it. Because that code runs in the host kernel, controlling the freed memory turns into code execution on the host. Microsoft hasn't published the exact object or trigger, and no reverse-engineering write-up is public yet — but the shape is well understood from earlier VMSwitch bugs.

The exploitation chain

The path from a foothold in a guest to full host compromise is short, and there are only two places worth spending money to break it: shrink who can run untrusted guests, and patch. The diagram traces the chain and marks those chokepoints.

Am I affected?

Only hosts with the Hyper-V role/feature enabled load vmswitch.sys, so if you don't run Hyper-V you're not exposed. The bug spans the full supported Windows and Windows Server range that ships Hyper-V. The fix ships only inside the July 14, 2026 cumulative update — there is no standalone hotfix — so confirm the OS build, not a driver version.

Exploited in the wild? Stated carefully

As of 2026-07-15: no public proof-of-concept, not on CISA KEV, no EPSS score published, and no in-the-wild reports. Microsoft rates it “Exploitation Less Likely” and the temporal vector carries E:U (exploit code unproven). This landed in a record Patch Tuesday whose actual exploited zero-days were a different set — an AD FS bug (CVE-2026-56155) and a SharePoint bug (CVE-2026-56164). This one's notability is its severity and class, not its exploit maturity.

Detection & hunting

Be honest about the ceiling: a kernel-mode use-after-free leaves almost no telemetry when it succeeds, and there is no CVE-specific Sigma, Nuclei, Snort or Defender rule published. The only host-side signal is the opposite of success — a failed attempt that bugchecks the host — plus knowing which hosts are unpatched. So detection here is really inventory + patch-state, with crash-correlation as a weak triage lead.

• Scope exposure: is Hyper-V enabled (Get-WindowsOptionalFeature / Get-WindowsFeature), and does Get-VMSwitch return a switch? If not, vmswitch.sys isn't even loaded.
• Gate patch state on OS build, not the driver string — compare each host's build/UBR to the July fixed build for its SKU.
• Crash-correlation (weak): on inventoried Hyper-V hosts, a bugcheck (System log Event ID 1001 + Kernel-Power Event ID 41) is worth a look — confirm vmswitch.sys as the faulting module in the minidump (!analyze -v). It usually means a failed attempt or unrelated instability, not proof of compromise.
• MDE/TVM: DeviceTvmSoftwareVulnerabilities | where CveId == "CVE-2026-57092" lists hosts still flagged as missing the fix once TVM ingests the CVE.

# Flag Hyper-V hosts NOT on the July 2026 fixed build (run local or via Invoke-Command)
$fixed = @{'26100'='26100.8875';'26200'='26200.8875';'20348'='20348.5386';
           '17763'='17763.9020';'19045'='19045.7548';'19044'='19044.7548'}
$hv = (Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -EA SilentlyContinue).State
if (-not $hv) { try { $hv = (Get-WindowsFeature Hyper-V -EA Stop).InstallState } catch {} }
$cv  = [Environment]::OSVersion.Version
$ubr = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR
$cur = "$($cv.Build).$ubr"; $req = $fixed[[string]$cv.Build]
$patched = if ($req) { [version]$cur -ge [version]$req } else { $null }   # $null = confirm SKU vs MSRC
[pscustomobject]@{ Host=$env:COMPUTERNAME; HyperV=$hv; OSBuild=$cur;
  FixedRequired=$req; Patched=$patched;
  Exposed=(($hv -match 'Enabled|Installed') -and $patched -ne $true) } | Format-List

What to do now

1. Inventory your Hyper-V hosts and their build state (script above).
2. Patch first the hosts that carry untrusted or multi-tenant guests — cloud, VDI, DMZ VM hosts. That's where a guest can actually reach the vulnerable path.
3. Apply the July 14, 2026 cumulative update and reboot. There is no workaround; patching is the only fix.
4. Can't patch yet? You can't disable VMSwitch on a working host, so reduce blast radius: restrict who can create/run VMs, isolate the Hyper-V management plane, and treat untrusted guests as hostile until the host is patched.
5. Verify every host's build is at or above the fixed build, fleet-wide.

FAQ

Sources

• Microsoft MSRC — CVE-2026-57092 advisory
• NVD — CVE-2026-57092
• Zero Day Initiative — The July 2026 Security Update Review
• SecurityWeek — Microsoft patches a record number of vulnerabilities, incl. exploited zero-days
• The Hacker News — Microsoft July 2026 Patch Tuesday
• Cisco Talos — Microsoft Patch Tuesday, July 2026
• Microsoft — KB5101650 (Win11 24H2 / Server 2025 build reference)
• Akamai — Critical Hyper-V/VMSwitch vulnerability analysis (background on the attack surface)
• BleepingComputer — the earlier VMSwitch bug (CVE-2021-28476), for class precedent
• CISA — Known Exploited Vulnerabilities catalog