Is CVE-2025-21335 (Microsoft Windows Hyper-V NT Kernel Integration VSP Use-After-Free) being exploited in the wild?

Yes. CISA added CVE-2025-21335 to its Known Exploited Vulnerabilities catalogue on 14 January 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Windows Hyper-V NT Kernel Integration VSP contains a use-after-free vulnerability that allows a local attacker to gain SYSTEM privileges.

What “exploited in the wild” means for a KEV-listed CVE

A CISA KEV listing is the strongest practical signal that a vulnerability is not just theoretically exploitable, but has credible evidence of active use. For defenders, that changes the question from “should we patch?” to “is this exposed here, and has it already been used against us?” Treat the KEV entry as a trigger for immediate exposure review, not as a score to debate.

For a Windows Hyper-V flaw affecting a local privilege boundary, the first task is to confirm whether any system in your estate actually exposes the vulnerable component and whether any account on that host could reach the vulnerable path. The issue is not remote reachability by default, it is whether a local foothold can be turned into SYSTEM privileges.

Because the vulnerability is in a kernel-integrated virtualization component, the operational concern is blast radius. Once an attacker has local execution on a host, privilege escalation can turn a low-value foothold into control over the machine, its secrets, and anything trusted by that machine.

How to verify exposure and decide what to do first

The right workflow is to start with asset identification, then move to host-level exposure, then to compromise checks. The relevant question is not whether the CVE exists in the abstract, but whether your Windows hosts with Hyper-V enabled are reachable by a local attacker through a realistic initial access path.

Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog for authoritative remediation direction, then map that guidance to your own host inventory and patch windows. If a system cannot be patched immediately, isolate it from untrusted local execution paths and treat it as a priority for containment.

When a host is exposed, the practical response is to patch or mitigate quickly, then validate that the system is no longer reachable through the vulnerable code path. If you rely on rolling maintenance, make the vulnerable host set visible to operations so it does not sit unnoticed in a deferred backlog.

What earlier compromise checks matter after active exploitation is confirmed

Once a vulnerability is known to be in active exploitation, you should assume some systems may already have been used for privilege escalation before you finish remediation. That makes post-exposure validation part of the fix, not an optional follow-up. The key question is whether any host showed signs of local privilege escalation, suspicious process creation, or privilege changes around the relevant window.

For host-side investigation, preserve logs and look for newly created privileged accounts, unusual service activity, odd kernel or virtualization-related crashes, and any signs that a local attacker used the host as a stepping stone. If the host held sensitive credentials or administrative sessions, review whether those were reachable from the escalated context.

If the affected machine participated in administration, virtualization, or management workflows, treat the incident as potentially broader than a single endpoint. Local SYSTEM on a host can be enough to expose service credentials, session material, or internal administrative access paths.

Risk and Threat Considerations

This CVE matters because local privilege escalation is often the bridge between initial access and full host compromise. In a virtualization-adjacent component, that bridge can also create a path to higher-trust workloads or management activity on the same system.

Failure mechanism: A use-after-free condition in kernel-integrated Hyper-V code can be triggered by a local attacker to corrupt execution flow and obtain SYSTEM privileges, especially if they already have some foothold on the host.

Impact: Successful exploitation can let an attacker disable defenses, access sensitive local material, stage lateral movement, and persist with elevated control over the affected machine.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes rapid identification and remediation of vulnerable hosts central.
Recommendation — Prioritise exposed Hyper-V hosts for immediate remediation and validation.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	The question hinges on identifying whether the vulnerable Windows hosts exist in the environment.
Recommendation — Inventory affected hosts and map exposure before deciding containment.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	A KEV-listed local privilege escalation vulnerability requires prompt patching or mitigation.
Recommendation — Apply the vendor fix or mitigation as soon as operationally possible.
MITRE ATT&CK	T1068 — Exploitation for Privilege Escalation	The CVE enables local attackers to escalate from foothold to SYSTEM privileges.
Recommendation — Hunt for privilege-escalation activity and contain compromised hosts quickly.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Host compromise can expose privileged machine-bound material and widen blast radius.
Recommendation — Review any machine-bound credentials reachable from the affected host.

Practitioner Guidance

What to prioritise: Patch or mitigate any exposed Hyper-V hosts first, especially systems that accept local code execution from multiple users, run administrative tooling, or host sensitive workloads. If you have to sequence work, place internet-facing or heavily reused server images ahead of isolated endpoints because their compromise value is higher.

What to verify: Confirm whether the vulnerable component is present, whether the host is in the KEV-backed remediation set, and whether there are any indicators of local privilege escalation before you declare the system clean. Do not treat “patched” as sufficient until you have checked for pre-patch abuse on the most exposed hosts.

Practitioner takeaway: For a KEV-listed privilege-escalation flaw, the decision point is not whether exploitation is possible, but whether the host was exposed long enough for an attacker to use it before you contained the blast radius.