Hyper-V Remote Denial-of-Service Bug Fixed in July Windows Updates – Who’s Affected and How to Patch

Microsoft’s July 2026 security updates, released on July 14, close a use-after-free vulnerability in the Windows Virtual Filtering Platform (VFP) that can let an authenticated attacker remotely crash a system. Tracked as CVE-2026-50432, the flaw is rated Important with a CVSS 3.1 score of 5.3. It affects nearly every supported Windows client and server version, from Windows 10 1607 to Windows 11 26H1, plus Windows Server 2016, 2019, 2022, and 2025. While the severity score appears modest, the bug’s location inside Hyper-V’s virtual switch makes it a meaningful threat for server and virtualization environments.

The July 14 fix and which builds are protected

The vulnerability is remediated in the July cumulative updates. For Windows 11 versions 24H2 and 25H2, the fix arrives in KB5101650, pushing those systems to builds 26100.8875 and 26200.8875, respectively. Other affected releases have their own update packages that include the same VFP correction. Because Windows cumulative updates are superseding, any later update installed after July 14 should also contain the patch.

Here are the minimum fixed builds for each affected version:

Both Server Core and Desktop Experience installations are affected. Older Windows 10 branches in the list represent Long-Term Servicing Channel (LTSC) or server equivalents, not consumer editions returning to broad support.

What the VFP vulnerability actually does

CVE-2026-50432 is a classic memory-safety mistake: a use-after-free (CWE-416). The operating system continues to access an object in memory after that object has already been released, leading to unpredictable behaviour that can crash the component. In this case, Microsoft says an authorized attacker can trigger the bug over a network to cause a denial of service.

The full CVSS vector – AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H – tells the story. The flaw is network-accessible, requires no user interaction, and can completely disrupt availability. However, an attacker needs low privileges (any authenticated session will do), and attack complexity is rated high. That last metric signals that exploitation isn’t trivial: it may depend on specific network states, packet sequences, or configurations. There is no impact on confidentiality or integrity; data theft and code execution are out of scope.

In plain English, this is a crash bug, not a takeover. But a crash inside VFP can be deeply disruptive because of where that code runs.

Who should move first—and who can breathe easier

VFP is not exposed identically on every Windows machine. It lives as an NDIS forwarding extension inside the Hyper-V Virtual Switch, where it enforces virtual networking policies: access rules, NAT, QoS, traffic forwarding. A typical home laptop without Hyper-V or containers enabled is unlikely to have the VFP code actively reachable over the network, even though the vulnerable binary is present. Microsoft has not clarified if all default installations expose the attack surface equally, but the practical risk for such users is low.

Server administrators should take the opposite view. Any Hyper-V host, Software Defined Networking (SDN) node, container host, or system with complex virtual-switch configurations should be patched promptly. Even if a denial-of-service attack doesn’t demand emergency weekend patching, it can be woven into a broader intrusion. An attacker who already has low-privilege access might crash a host to interrupt monitoring, force failover, or cover other malicious activity. For clustered environments, a well-timed crash could cascade.

No active exploitation or public proof-of-concept code was known as of July 14, 2026. CISA’s initial assessment confirmed the vulnerability is not readily automatable, and the technical impact is rated partial. Still, the absence of working exploit code today doesn’t guarantee it won’t appear later.

How VFP became a weak spot: a short background

Microsoft introduced the Virtual Filtering Platform as part of the Hyper-V virtual switch architecture to add programmable network policy enforcement. Think of it as a software-defined networking layer that can inspect, modify, and manage every packet flowing between virtual machines and the outside world. That role sits deep in the packet-processing path, making VFP both performance-sensitive and critical for reliability.

Use-after-free vulnerabilities have plagued software for decades. In a networking context, they often emerge when object lifetimes aren’t managed carefully during complex sequences of connection setup, teardown, and reconfiguration. Microsoft confirmed the vulnerability but hasn’t released details on exactly how an attacker would trigger it—likely to give administrators time to patch.

The CVE was disclosed as part of the July 2026 Patch Tuesday cycle. No prior public reports of the bug exist, and Microsoft’s advisory marks its report confidence as “confirmed,” meaning the vendor verified the underlying flaw.

Verifying the patch took hold

Don’t trust the update history alone. Vulnerability scanners and endpoint-management platforms may report a device as compliant even when an update is pending a reboot or has silently failed. Directly check the build number. The quickest method: run winver from the Start menu and look for the OS build. PowerShell can also retrieve it with (Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" -Name CurrentBuild).CurrentBuild.

For Windows 11 24H2 or 25H2, the build after installing KB5101650 should be 26100.8875 or 26200.8875. For servers, confirm the build matches the fixed threshold in the table above. Remember that Server Core installations—which many admins manage remotely—must also be checked. They aren’t immune simply because they lack a desktop interface.

Steps for your update rollout

• Prioritize Hyper-V hosts, SDN controllers, and container hosts. Any server running the virtual switch or managing network policies for VMs should be at the top of your deployment list.
• Use rolling updates for clusters. Patching every node at once is a bad idea for a denial-of-service vulnerability. Follow your normal maintenance procedure to avoid self-inflicted downtime.
• Plan for reboots. Cumulative updates require a restart. In production environments, that means coordination with workload owners.
• Validate build numbers post-reboot. Don’t close the ticket until you’ve confirmed each system crossed the fixed-build threshold.
• No workaround exists. Microsoft has not offered any mitigation or registry key that disables VFP without breaking Hyper-V. The cumulative update is the only path to safety.

The update can be applied through Windows Update, Windows Server Update Services, Microsoft Endpoint Configuration Manager, or standard third-party patch tools.

What’s next

As of mid-July 2026, CVE-2026-50432 remains an Important denial-of-service bug with no known exploitation. That could change. Memory-safety flaws in kernel-level networking components have an unpredictable shelf life; once a proof-of-concept emerges, the window for unpatched systems shrinks fast.

Administrators should monitor the Microsoft Security Response Center for any revision to the advisory. If exploit activity is later detected, Microsoft would likely raise the severity and issue further guidance. For now, the immediate takeaway is straightforward: install the July cumulative updates, reboot, and verify your builds. In environments where Hyper-V and software-defined networking are business-critical, that step shouldn’t wait.