CVE-2026-42915

What it actually does

CVE-2026-42915 is a local denial-of-service vulnerability in Windows VMSwitch, the Hyper-V virtual switch component. An authorized local attacker with low privileges can trigger an incorrect buffer-size calculation in the VMSwitch code path, causing a high-impact availability failure such as a service crash, host networking disruption, or system bugcheck. The flaw does not provide confidentiality or integrity impact and is not described as enabling privilege escalation or remote code execution.

Why it matters to the business

Successful exploitation can disrupt Hyper-V host networking and workloads that depend on virtual switching, potentially causing virtual machine connectivity loss, service outages, failed maintenance operations, or host instability. The risk is most relevant on Windows client and server systems using Hyper-V, virtualization-based services, containers, or virtual networking. Current exploitation signals are low: EPSS is 0.00383 with no 30-day increase, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity reported; however, affected Windows Server and workstation versions are broadly deployed, so patching should still be handled through normal security update cycles with higher priority for virtualization hosts.

How an attack unfolds

An attacker first needs local authenticated access to an affected Windows system. From that position, the attacker runs code or issues system interactions that reach Windows VMSwitch functionality, typically on a host where Hyper-V virtual networking, virtual switches, containers, or related virtualization features are enabled. The attacker then supplies inputs or triggers a code path that causes VMSwitch to miscalculate a required buffer size. Because the component operates in a privileged networking/virtualization context, the resulting memory-handling failure can destabilize the virtual switch or the host, leading to denial of service. The expected outcome is disruption rather than data theft or code execution: virtual networking may stop working, virtual machines may lose connectivity, and the Windows host may log crash, bugcheck, or unexpected restart events.

How to fix it

Apply the Microsoft security update that addresses CVE-2026-42915 for the affected Windows version. Because no discrete fixed build numbers were provided, use Windows Update, Microsoft Update Catalog, WSUS, Intune, Configuration Manager, or the organization's normal patch-management tooling to install the latest cumulative security updates for Windows 10 21H2/22H2, Windows 11 23H2/24H2/25H2/26H1, Windows Server 2022, and Windows Server 2025. Prioritize Hyper-V hosts, systems running containers or virtualization-based networking, and servers where VM network availability is business-critical. If immediate patching is not possible, reduce exposure by limiting local interactive and remote logon rights, removing unnecessary local users from affected hosts, disabling unused Hyper-V/virtual-switch functionality where operationally feasible, restricting administrative access to virtualization hosts, and monitoring for repeated crashes or virtual switch failures.

How to confirm the fix worked

Confirm exposure by identifying systems running affected Windows versions and checking whether Hyper-V, virtual switches, Windows containers, or virtualization-based networking features are enabled. Validate remediation by confirming that the latest applicable cumulative Windows security update is installed and that the system build/revision matches Microsoft guidance for the relevant release channel. On Hyper-V hosts, verify that virtual switches are present and operational after patching, VMs or containers retain expected network connectivity, and no new VMSwitch-related crash or bugcheck events occur after reboot. For compensating controls, validate that only approved users can log on locally or remotely to affected systems and that unnecessary Hyper-V or virtual switch features are disabled where not required.

Typical attack path

1. Obtain low-privileged local access to an affected Windows 10, Windows 11, Windows Server 2022, or Windows Server 2025 system.
2. Confirm that Hyper-V, virtual switching, container networking, or other VMSwitch-dependent functionality is present or enabled.
3. Execute a local program or trigger local API/system interactions that exercise the vulnerable VMSwitch buffer calculation path.
4. Cause VMSwitch or the host networking stack to enter an error condition due to the incorrect buffer-size calculation.
5. Induce denial of service, such as virtual switch failure, VM/container network interruption, or host crash/restart.
6. Optionally repeat the trigger to maintain disruption until the system is patched or the attacker's local access is removed.

How to detect it

To determine whether this vulnerability may already have been exploited, focus on evidence of local denial-of-service activity rather than remote intrusion. Review Windows System logs for bugchecks, unexpected shutdowns, and service-control failures around the time of Hyper-V or virtual network disruption. Review Hyper-V VMSwitch operational/admin logs for virtual switch failures, port disconnects, extension failures, or repeated switch resets. Correlate those events with local logon events, Remote Desktop sessions, PowerShell activity, process creation telemetry, and newly introduced executables run by non-administrative users. Relevant log sources include Windows System, Microsoft-Windows-Hyper-V-VmSwitch logs, Microsoft-Windows-Hyper-V-VMMS logs, Windows Security logs for logon activity, Sysmon or EDR process telemetry, Windows Error Reporting, crash dumps, and hypervisor/host monitoring alerts. Indicators are likely behavioral: repeated VMSwitch-related crashes, host bugchecks referencing vmswitch.sys, virtual switch outages following local user activity, or recurring restarts with no maintenance explanation. Absence of such events does not prove non-exploitation, because a denial-of-service attempt may leave only generic crash or reboot artifacts.

• C:\Windows\System32\drivers\vmswitch.sys
• Microsoft-Windows-Hyper-V-VmSwitch
• Microsoft-Windows-Hyper-V-VMMS
• Event ID 1001
• Event ID 41
• Event ID 6008
• BugCheck
• vmswitch.sys
• The computer has rebooted from a bugcheck
• The system has rebooted without cleanly shutting down first
• The previous system shutdown was unexpected
• C:\Windows\MEMORY.DMP
• C:\Windows\Minidump\

What your security team should do

• Inventory Windows systems in the affected product list and tag those using Hyper-V, virtual switches, containers, or virtualization-based networking as higher priority.
• Deploy the latest Microsoft cumulative security updates to affected systems, prioritizing Windows Server virtualization hosts and operationally critical workstations or servers.
• Review local user, Remote Desktop, PowerShell Remoting, and administrative group memberships on affected systems to reduce the number of users able to trigger a local denial of service.
• Monitor for System log bugcheck, unexpected shutdown, and Hyper-V VMSwitch events that correlate with local user sessions or newly executed binaries.
• If outages are observed before patching, preserve memory dumps, System logs, Hyper-V logs, and recent process execution telemetry for forensic review.
• Because EPSS is low, there is no KEV listing, and no exploit maturity is reported, treat this as a normal-to-elevated patching item rather than an emergency internet-facing exploitation scenario, unless the affected host supports critical virtualization workloads.