Skip to content
hacker_posts

Windows VMSwitch CVE-2026-57092: CVSS 9.9 guest-to-host escape in Hyper-V

Microsoft's July 14 Patch Tuesday closed CVE-2026-57092 — a CVSS 9.9 use-after-free in the Windows VMSwitch that lets a low-privileged guest reach the Hyper-V host.

Published 5 min read
cvemicrosofthyper-vexplainer

Microsoft's July 14, 2026 Patch Tuesday shipped a fix for CVE-2026-57092, a use-after-free in the Windows VMSwitch component — the Hyper-V Virtual Switch that bridges guest VMs, the host, and the physical network. CVSS 3.1 base score 9.9. A low-privileged principal running code inside a guest VM can send crafted network requests through the switch and force the host into freed memory, ending in elevation of privilege on the Hyper-V host. It is the highest-scoring Critical in a Patch Tuesday that shipped 621 CVEs — Microsoft's largest single release to date.

What the bug is

  • CWE-416 — use-after-free.
  • Component: VMSwitch, the kernel-mode virtual switch that Hyper-V installs when the role or any dependent feature is enabled.
  • CVSS vector: AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — network adjacent (the guest's virtual NIC), attack complexity low, low privileges in the guest, no user interaction, and — critically — scope: changed. The exploit crosses the guest/host trust boundary.
  • Outcome: guest-to-host VM escape. Code executes on the host with elevated privileges, exposing every other tenant sharing the hypervisor.

Microsoft's advisory notes exploitation involves executing code inside a guest and sending "specially crafted network-related requests" to the host through the virtual switch, forcing access to memory the kernel has already freed. Neither MSRC nor any independent researcher has published technical details or PoC code.

Affected products

The July 14 cumulative covers every supported client and server edition of Windows where VMSwitch is present, back to Windows 10 1607 and Windows Server 2012. From Rapid7's Patch Tuesday roundup and Microsoft's per-KB mapping in the Security Update Guide, the scope in practice is any host with:

  • The Hyper-V role installed (Windows Server) or Hyper-V platform feature enabled (Windows client).
  • Windows Sandbox or WSL2 — both depend on the VMSwitch driver and install it as a side effect.
  • Third-party virtualization stacks that layer on the Windows Hypervisor Platform APIs (which pull VMSwitch in for guest networking).

Devices with none of the above do not load VMSwitch and are not exposed to CVE-2026-57092 — but confirm the driver state before you defer the patch. Get-WindowsOptionalFeature -Online | Where-Object FeatureName -Like '*Hyper*' on a client, or Get-WindowsFeature *Hyper* on a server, will tell you.

Exploitation status

No confirmed exploitation. Microsoft flags CVE-2026-57092 as "Exploitation Less Likely" at ship time, and CISA's SSVC enrichment marks current exploitation as none. The CVE is not on the KEV catalogue as of writing.

That framing should not be read as "safe to defer." The bug is remote-code-execution-adjacent on the highest-value target in a virtualized shop — the hypervisor — and low-privileged exploitation from a guest is exactly the primitive a cloud-tenant attacker or a phished developer with WSL2 access already holds. Multiple Patch Tuesday roundups — CrowdStrike, Talos, Kaspersky, and Zero Day Initiative — call it out as the highest-priority Critical to patch this month.

Action checklist

  1. Patch every host running Hyper-V, WSL2, or Windows Sandbox today. The July 14, 2026 cumulative closes the bug on all supported Windows client and server SKUs. Reboot is required — VMSwitch is a kernel driver.
  2. Prioritize multi-tenant hosts. Hyper-V clusters running mixed-trust workloads, VDI pools, hosted CI runners, sandbox farms, and any host where a guest owner is not also a host owner sit at the top of the exposure list.
  3. Do not gate on KEV. Wait for KEV and you wait for exploitation to arrive. The scope-changed CVSS 9.9 and the guest-to-host boundary are the reason to move now.
  4. If you cannot patch immediately, restrict who runs guest code. Any user or process that can execute code inside a guest VM is a potential exploiter. Revisit RDP and console access to guests, PowerShell Direct rights, and integration-service allowlists.
  5. Audit for stray VMSwitch installs. Enabling WSL2 on a developer laptop installs the driver silently. Fleet-wide, that means every dev workstation running WSL2 is in scope — not just the servers you think of as Hyper-V hosts.
  6. Rebuild guest images cautiously if you were behind on updates. No PoC is public today, but a rushed catch-up cycle in a fleet with poor host-guest separation is exactly the window an early exploit chain would target.

Context

CVE-2026-57092 is the second Hyper-V VMSwitch escape Microsoft has patched in twelve months — a pattern the ZDI July review flags explicitly. VM escapes remain rare in the public catalogue because they require both a kernel bug in the hypervisor's guest-facing surface and reliable primitives to weaponize it — but the payoff for an attacker is disproportionate. A VMSwitch bug is not a route into one workload; it is a route into every workload sharing the host.

The 621-CVE July release also carried two zero-days already in KEV: the AD FS DKM ACL bug that Microsoft's DART discovered in a live intrusion, and the SharePoint pre-auth bypass CVE-2026-56164 that CISA hardened the same day. VMSwitch is the quietest of the three — no headline, no in-the-wild story — and the one with the highest theoretical blast radius if a working exploit lands.

Related stories