CVE-2026-25170: Windows Hyper-V Local Privilege Elevation via Use‑After‑Free

Microsoft and independent trackers recorded CVE-2026-25170 on March 10, 2026 — a use‑after‑free (CWE‑416) vulnerability in Windows Hyper‑V that Microsoft classifies as an elevation‑of‑privilege flaw allowing an authorized local actor with low privileges to obtain higher privileges on the host. Public registries show the vendor as the canonical source and report a CVSS v3.1 base score of 7.0 (High) with the vector string AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, indicating a local attack vector, high attack complexity, and no required user interaction. (nvd.nist.gov) (cvedetails.com)

Background / Overview​

Hyper‑V is Microsoft’s built‑in hypervisor embedded across Windows client and server SKUs; it runs privileged code on the host and exposes integration channels used by guests and host management tools. Vulnerabilities in Hyper‑V components — particularly memory‑corruption defects such as use‑after‑free and race conditions — are high‑value targets because successful exploitation can allow a process with limited rights to elevate to SYSTEM or host‑level privileges. The NVD entry for CVE‑2026‑25170 summarizes the technical classification as a use‑after‑free and links the record to Microsoft’s vendor advisory listing. (nvd.nist.gov)
Microsoft’s public advisory record for CVE‑2026‑25170 (catalogued in its Security Update Guide and reflected in third‑party trackers) shows the vendor as the originator of the CVE submission and confirms the vulnerability exists and has been addressed in Microsoft’s servicing model. Independent aggregators indexed the entry the same day, and public CVE trackers list the same high‑level description and CVSS vector. Those parallel entries are consistent with a vendor‑confirmed, high‑confidence disclosure. (cvedetails.com)

---

What the record actually says — technical summary​

The core defect​

• The vulnerability is described as a use‑after‑free (UAF) in a Hyper‑V component. UAFs occur when code reuses memory after it has been freed, allowing attackers—under the right timing and reuse conditions—to manipulate data structures or redirect control flow. The NVD and vendor metadata list CWE‑416 as the weakness class. (nvd.nist.gov)

Impact and attack model​

• Impact: Local elevation of privilege on the Hyper‑V host (confidentiality, integrity, and availability impacts all rated High in the vendor-supplied CVSS vector). (cvedetails.com)
• Attack vector: Local (an attacker must already have local/authorized access to the target machine). (nvd.nist.gov)
• Attack complexity: High — the vendor’s metrics and third‑party scoring indicate exploitation requires non‑trivial conditions such as precise timing, careful memory grooming, or specific host state. This reduces immediate mass exploitation risk but does not eliminate targeted abuse. (nvd.nist.gov)

Vulnerability timing and vendor response​

• The CVE record and indexers list the public disclosure and vendor submission date as March 10, 2026. The vendor (Microsoft) is listed as the CNA/source, which signals a vendor‑driven disclosure and availability of vendor guidance and updates mapped within Microsoft’s update catalog. (nvd.nist.gov)

---

Why defenders should care (context and risk calculus)​

Hyper‑V runs at high privilege and often hosts many production workloads or developer systems. A successful local elevation on a Hyper‑V host can permit:

• direct compromise of the virtualization host (SYSTEM privileges),
• modification of other VM images or live guest state,
• credential theft and lateral movement from a now‑privileged host,
• persistence that survives guest reboots.

Although CVE‑2026‑25170 is scored with a local vector and high complexity, historical precedent shows Hyper‑V memory‑corruption bugs have been weaponized. In January 2025, Microsoft patched several Hyper‑V use‑after‑free flaws that were actively exploited; the remediation for those issues required rapid, prioritized patching in many environments. That history raises the operational imperative: Harden, inventory, and patch Hyper‑V hosts early rather than assuming ility is “low risk.”
Community discussion also highlights how Microsoft’s advisory metadata — especially the vendor’s report confidence / exploitability signals — should shape triage and patch scheduling for administrators. The vendor‑confirmed CNAs and high CVSS rating push this CVE into the “patch promptly for management hosts” category even if no public exploit is circulating today.

---

Confidence, disclosure posture, and what Microsoft’s metadata means​

Security advisories carry two important signals beyond CVSS numbers: the vendor’s report/technical confidence and the remediation level (workaround, temporary fix, official fix). These signals help defenders prioritize action.

• Report confidence: A metric that measures the degree of confidence in the vulnerability’s existence and in the accuracy of the technical details. Vendor‑confirmed entries — those where Microsoft is the CNA and has submitted CVSS metadata — indicate high confidence that the flaw exists and that the public description is accurate. The CVE and NVD records for CVE‑2026‑25170 show Microsoft as the source and record the CVSS vector, which is consistent with a vendor‑validated disclosure. (nvd.nist.gov)
• Remediation level: Microsoft’s Update Guide maps CVEs to KBs / update packages; patch availability is the most decisive temporal signal for action. Trackers show the CVE mapped to Microsoft’s update guidance on March 10, 2026, signalling that an official fix has been published or will be distributed as part of Windows servicing. (cvedetails.com)

CVSS specifications and community guides explain the report confidence concept and why it matters: a high report confidence reduces ambiguity and gives defenders permission to act decisively (patch, isolate, hunt); lower confidence advises additional validation and careful testing prior to broad rollouts. For CVE‑2026‑25170, vendor attribution and the inclusion of a full CVSS vector suggest Microsoft has high confidence in the assessment.

---

What we do and don’t know right now — verification checklist​

• Confirmed facts
• The CVE identifier exists and was published on March 10, 2026; the vendor (Microsoft) is listed as the source. (nvd.nist.gov)
• The vulnerability class is Use‑After‑Free (CWE‑416) inside Windows Hyper‑V, with the vendor‑stated impact of local elevation of privilege. (cvedetails.com)
• A CVSS v3.1 vector and base score (7.0) were supplied by Microsoft and recorded by NVD/CVE aggregators. (nvd.nist.gov)
• Unverified / not publicly available
• There is no public proof‑of‑concept exploit widely published at time of disclosure in registry or aggregation feeds. Third‑party trackers indicate no EPSS or exploit telemetry as of publication. That reduces—but does not eliminate—immediate threat. Treat this as time‑sensitive: lack of a public exploit does not equal lack of risk.
• Low‑level exploit mechanics (for example, the exact code path, specific vulnerable function names, or exploit primitives) have not been exhaustively published in the public advisory. Microsoft’s approach often withholds deep exploit detail until patches are broadly distributed; read the vendor guidance for KB→SKU mappings before automating rollouts. (nvd.nist.gov)

If any of the above unverifiable items become public (exploit PoC, proof of in‑the‑wild abuse), the operational priority for Hyper‑V hosts should increase immediately. Windows security history shows targeted attackers will attempt to weaponize local‑access UAFs against high‑value management endpoints quickly when the details leak.

---

Practical mitigation and patching playbook (recommended immediate actions)​

Applied quickly and methodically, the following steps will materially reduce risk from CVE‑2026‑25170 for most organizations.

1. Inventory and prioritize​

• Enumerate all Hyper‑V hosts and machines with the Hyper‑V role enabled, including developer laptops that run local VMs and domain‑joined management servers.
• Prioritize systems that host multi‑tenant workloads, control planes (cluster nodes, management servers), or contain privileged credentials.

2. Confirm vendor KB mapping and apply updates​

• Consult Microsoft’s update catalog / Security Update Guide entry for CVE‑2026‑25170 and record the exact KB packages and OS builds that contain the fix.
• Test the vendor patch in a small pilot (especially for production cluster or HCI nodes) and then roll out to prioritized hosts.
• If you use WSUS, update management tooling to ensure the KBs are approved and scheduled for deployment to targeted device groups.

3. Short-term containment if patching is delayed​

• Remove or restrict local administrative access to Hyper‑V hosts; enforce least privilege and jump‑box patterns for management tasks.
• Disable non‑essential Hyper‑V integrations (e.g., unnecessary Guest‑to‑Host integration features or VSP paths) when feasible.
• Apply host isolation and network segmentation rl movement from a compromised host to critical resources.

4. Detection and hunting​

• Implement EDR rules to watch for suspicious process behavior on Hyper‑V hosts: abnormal device‑driver loads, unexpected VM manipulation APIs, or kernel‑mode crashes related to Hyper‑V components.
• Collect and review kernel crash dumps and Windows event channels for unexplained use‑after‑free symptoms (crashes or irregular memory faults) on hosts.
• Hunt for local privilege elevation activity (new SYSTEM processes spawned from low‑privilege contexts, credential access, or abnormal service modifications).

5. Post‑patch validation​

• After applying vendor updates, validate hosts by confirming OS build/patch levels and re‑conducting local hardening checks.
• Re‑run EDR detection sweeps and verify no persistent artifacts from pre‑patch activity remain.
• Document remediation and ensure change control records include the CVE identifier and KB mapping.

These steps are the standard operational playbook for vendor‑confirmed Hyper‑V EoP defects and are consistent with the practical guidance provided in community briefings and incident playbooks.

---

Detection signatures and hunting suggestions (technical detail)​

• Look for anomalous use of Hyper‑V management APIs from non‑privileged contexts. Legitimate user applications should not ordinarily be invoking host‑control paths that change VM memory or host device state.
• Monitor kernel crash dumps for repeated page‑fault or access‑violation patterns inside Hyper‑V DLLs/drivers; UAFs may manifest as non‑deterministic crashes under memory‑reuse conditions.
• Configure EDR to flag when low‑privilege processes attempt to open or manipulate VM physical memory ranges, or when they attempt to load unsigned or unexpected kernel drivers.
• In environments that collect Windows kernel telemetry (stackwalks, kernel traces), search for frequent allocations/frees followed by use in the same weighted address space — patterns that often precede reproducible use‑after‑free exploitation.

Note: detailed memory forensics may require offline analysis and vendor coordination. If you see telemetry strongly indicative of exploitation (unexpected SYSTEM creation, credential dumping, unexplained LSA activity), treat hosts as potentially compromised and enact incident response containment steps.

---

Threat actor and exploitation likelihood assessment​

• Current public records do not show wide public PoC release or confirmed in‑the‑wild exploitation for CVE‑2026‑25170 at the time of disclosure. Several reputable trackers report no EPSS or exploitation telemetry linked to this CVE immediately post‑publication. That lowers—but does not eliminate—near‑term mass exploitation risk.
• Attack complexity is rated High, which implies reliable exploitation may require precise memory grooming and timing conditions that are non‑trivial to reproduce across variable host configurations. This typically favors targeted, skilled adversaries over opportunistic mass attackers.
• However, Hyper‑V has been subject to real‑world exploitation in previous years; when vendors release fixes and CVE summaries, sophisticated actors sometimes reverse the patches to craft private exploits. The historical record suggests defenders should not defer patching until proof‑of‑exploit appears.

---

Strengths and limitations of the public record — critical analysis​

Strengths​

• Vendor submission: Microsoft is the CNA and supplied a full CVSS vector and weakness classification, which increases transparency and gives defenders a clear, authoritative starting point. Registry entries and vendor metadata converge on the same high‑level picture. (nvd.nist.gov)
• Clear impact class: NVD/CVE trackers consistently identify the flaw as a use‑after‑free that leads to local elevation of privilege; this is a concrete, well‑understood vulnerability category with known exploitation patterns and mitigations. (cvedetails.com)

Limitations and risks​

• Sparse exploit details: Microsoft’s public advisory cadence often deliberately omits deep exploitation mechanics until widespread patching has occurred. That reduces short‑term weaponization risk but leaves defenders without low‑level IOCs to hunt effectively. This tradeoff makes quick, conservative patching the safest operational posture. (nvd.nist.gov)
• Local vector but high impact: Although the CVE requires local access, many environments provide local access via remote management, service accounts, or multi‑user workstations; conflating “local” with “low consequence” is a dangerous mistake. Historical Hyper‑V exploitation underscores the potential for damage even when initial access is constrained.
• No EPSS/No public PoC: While the absence of an EPSS or public ex mass‑scale risk, it can create a false sense of security; historically, proof‑of‑concept code for memory‑corruption bugs often appears weeks after patches, and successful targeted exploits have been built by capable adversaries.

---

Recommended timeline for operations teams (prioritized and pragmatic)​

• Within 24 hours
• Inventory all Hyper‑V hosts and identify which systems are high‑value (management servers, domain controllers, multi‑tenant hosts).
• Review Microsoft’s update mapping for CVE‑2026‑25170 and schedule patch tests. (cvedetails.com)
• Within 72 hours
• Complete patch testing on pilot hosts, validate rollback plans, and start phased rollouts to high‑priority hosts.
• Harden host access and apply immediate containment controls for hosts that cannot be patched within the window.
• Within 1–2 weeks
• Complete remediation across remaining Hyper‑V hosts and validate via telemetry review and post‑patch hunting.
• Document remediation and integrate the CVE into your vulnerability management and configuration baselines.
• Ongoing
• Maintain an active hunt for exploitation attempts and monitor threat intelligence feeds for any public PoC or exploit chatter referencing CVE‑2026‑25170.
• Update incident playbooks to reflect lessons learned and adjust segmentation/privitualization management planes.

Community advisory threads and operational playbooks emphasize the same cadence: prioritize management and high‑value hosts first, test patches safely, and assume motivated adversaries will attempt to accelerate exploitation research after disclosure.

---

Final assessment and closing recommendation​

CVE‑2026‑25170 is a vendor‑confirmed, high‑impact use‑after‑free vulnerability in Windows Hyper‑V that allows local elevation of privilege. The record is clear enough to compel prioritized operational action: inventory Hyper‑V hosts, confirm Microsoft’s KB mappings, test and apply fixes promptly, and harden/monitor management endpoints while patch rollouts proceed. The CVSS vector and vendor metadata point to high impact but non‑trivial exploitation complexity, so the immediate mass‑exploitation risk is moderate — however the historical pattern for Hyper‑V vulnerabilities argues strongly against complacency.
In simple terms: do not wait for a proof‑of‑concept to appear. Treat Hyper‑V hosts as high‑priority assets, patch them according to Microsoft’s guidance, and use layered detection and segmentation to reduce the blast radius in case a skilled adversary attempts targeted weaponization.

---

Conclusion
CVE‑2026‑25170 reminds administrators that virtualization control planes are attractive, high‑impact targets and that vendor‑confirmed UAF defects require decisive, timely action. Microsoft and independent registries provide the canonical technical metadata and severity metrics; use those authoritative signals to drive your patch, containment, and detection plans now — before an exploit becomes widely available. (nvd.nist.gov) (cvedetails.com)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center